imperva/automatic-api-attack-toolImpervas anpassbares API-Angriffstool nimmt eine API-Spezifikation als Eingabe, generiert und führt darauf basierende Angriffe als Ausgabe aus.
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.
./gradlew build oder gradlew.bat build unter Windows ausbuild/libsjava -jar imperva-api-attack-tool.jar aus, um das Hilfemenü anzuzeigenrunnable.sh aus dem Ordner src/main/resources in dasselbe Verzeichnis wie die Jar-Datei.cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.shapi-attack.sh als reguläre ausführbare Datei verwenden-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
-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
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 TestNG-Plugin installiert ist, das die in build/testng-results geschriebenen Ergebnisse für eine bessere Sichtbarkeit im CI/CD-Szenario parsen soll.
Sie möchten überprüfen, ob diese API möglicherweise für Fuzzing-Versuche offen ist. Führen Sie einfach das Tool aus und überprüfen Sie die gemeldeten Fehlschläge.
Beispielaufruf: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https
Sie möchten überprüfen, ob Ihre API serverseitig korrekt implementiert ist oder ob ihre Definition der Serverimplementierung entspricht.
Beispielaufruf: api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https
default-Definition im Antwortbereich von Swagger verwenden, dies wird jedoch nicht empfohlen. Definieren Sie Ihre legitimen Antworten immer präzise.default-Definition im Antwortbereich von Swagger verwenden, dies wird jedoch nicht empfohlen. Definieren Sie Ihre legitimen Antworten immer präzise.