Automatisches API-Angriffstool

Impervas anpassbares API-Angriffstool nimmt eine API-Spezifikation als Eingabe und generiert und führt darauf basierende Angriffe als Ausgabe durch.

Das Tool kann eine API-Spezifikation parsen und basierend auf dem, was in der API-Spezifikation definiert ist, Fuzzing-Angriffsszenarien erstellen. Jeder Endpunkt wird mit intelligent generierten Werten innerhalb der durch die Spezifikation definierten Grenzen injiziert, und außerhalb dieser werden die entsprechenden Anfragen gesendet und deren Erfolg oder Fehlschlag detailliert gemeldet. Sie können das Tool auch erweitern, um verschiedene Sicherheitsangriffsvektoren wie illegalen Ressourcenzugriff, XSS, SQLi und RFI auszuführen, die auf die vorhandenen oder sogar nicht vorhandenen Endpunkte abzielen. Kein menschliches Eingreifen erforderlich. Einfach das Tool ausführen und die Ergebnisse erhalten.

Das Tool kann leicht erweitert werden, um verschiedene Anforderungen zu erfüllen, wie z. B. für einen Entwickler, der seine API testen möchte, oder für eine Organisation, die regelmäßige Schwachstellen- oder positive Sicherheitsscans für ihre öffentliche API durchführen möchte. Es wurde mit CI/CD im Hinterkopf entwickelt.

Anforderungen

Java 8 oder höher
Gradle

Ausführung

Checken Sie den Code von GitHub aus und führen Sie ./gradlew build oder gradlew.bat build unter Windows aus
Sie finden die ausführbare Jar-Datei im Ordner build/libs
Führen Sie java -jar imperva-api-attack-tool.jar aus, um das Hilfemenü anzuzeigen

Erstellen einer Linux-ausführbaren Datei

Kopieren Sie die Datei runnable.sh aus dem Ordner src/main/resources in dasselbe Verzeichnis wie die Jar-Datei.
Führen Sie nun aus: cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
Sie können die Datei api-attack.sh als reguläre ausführbare Datei verwenden

Verwendung

Erforderliche Parameter:

-f, --specFile=specFilePath

Die API-Spezifikationsdatei (Swagger 2.0), die ausgeführt werden soll. JSON/YAML-Format. Für bessere Ergebnisse stellen Sie sicher, dass Antworten für jeden Endpunkt gut definiert sind.

-n, --hostName=hostName

Der Hostname, zu dem eine Verbindung hergestellt werden soll. Es kann auch eine IP-Adresse sein.

-s, --hostScheme=hostScheme

Die Verbindung zum Host erfolgt über dieses Schema; z.B. https oder http

Optionale Parameter:

-p, --hostPort=hostPort

Der Port, auf dem der Host auf API-Aufrufe lauscht, Standard: 443

-ph, --proxyHost=proxyHost

Geben Sie den Proxy-Host an, um die Anfragen über einen Proxy zu senden

-pp, --proxyPort=proxyPort

Der Proxy-Port, Standard: 80

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

Zusätzliche Antwortcodes, die bei negativen Angriffen (z. B. Angriffe mit ungültigen Werten) akzeptiert werden sollen. Mehrere Werte werden durch Kommas getrennt unterstützt

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

Zusätzliche Antwortcodes, die bei positiven Prüfungen (Angriffe mit legitimen Werten) akzeptiert werden sollen. Mehrere Werte werden durch Kommas getrennt unterstützt

Typische Nutzungsszenarien:

Sie möchten überprüfen, ob Ihre API durch eine API-Sicherheitslösung geschützt ist.

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

