Come trovare la vulnerabilità nella tua applicazione web?

Al giorno d'oggi sempre più aziende forniscono API web per accedere ai propri servizi. Di solito seguono lo stile REST. Un tale servizio web RESTful sembra una normale applicazione web. Accetta una richiesta HTTP, fa qualche magia e quindi risponde con una risposta HTTP. Una delle principali differenze è che la risposta normalmente non contiene codice HTML da visualizzare in un browser web. Invece, la risposta di solito contiene dati in un formato (ad esempio, JSON o XML) che è più facile da elaborare da un'altra applicazione.

Sfortunatamente, poiché un servizio Web RESTful è ancora un'applicazione Web, potrebbe contenere vulnerabilità di sicurezza tipiche per applicazioni Web come SQL injection, XXE e così via. Uno dei modi per identificare i problemi di sicurezza nelle applicazioni Web è utilizzare gli scanner di sicurezza Web. Fortunatamente, poiché un servizio Web RESTful è ancora un'applicazione Web, possiamo utilizzare gli scanner di sicurezza Web per cercare problemi di sicurezza nelle API Web.

Esistono diversi scanner di sicurezza Web ben noti. Uno di questi è w3af.

In che modo w3af trova le vulnerabilità?

w3af è un framework di controllo e attacco alle applicazioni Web. L'obiettivo del progetto è creare un framework per aiutarti a proteggere le tue applicazioni web trovando e sfruttando tutte le vulnerabilità delle applicazioni web. Questo framework contiene centinaia di plugin che aiuteranno a trovare le vulnerabilità.

I plug-in di scansione utilizzano tecniche diverse per identificare nuovi URL, moduli e qualsiasi altra risorsa che potrebbe essere utile durante le fasi di controllo e forza bruta. In altre parole, questi plug-in esplorano l'applicazione e provano a scoprire i punti di ingresso da testare.

I plug-in di controllo utilizzano la conoscenza creata dai plug-in di ricerca per indicizzazione per individuare le vulnerabilità nell'applicazione Web remota e nel server Web. Questi plugin testano i punti di ingresso scoperti per le vulnerabilità.

Abilitando alcuni plugin potresti trovare alcune vulnerabilità, ma non molto. Ecco un risultato del mio progetto web spring-boot. Uno scanner Web di solito cerca di navigare in un sito Web per trovare tutte le pagine e i parametri disponibili che possono quindi essere testati per le vulnerabilità. Nel caso di un tipico sito Web, uno scanner spesso parte da una home page e cerca collegamenti ad altre pagine nel codice HTML. Ma questo approccio non funziona con le API web perché di solito gli endpoint API non servono dati HTML e le API di solito non fanno riferimento l'una all'altra nelle loro risposte.

{
  "items": [
    {
      "href": "/scans/1/kb/0",
      "id": 0,
      "name": "Strange HTTP Reason message",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/1/kb/1",
      "id": 1,
      "name": "Cross site tracing vulnerability",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/1/kb/2",
      "id": 2,
      "name": "Omitted server header",
      "url": null
    },
    {
      "href": "/scans/1/kb/3",
      "id": 3,
      "name": "Allowed HTTP methods",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/1/kb/4",
      "id": 4,
      "name": "Click-Jacking vulnerability",
      "url": null
    }
  ]
}

Una RESTful Api Spec è importante per uno scanner

Come otteniamo un elenco di endpoint API e parametri da scansionare? Ci sono due modi principali:

• N. 1 RESTful Api Spec Un servizio Web può avere una specifica OpenAPI che descrive tutti gli endpoint, i parametri, le risposte, gli schemi di autenticazione, ecc. Tale specifica è normalmente fornita dagli sviluppatori.
• # 2 Delega Utilizzando un proxy, possiamo acquisire le richieste HTTP che sono state inviate agli endpoint API da un client. Quindi, possiamo analizzare le richieste acquisite ed estrarre informazioni sui parametri.

