Strumento Automatico di Attacco API

Lo strumento di attacco API personalizzabile di Imperva prende una specifica API come input, e genera ed esegue attacchi basati su di essa come output.

Lo strumento è in grado di analizzare una specifica API e creare scenari di attacco fuzzing basati su ciò che è definito nella specifica API. Ogni endpoint viene iniettato con valori generati intelligentemente all'interno dei confini definiti dalla specifica, e al di fuori di essi, le richieste appropriate vengono inviate e il loro successo o fallimento viene riportato in modo dettagliato. Puoi anche estenderlo per eseguire vari vettori di attacco di sicurezza, come accesso a risorse illegali, XSS, SQLi e RFI, mirati agli endpoint esistenti, o anche a quelli inesistenti. Non è necessario alcun intervento umano. Basta eseguire lo strumento e ottenere i risultati.

Lo strumento può essere facilmente esteso per adattarsi a varie esigenze, come per uno sviluppatore che vuole testare la propria API, o un'organizzazione che vuole eseguire scansioni regolari di vulnerabilità o sicurezza positiva sulla propria API pubblica. È costruito pensando al CI/CD.

Requisiti

Java 8 o superiore
Gradle

Esecuzione

Scarica il codice da GitHub ed esegui ./gradlew build o gradlew.bat build su Windows
Puoi trovare il jar eseguibile nella cartella build/libs
Esegui 'java -jar imperva-api-attack-tool.jar' per vedere il menu di aiuto

Creazione di un eseguibile Linux

Copia il file runnable.sh dalla cartella src/main/resources nella stessa directory del file jar.
Ora esegui: cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
Puoi usare il file api-attack.sh come un normale eseguibile

Utilizzo

Parametri richiesti:

-f, --specFile=percorsoFileSpec

Il file di specifica API (swagger 2.0) su cui eseguire. Formato JSON/YAML. Per risultati migliori, assicurati che le risposte siano ben definite per ogni endpoint.

-n, --hostName=nomeHost

Il nome host a cui connettersi. Può anche essere un IP

-s, --hostScheme=schemaHost

La connessione all'host verrà effettuata utilizzando questo schema; es: https o http

Parametri opzionali:

-p, --hostPort=portaHost

La porta su cui l'host è in ascolto per le chiamate API, il valore predefinito è: 443

-ph, --proxyHost=hostProxy

Specifica l'host proxy per inviare le richieste tramite un proxy

-pp, --proxyPort=portaProxy

La porta del proxy, il valore predefinito è: 80

-rcn, --addNegativeRC=codiceRisposta[,codiceRisposta...]

Codici di risposta aggiuntivi da accettare negli attacchi negativi (es. attacchi con valori errati). Sono supportati più valori, separati da virgole

-rcp, --addPositiveRC=codiceRisposta[,codiceRisposta...]

Codici di risposta aggiuntivi da accettare nei controlli positivi (attacchi con valori legittimi). Sono supportati più valori, separati da virgole

Scenari di utilizzo tipici:

Vuoi verificare se la tua API è protetta da una soluzione di sicurezza API.

Esempio di esecuzione: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403

Abbiamo aggiunto il codice di risposta 403 come codice di risposta legittimo per i controlli negativi. Questo perché la soluzione di sicurezza API blocca tali richieste e restituisce uno stato 403. La specifica, d'altra parte, non definisce necessariamente una tale risposta con codice HTTP 403 per nessuno dei suoi endpoint. Ciò renderebbe tali risposte legittime, nonostante non siano nella specifica, e ti avviserebbe quando una tale risposta non viene ricevuta da un controllo negativo. Tali casi significano che sei lasciato non protetto dalla tua soluzione di sicurezza API.
Vuoi verificare come il tuo proxy mitiga gli attacchi API, ma non hai un sito reale dietro di esso.

Esempio di esecuzione: api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404

Questa volta abbiamo aggiunto il codice di stato 404 agli scenari positivi. In modo che quando uno scenario non viene bloccato, non segnaleremo un fallimento, ma accetteremo la risposta legittima 404 (risorsa non trovata).
Vuoi verificare se la tua API gestisce correttamente tutti gli input. Inoltre, vuoi eseguirlo su base notturna, o anche dopo ogni volta che uno sviluppatore invia nuovo codice al progetto.

Esempio di esecuzione: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https

Questa volta stiamo eseguendo senza esclusioni. Il file di specifica API deve dichiarare i suoi codici di risposta in modo preciso. Lo strumento accetterà solo quelli come legittimi e fallirà i controlli in caso contrario. Vedi più sotto per le condizioni di fallimento dei controlli. Esegui il comando sopra in un job Jenkins (o qualsiasi altro software CI/CD a tuo piacimento), che verrà attivato da un cron o da un'attività di push del codice del repository. Assicurati di avere installato il plugin , che dovrebbe analizzare i risultati scritti in , per una migliore visibilità nello scenario CI/CD.

Condizioni per il fallimento dei controlli

Lo strumento verifica che il codice di risposta della richiesta generata corrisponda ai codici di risposta dichiarati nello swagger. Tuttavia,
Controlli positivi: se è un errore chiaro (codice 5xx), falliamo comunque il controllo, anche se questo codice di risposta non è definito nella specifica, ma non se hai fornito un override.
Controlli negativi: se la risposta non è un errore legittimo (1xx, 2xx, 5xx), falliamo il controllo a meno che tu non abbia fornito un override. Se il codice di errore legittimo non è nella specifica, anche il controllo fallirà.
Puoi usare la definizione 'default' nella sezione delle risposte dello swagger, ma non è raccomandato. Definisci sempre le tue risposte legittime con precisione.