Wir haben den Antwortcode 403 als legitimen Antwortcode für die negativen Prüfungen hinzugefügt. Dies liegt daran, dass die API-Sicherheitslösung solche Anfragen blockiert und einen 403-Status zurückgibt. Die Spezifikation definiert eine solche Antwort mit HTTP-Code 403 hingegen nicht unbedingt für einen ihrer Endpunkte. Dadurch werden solche Antworten als legitim betrachtet, obwohl sie nicht in der Spezifikation enthalten sind, und Sie werden benachrichtigt, wenn bei einer negativen Prüfung keine solche Antwort empfangen wird. Diese Fälle bedeuten, dass Sie von Ihrer API-Sicherheitslösung nicht geschützt werden.
Sie möchten überprüfen, wie Ihr Proxy API-Angriffe abwehrt, haben aber keine tatsächliche Website dahinter.

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

Dieses Mal haben wir den Statuscode 404 zu den positiven Szenarien hinzugefügt. Wenn ein Szenario nicht blockiert wird, melden wir keinen Fehler, sondern akzeptieren die legitime 404-Antwort (Ressource nicht gefunden).
Sie möchten überprüfen, ob Ihre API alle Eingaben korrekt verarbeitet. Darüber hinaus möchten Sie sie nächtlich oder sogar nach jedem Push neuen Codes durch einen Entwickler ausführen.

Beispielaufruf: api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https

Dieses Mal führen wir ohne Ausschlüsse aus. Die API-Spezifikationsdatei muss ihre Antwortcodes genau deklarieren. Das Tool akzeptiert nur diese als legitim und schlägt die Prüfungen andernfalls fehl. Siehe unten für Bedingungen zum Fehlschlagen der Prüfungen. Führen Sie den obigen Befehl in einem Jenkins-Job (oder einer anderen CI/CD-Software Ihrer Wahl) aus, der durch einen Cron oder eine Code-Push-Aktivität im Repository ausgelöst wird. Stellen Sie sicher, dass das -Plugin installiert ist, das die in geschriebenen Ergebnisse für eine bessere Sichtbarkeit im CI/CD-Szenario parsen soll.

Bedingungen für das Fehlschlagen von Prüfungen

Das Tool überprüft, ob der Antwortcode der generierten Anfrage mit den in Swagger deklarierten Antwortcodes übereinstimmt. Dennoch:
Positive Prüfungen: Bei einem eindeutigen Fehler (Code ist 5xx) wird die Prüfung trotzdem als fehlgeschlagen gewertet, selbst wenn dieser Antwortcode nicht in der Spezifikation definiert ist, es sei denn, Sie haben eine Überschreibung angegeben.
Negative Prüfungen: Wenn die Antwort kein legitimer Fehler ist (1xx, 2xx, 5xx), wird die Prüfung als fehlgeschlagen gewertet, es sei denn, Sie haben eine Überschreibung angegeben. Wenn der legitime Fehlercode nicht in der Spezifikation enthalten ist, schlägt die Prüfung ebenfalls fehl.
Sie können die default-Definition im Antwortbereich von Swagger verwenden, dies wird jedoch nicht empfohlen. Definieren Sie Ihre legitimen Antworten immer präzise.

Bedingungen für das Fehlschlagen von Prüfungen

Das Tool überprüft, ob der Antwortcode der generierten Anfrage mit den in Swagger deklarierten Antwortcodes übereinstimmt. Dennoch:
Positive Prüfungen: Bei einem eindeutigen Fehler (Code ist 5xx) wird die Prüfung trotzdem als fehlgeschlagen gewertet, selbst wenn dieser Antwortcode nicht in der Spezifikation definiert ist, es sei denn, Sie haben eine Überschreibung angegeben.
Negative Prüfungen: Wenn die Antwort kein legitimer Fehler ist (1xx, 2xx, 5xx), wird die Prüfung als fehlgeschlagen gewertet. Es sei denn, Sie haben eine Überschreibung angegeben. Wenn der legitime Fehlercode nicht in der Spezifikation enthalten ist, schlägt die Prüfung ebenfalls fehl.
Sie können die default-Definition im Antwortbereich von Swagger verwenden, dies wird jedoch nicht empfohlen. Definieren Sie Ihre legitimen Antworten immer präzise.

Erwartete Ausgaben:

