Outil d'Attaque Automatique d'API

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.

Prérequis

• Java 8 ou supérieur
• Gradle

Exécution

• Récupérez le code depuis GitHub et exécutez ./gradlew build ou gradlew.bat build sous Windows
• Vous trouverez le fichier JAR exécutable dans le dossier build/libs
• Exécutez java -jar imperva-api-attack-tool.jar pour afficher le menu d'aide

Création d'un exécutable Linux

• Copiez le fichier runnable.sh depuis le dossier src/main/resources dans le même répertoire que le fichier JAR.
• Exécutez maintenant : cat runnable.sh imperva-api-attack-tool.jar > api-attack.sh && chmod +x api-attack.sh
• Vous pouvez utiliser le fichier api-attack.sh comme un exécutable standard

Utilisation

Paramètres obligatoires :

-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

Paramètres optionnels :

-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

Scénarios d'utilisation typiques :

• 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 TestNG, qui doit analyser les résultats écrits dans build/testng-results pour une meilleure visibilité dans le scénario CI/CD.

• Vous 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

Conditions d'échec des vérifications

• L'outil vérifie que le code de réponse de la requête générée correspond aux codes de réponse déclarés dans le swagger. Cependant,
• Vérifications positives : s'il s'agit d'une erreur manifeste (code 5xx), nous ferons échouer la vérification, même si ce code de réponse n'est pas défini dans la spécification, sauf si vous avez fourni une substitution.
• Vérifications négatives : si la réponse n'est pas une erreur légitime (1xx, 2xx, 5xx), nous faisons échouer la vérification, sauf si vous avez fourni une substitution. Si le code d'erreur légitime n'est pas dans la spécification, la vérification échouera également.
• Vous pouvez utiliser la définition 'default' dans la section des réponses du swagger, mais ce n'est pas recommandé. Définissez toujours précisément vos réponses légitimes.

Conditions d'échec des vérifications

• L'outil vérifie que le code de réponse de la requête générée correspond aux codes de réponse déclarés dans le swagger. Cependant,
• Vérifications positives : s'il s'agit d'une erreur manifeste (code 5xx), nous ferons échouer la vérification, même si ce code de réponse n'est pas défini dans la spécification, sauf si vous avez fourni une substitution.
• Vérifications négatives : si la réponse n'est pas une erreur légitime (1xx, 2xx, 5xx), nous faisons échouer la vérification. Sauf si vous avez fourni une substitution. Si le code d'erreur légitime n'est pas dans la spécification, la vérification échouera également.
• Vous pouvez utiliser la définition 'default' dans la section des réponses du swagger, mais ce n'est pas recommandé. Définissez toujours précisément vos réponses légitimes.