Il modo in cui il numero 1 sembra molto meglio del numero 2. In un mondo perfetto, ogni servizio web ha una specifica OpenAPI che è sempre disponibile e aggiornata. Ma nel mondo reale, non sembra accadere troppo spesso. Uno sviluppatore può modificare le API ma dimenticare di aggiornare le specifiche o per qualche motivo non rendere le specifiche disponibili pubblicamente. Nella maggior parte dei casi, l'API REST pubblicamente disponibile ha documenti leggibili dall'uomo, il che è carino ma di solito è difficile da usare in modo automatizzato.

• Ma APIGIT potrebbe semplificare le cose.

APIGIT è una piattaforma di collaborazione che si distingue per il supporto nativo di Git, che semplifica il processo di sviluppo delle API e il controllo della versione, consentendo agli utenti di progettare, documentare, simulare, testare e condividere facilmente le API. L'editor visivo OpenAPI della piattaforma, in combinazione con il suo supporto Git nativo, rende facile per il team collaborare e condividere il proprio lavoro in modo fluido ed efficiente.

In che modo w3af trova le vulnerabilità secondo una RESTful Api Spec?

Ecco parte del mio RESTful Api Spec.

"paths": {
    "/find_pet": {
      "get": {
        "summary": "List pet",
        "operationId": "listPet",
        "tags": [
          "pet"
        ],
        "parameters": [
          {
            "name": "version",
            "in": "query",
            "description": "Get pet by version",
            "required": true,
            "type": "string"
          }
        ],

Abilitando i plug-in correlati e il feed con la tua RESTful Api Spec:

[crawl.open_api]
custom_spec_location = /var/log/wvs/openapi2.json
no_spec_validation = True

Possiamo trovare più vulnerabilità.

{
  "items": [
    {
      "href": "/scans/0/kb/0",
      "id": 0,
      "name": "Strange HTTP Reason message",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/1",
      "id": 1,
      "name": "Omitted server header",
      "url": null
    },
    {
      "href": "/scans/0/kb/2",
      "id": 2,
      "name": "Cross site tracing vulnerability",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/3",
      "id": 3,
      "name": "Open API specification found",
      "url": "file:///var/log/wvs/openapi2.json"
    },
    {
      "href": "/scans/0/kb/4",
      "id": 4,
      "name": "Allowed HTTP methods",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/5",
      "id": 5,
      "name": "Cross site scripting vulnerability",
      "url": "http://192.168.1.65:8181/find_pet"
    },
    {
      "href": "/scans/0/kb/6",
      "id": 6,
      "name": "Unhandled error in web application",
      "url": "http://192.168.1.65:8181/_pet"
    },
    {
      "href": "/scans/0/kb/7",
      "id": 7,
      "name": "Unhandled error in web application",
      "url": "http://192.168.1.65:8181/find_"
    },
    {
      "href": "/scans/0/kb/8",
      "id": 8,
      "name": "Unhandled error in web application",
      "url": "http://192.168.1.65:8181/"
    },
    {
      "href": "/scans/0/kb/9",
      "id": 9,
      "name": "Strange HTTP response code",
      "url": "http://192.168.1.65:8181/%2Fbin%2Fcat+%2Fetc%2Fpasswd_pet"
    },
    {
      "href": "/scans/0/kb/10",
      "id": 10,
      "name": "Click-Jacking vulnerability",
      "url": null
    }
  ]
}

Parliamo del plugin crawl.open_api. La prima versione del plug-in ha cercato di trovare una specifica OpenAPI in una delle posizioni note come:

/api/openapi.json

/api/v2/swagger.json

/api/v1/swagger.yaml

e così via. È una caratteristica molto interessante. Se hai più servizi Web da testare e le loro specifiche API sono disponibili in posizioni note, devi solo alimentare lo scanner con i nomi host e questo è tutto. Lo scanner troverà tutti gli endpoint API da solo e quindi li testerà. Sfortunatamente, a volte i servizi Web non forniscono le specifiche API e il parametro custom_spec_file consente di impostare un percorso locale alla specifica OpenAPI. Un utente può utilizzare i documenti API e creare le specifiche da solo, oppure a volte le specifiche sono disponibili pubblicamente ma non in una posizione nota.