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 TestNG, che dovrebbe analizzare i risultati scritti in build/testng-results, per una migliore visibilità nello scenario CI/CD.

• Vuoi verificare se questa API potrebbe essere vulnerabile a tentativi di fuzzing. Basta eseguire lo strumento e controllare i fallimenti segnalati.

  Esempio di esecuzione: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

• Vuoi verificare se la tua API è implementata correttamente lato server, o se la sua definizione corrisponde all'implementazione del server.

  Esempio di esecuzione: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https

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.