imperva/automatic-api-attack-toolL'outil d'attaque API personnalisable d'Imperva prend en entrée une spécification API, génère et exécute des attaques basées sur celle-ci en sortie.
L'outil d'attaque d'API personnalisable d'Imperva prend une spécification d'API en entrée, et génère et exécute des attaques basées sur celle-ci en sortie.
L'outil est capable d'analyser une spécification d'API et de créer des scénarios d'attaque par fuzzing en fonction de ce qui est défini dans la spécification. Chaque point d'accès (endpoint) est injecté avec des valeurs intelligemment générées dans les limites définies par la spécification, et en dehors de celles-ci, les requêtes appropriées sont envoyées et leur succès ou échec sont rapportés de manière détaillée. Vous pouvez également l'étendre pour exécuter divers vecteurs d'attaque de sécurité, tels que l'accès illégal aux ressources, XSS, SQLi et RFI, ciblant les points d'accès existants, ou même inexistants. Aucune intervention humaine n'est nécessaire. Exécutez simplement l'outil et obtenez les résultats.
L'outil peut être facilement étendu pour s'adapter à divers besoins, comme pour un développeur souhaitant tester son API, ou une organisation voulant effectuer des analyses de vulnérabilité régulières ou des tests de sécurité positifs sur son API publique. Il est conçu pour être intégré dans une chaîne CI/CD.
./gradlew build ou gradlew.bat build sous Windowsjava -jar imperva-api-attack-tool.jar pour afficher le menu d'aiderunnable.sh depuis le dossier src/main/resources dans le même répertoire que le fichier JAR.cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh-f, --specFile=cheminFichierSpec
Le fichier de spécification API (swagger 2.0) sur lequel exécuter l'outil. Format JSON/YAML. Pour de meilleurs résultats, assurez-vous que les réponses sont bien définies pour chaque point d'accès.
-n, --hostName=nomHôte
Le nom d'hôte auquel se connecter. Il peut aussi s'agir d'une adresse IP
-s, --hostScheme=schémaHôte
La connexion à l'hôte se fera en utilisant ce schéma ; ex : https ou http
-p, --hostPort=portHôte
Le port sur lequel l'hôte écoute pour les appels API, par défaut : 443
-ph, --proxyHost=proxyHôte
Spécifiez l'hôte proxy pour envoyer les requêtes via un proxy
-pp, --proxyPort=proxyPort
Le port du proxy, par défaut : 80
-rcn, --addNegativeRC=codeRéponse[,codeRéponse...]
Codes de réponse supplémentaires acceptés dans les attaques négatives (ex. attaques avec valeurs invalides). Plusieurs valeurs séparées par des virgules sont prises en charge
-rcp, --addPositiveRC=codeRéponse[,codeRéponse...]
Codes de réponse supplémentaires acceptés dans les vérifications positives (attaques avec valeurs légitimes). Plusieurs valeurs séparées par des virgules sont prises en charge
Vous souhaitez vérifier si votre API est protégée par une solution de sécurité API.
Exemple d'exécution : api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -rcn=403
Nous avons ajouté le code de réponse 403 comme code légitime pour les vérifications négatives. En effet, la solution de sécurité API bloque ces requêtes et renvoie un statut 403. La spécification, quant à elle, ne définit pas nécessairement une telle réponse avec un code HTTP 403 pour l'un de ses points d'accès. Cela rendrait ces réponses légitimes, même si elles ne figurent pas dans la spécification, et vous alerterait lorsqu'une telle réponse n'est pas reçue lors d'une vérification négative. De tels cas signifient que vous n'êtes pas protégé par votre solution de sécurité API.
Vous souhaitez vérifier comment votre proxy atténue les attaques API, mais vous n'avez pas de site réel derrière lui.
Exemple d'exécution : api-attack.sh -f swaggerPetStore.json -n myapisite.com -s http -ph 127.0.0.1 -pp=4010 -rcn=403 -rcp=404
Cette fois, nous avons ajouté le code de statut 404 aux scénarios positifs. Ainsi, lorsqu'un scénario n'est pas bloqué, nous ne signalerons pas un échec, mais accepterons la réponse légitime 404 (ressource non trouvée).
Vous souhaitez vérifier si votre API gère correctement toutes les entrées. De plus, vous souhaitez l'exécuter chaque nuit, ou même après chaque push de nouveau code par un développeur.
Exemple d'exécution : api-attack.sh -f myapi_swagger.yaml -n staging.myorg.com -s https
Cette fois, nous exécutons sans aucune exclusion. Le fichier de spécification API doit déclarer précisément ses codes de réponse. L'outil n'acceptera que ceux-ci comme légitimes et fera échouer les vérifications dans le cas contraire. Voir ci-dessous les conditions d'échec des vérifications. Exécutez la commande ci-dessus dans un job Jenkins (ou tout autre logiciel CI/CD de votre choix), qui sera déclenché par une tâche cron ou une activité de push de code dans le dépôt. Assurez-vous d'avoir installé le plugin , qui doit analyser les résultats écrits dans pour une meilleure visibilité dans le scénario CI/CD.
bad_requests, afin que vous puissiez les analyser ultérieurement (par exemple, si cela s'exécute sur un serveur CI/CD et que vous n'avez pas un accès immédiat à la machine).***** 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}
Pourquoi la vérification a-t-elle échoué ? La requête a reçu un 200, alors qu'elle ne contenait pas une URL valide.
***** 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}
Le serveur s'attendait à recevoir un entier, mais a accepté une valeur double. Cela pourrait être un bon endroit pour essayer d'exploiter un dépassement de tampon dans le serveur.
***** 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"}
Nous avons fourni un nom d'utilisateur inexistant mais légal, selon la spécification de l'API. Le serveur a su gérer cette requête et renvoyer une erreur légale.
Nous utiliserons le terme point d'accès (endpoint) ici, en tant que couple URL de point d'accès et méthode HTTP.
Nous travaillons à la migration de nos autres scénarios vers l'outil open-source, pour le bénéfice de la communauté. Restez à l'écoute pour les mises à jour.
L'outil est conçu de manière à faciliter l'extension de ses fonctionnalités de fuzzing et de génération de requêtes pour répondre à vos besoins spécifiques. N'hésitez pas à suggérer des ajouts qui pourraient bénéficier à d'autres en créant une pull request.
Si vous avez des questions sur la bibliothèque, n'oubliez pas de consulter la documentation du code source. Si vous avez encore des questions, contactez-moi par e-mail à boris.serebro(at)imperva(dot)com.
Veuillez ouvrir une Issue Git et inclure autant d'informations que possible. Si possible, fournissez un exemple de code illustrant le problème que vous rencontrez. Si vous rencontrez un bogue sur un dépôt spécifique uniquement, fournissez un lien vers celui-ci, si possible. N'ouvrez pas une Issue Git pour de l'aide, uniquement pour des rapports de bogues.
TestNGbuild/testng-resultsVous souhaitez vérifier si cette API est potentiellement vulnérable à des tentatives de fuzzing. Exécutez simplement l'outil et examinez les échecs signalés.
Exemple d'exécution : api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https
Vous souhaitez vérifier si votre API est correctement implémentée côté serveur, ou si sa définition correspond à l'implémentation du serveur.
Exemple d'exécution : api-attack.sh -f publiclyAvailableSwaggerOfAPI.yaml -n api.corporate.com -s https