Condizioni per il fallimento dei controlli

Lo strumento verifica che il codice di risposta della richiesta generata corrisponda ai codici di risposta dichiarati nello swagger. Tuttavia,
Controlli positivi: se è un errore chiaro (codice 5xx), falliamo comunque il controllo, anche se questo codice di risposta non è definito nella specifica, ma non se hai fornito un override.
Controlli negativi: se la risposta non è un errore legittimo (1xx, 2xx, 5xx), falliamo il controllo. A meno che tu non abbia fornito un override. Se il codice di errore legittimo non è nella specifica, anche il controllo fallirà.
Puoi usare la definizione 'default' nella sezione delle risposte dello swagger, ma non è raccomandato. Definisci sempre le tue risposte legittime con precisione.

Output previsti:

Lo strumento utilizza il framework di reporting testng, quindi qualsiasi plugin che gestisce esecuzioni testng può essere utilizzato qui. Nota solo che i risultati vengono scritti nella cartella build/testng-results. Ovviamente può essere modificato.
Lo strumento genera richieste secondo le sue suite di controllo, e ogni richiesta verifica qualcosa di specifico. Quindi ogni controllo presenterà tutti i dettagli rilevanti nell'output della riga di comando, insieme a ciò che viene controllato, qual è la risposta e se era come previsto o meno.
Qualsiasi richiesta non valida verrà archiviata nella cartella bad_requests, in modo da poterla analizzare in seguito (ad esempio se questo viene eseguito su un server CI/CD e non hai accesso immediato alla macchina)
Alla fine, ti verrà fornito un riepilogo

Esempio di un controllo negativo fallito:

***** Testing API Endpoint *****
***** Test ID: 1575128763286-74212
Testing: Bad Property: /username (STRING), value: {, URL encoded: %7B
--> Url: /user/{
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/{ [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"username":"string","firstName":"string","lastName":"string","email":"string","password":"string","phone":"string","userStatus":0}

Perché il controllo è fallito? La richiesta ha ottenuto 200, anche se non conteneva un URL valido

Un altro esempio:

***** Testing API Endpoint *****
***** Test ID: 1575128763286-25078
Testing: Bad Property: /body/quantity (INTEGER), value: 0.4188493, URL encoded: 0.4188493
--> Url: /store/order
--> Method: POST
--> Headers: []
--> Body: {"petId":-2511515111206893939,"quantity":0.4188493,"id":698757161286106823,"shipDate":"�s","complete":"true","status":"approved"}
----------**----------
Request was: POST /store/order [Accept: application/json], Response status code: 200(UNEXPECTED)
Response (non parsed):
{"id":0,"petId":0,"quantity":0,"shipDate":"2019-11-30T15:46:03Z","status":"placed","complete":false}

Il server si aspettava di ricevere un intero, ma ha accettato un valore double. Questo potrebbe essere un buon punto per provare a sfruttare un buffer overflow nel server.

Esempio di un controllo riuscito:

***** Testing API Endpoint *****
***** Test ID: 1575128763137-43035
Testing: /user/{username}
--> Url: /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+(
--> Method: GET
--> Headers: []
----------**----------
Request was: GET /user/%E68E97EDB4Oq-(!BbG,Y$p'A-KW%65f9FA6jt5vvDz-cW.QGsLS+AA~RIHC3wgy25lDJsGzcT.;kJ+( [Accept: application/json], Response status code: 404
Response (non parsed):
{"statusCode":404,"error":"Not Found","message":"Not Found"}

Abbiamo fornito un nome utente inesistente ma legale, secondo la specifica API. Il server ha saputo gestire questa richiesta e restituire un errore legale.

Scenari di Controllo Supportati

Useremo il termine endpoint qui, come tupla URL e Metodo dell'endpoint.

Scenari Positivi

Per ogni endpoint, crea una richiesta con valori generati per tutti i suoi parametri. Questi vengono generati casualmente, ma rispettano le regole definite nella specifica API.
Per ogni endpoint, crea una richiesta con solo i parametri richiesti, con valori generati come descritto sopra.

Scenari Negativi

Per ogni endpoint, crea più richieste, ciascuna delle quali controlla un parametro diverso. Lo strumento lo fa iniettando un valore di input casuale non valido nel parametro controllato e riempiendo il resto con valori "positivi" generati nello stesso modo descritto negli scenari positivi.

Sforzo in Corso

Stiamo lavorando per migrare gli altri nostri scenari allo strumento open-source, a beneficio della comunità. Rimanete sintonizzati per gli aggiornamenti.

Estendibilità

Lo strumento è scritto in modo da rendere facile estendere la sua funzionalità di fuzzing e generazione di richieste per soddisfare le tue esigenze specifiche. Sentiti libero di suggerire qualsiasi aggiunta di cui altri potrebbero beneficiare creando una pull request.

Ottenere Aiuto

Se hai domande sulla libreria, assicurati di consultare la documentazione del codice sorgente. Se hai ancora domande, contattami via email a boris.serebro(at)imperva(dot)com.

Segnalazione di Bug

Aprire una Git Issue e includere quante più informazioni possibile. Se possibile, fornire un codice di esempio che illustri il problema che stai riscontrando. Se stai riscontrando un bug solo su un repository specifico, fornisci un link ad esso, se possibile. Non aprire una Git Issue per aiuto, solo per segnalazioni di bug.

automatic-api-attack-tool

Più Popolari