Das Tool verwendet das TestNG-Berichtsframework, sodass jedes Plugin, das TestNG-Ausführungen verarbeitet, hier verwendet werden kann. Beachten Sie nur, dass die Ergebnisse im Ordner build/testng-results geschrieben werden. Dies kann natürlich geändert werden.
Das Tool generiert Anfragen gemäß seinen Prüfungs‑Suites, und jede Anfrage prüft etwas Spezifisches. Jede Prüfung zeigt alle relevanten Details in der Befehlszeilenausgabe an, zusammen mit dem, was überprüft wird, wie die Antwort aussieht und ob sie erwartungsgemäß war.
Alle fehlerhaften Anfragen werden im Ordner bad_requests gespeichert, damit Sie sie später analysieren können (z. B. wenn dies auf einem CI/CD-Server läuft und Sie keinen sofortigen Zugriff auf die Maschine haben).
Am Ende erhalten Sie eine Zusammenfassung.

Beispiel für eine fehlgeschlagene negative Prüfung:

***** 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}

Warum schlug die Prüfung fehl? Die Anfrage erhielt 200, obwohl sie keine gültige URL enthielt.

Ein weiteres Beispiel:

***** 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}

Der Server erwartete eine ganze Zahl, akzeptierte aber einen Gleitkommawert. Dies könnte ein guter Ansatzpunkt sein, um einen Pufferüberlauf auf dem Server auszunutzen.

Beispiel für eine erfolgreiche Prüfung:

***** 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"}

Wir haben einen nicht existierenden, aber gemäß der API-Spezifikation gültigen Benutzernamen angegeben. Der Server wusste, wie er diese Anfrage zu behandeln hat, und gab einen legitimen Fehler zurück.

Unterstützte Prüfszenarien

Wir verwenden hier den Begriff Endpunkt als Tupel aus Endpunkt-URL und Methode.

Positive Szenarien

Für jeden Endpunkt wird eine Anfrage mit generierten Werten für alle Parameter erstellt. Diese werden zufällig generiert, befolgen jedoch die in der API-Spezifikation definierten Regeln.
Für jeden Endpunkt wird eine Anfrage mit nur den erforderlichen Parametern erstellt, wobei die Werte wie oben beschrieben generiert werden.

Negative Szenarien

Für jeden Endpunkt werden mehrere Anfragen erstellt, von denen jede einen anderen Parameter prüft. Das Tool injiziert einen zufälligen ungültigen Eingabewert in den geprüften Parameter und füllt die restlichen mit "positiven" Werten, die auf die gleiche Weise wie in den positiven Szenarien generiert werden.

Laufende Bemühungen

Wir arbeiten daran, unsere anderen Szenarien in das Open-Source-Tool zu überführen, zum Wohle der Community. Bleiben Sie auf dem Laufenden für Updates.

Erweiterbarkeit

Das Tool ist so geschrieben, dass es einfach ist, seine Fuzzing- und Anfragegenerierungsfunktionen zu erweitern, um Ihre spezifischen Anforderungen zu erfüllen. Fühlen Sie sich frei, Ergänzungen vorzuschlagen, von denen andere profitieren könnten, indem Sie einen Pull-Request erstellen.

Hilfe erhalten

Wenn Sie Fragen zur Bibliothek haben, lesen Sie unbedingt die Quellcode-Dokumentation. Wenn Sie immer noch Fragen haben, kontaktieren Sie mich per E-Mail unter boris.serebro(at)imperva(dot)com.

Fehler melden

Bitte öffnen Sie ein Git-Issue und fügen Sie so viele Informationen wie möglich hinzu. Geben Sie nach Möglichkeit einen Beispielcode an, der das Problem veranschaulicht. Wenn Sie einen Fehler nur in einem bestimmten Repository erleben, geben Sie nach Möglichkeit einen Link dazu an. Öffnen Sie kein Git-Issue für Hilfe, sondern nur für Fehlermeldungen.

automatic-api-attack-tool

Beliebteste