Pentesting d'API Web

Reading time: 7 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Résumé de la méthodologie de Pentesting des API

Le pentesting des APIs implique une approche structurée pour découvrir des vulnérabilités. Ce guide résume une méthodologie complète, en mettant l'accent sur des techniques et outils pratiques.

Comprendre les types d'API

  • SOAP/XML Web Services : Utilisent le format WSDL pour la documentation, typiquement accessible via des chemins ?wsdl. Des outils comme SOAPUI et WSDLer (Burp Suite Extension) sont utiles pour parser et générer des requêtes. Exemple de documentation accessible sur DNE Online.
  • REST APIs (JSON) : La documentation peut être fournie dans des fichiers WADL, mais des outils comme Swagger UI offrent une interface plus conviviale pour l'interaction. Postman est utile pour créer et gérer des requêtes d'exemple.
  • GraphQL : Un language de requête pour les APIs offrant une description complète et compréhensible des données de votre API.

Labs de pratique

  • VAmPI : Une API délibérément vulnérable pour la pratique, couvrant les vulnérabilités OWASP top 10 pour les API.

Astuces efficaces pour le Pentesting d'API

  • SOAP/XML Vulnerabilities : Cherchez des vulnérabilités XXE, bien que les déclarations DTD soient souvent restreintes. Les balises CDATA peuvent permettre l'insertion de payloads si le XML reste valide.
  • Escalade de privilèges : Testez des endpoints avec différents niveaux de privilèges pour identifier des possibilités d'accès non autorisé.
  • Mauvaise configuration CORS : Examinez les paramètres CORS pour une potentielle exploitabilité via des attaques CSRF depuis des sessions authentifiées.
  • Découverte d'endpoints : Exploitez les patterns d'API pour découvrir des endpoints cachés. Des outils comme les fuzzers peuvent automatiser ce processus.
  • Manipulation de paramètres : Expérimentez en ajoutant ou remplaçant des paramètres dans les requêtes pour accéder à des données ou fonctionnalités non autorisées.
  • Test des méthodes HTTP : Variez les méthodes de requête (GET, POST, PUT, DELETE, PATCH) pour découvrir des comportements inattendus ou des fuites d'information.
  • Manipulation du Content-Type : Passez d'un content type à un autre (x-www-form-urlencoded, application/xml, application/json) pour tester des problèmes de parsing ou des vulnérabilités.
  • Techniques avancées sur les paramètres : Testez avec des types de données inattendus dans les payloads JSON ou jouez avec des données XML pour des injections XXE. Essayez aussi la pollution de paramètres et les caractères wildcard pour des tests plus larges.
  • Test de versions : Les anciennes versions d'API peuvent être plus vulnérables. Vérifiez toujours et testez plusieurs versions d'API.

Autorisation & logique métier (AuthN != AuthZ) — pièges de tRPC/Zod protectedProcedure

Les stacks TypeScript modernes utilisent couramment tRPC avec Zod pour la validation d'entrée. Dans tRPC, protectedProcedure garantit généralement que la requête possède une session valide (authentification) mais n'implique pas que l'appelant ait le rôle/permissions appropriés (autorisation). Ce décalage mène à Broken Function Level Authorization/BOLA si des procédures sensibles ne sont protégées que par protectedProcedure.

  • Modèle de menace : Tout utilisateur authentifié à faible privilège peut appeler des procédures de niveau admin si les vérifications de rôle manquent (par ex. migrations en arrière-plan, feature flags, maintenance globale du tenant, contrôle de jobs).
  • Signal en boîte noire : Endpoints POST /api/trpc/<router>.<procedure> qui réussissent pour des comptes basiques alors qu'ils devraient être réservés aux admins. Les inscriptions en self-service augmentent fortement l'exploitabilité.
  • Forme typique de route tRPC (v10+) : corps JSON encapsulé sous {"input": {...}}.

Exemple de modèle vulnérable (pas de contrôle de rôle/permission) :

ts
// The endpoint for retrying a migration job
// This checks for a valid session (authentication)
retry: protectedProcedure
// but not for an admin role (authorization).
.input(z.object({ name: z.string() }))
.mutation(async ({ input, ctx }) => {
// Logic to restart a sensitive migration
}),

Exploitation pratique (black-box)

  1. Créer un compte normal et obtenir une session authentifiée (cookies/headers).
  2. Énumérer les background jobs ou d'autres ressources sensibles via les procédures “list”/“all”/“status”.
bash
curl -s -X POST 'https://<tenant>/api/trpc/backgroundMigrations.all' \
-H 'Content-Type: application/json' \
-b '<AUTH_COOKIES>' \
--data '{"input":{}}'
  1. Invoquer des actions privilégiées telles que redémarrer un job :
bash
curl -s -X POST 'https://<tenant>/api/trpc/backgroundMigrations.retry' \
-H 'Content-Type: application/json' \
-b '<AUTH_COOKIES>' \
--data '{"input":{"name":"<migration_name>"}}'

Impact à évaluer

  • Corruption de données via des redémarrages non-idempotents : Forcer l'exécution concurrente de migrations/workers peut créer des conditions de course et des états partiels incohérents (perte silencieuse de données, analytics cassés).
  • DoS via worker/DB starvation : En déclenchant de manière répétée des jobs lourds, on peut épuiser les pools de workers et les connexions à la base de données, provoquant des pannes affectant tout le tenant.

Outils et ressources pour l'API Pentesting

  • kiterunner: Excellent pour découvrir des endpoints d'API. Use it to scan and brute force paths and parameters against target APIs.
bash
kr scan https://domain.com/api/ -w routes-large.kite -x 20
kr scan https://domain.com/api/ -A=apiroutes-220828 -x 20
kr brute https://domain.com/api/ -A=raft-large-words -x 20 -d=0
kr brute https://domain.com/api/ -w /tmp/lang-english.txt -x 20 -d=0
  • https://github.com/BishopFox/sj: sj est un outil en ligne de commande conçu pour aider à l'audit des fichiers de définition Swagger/OpenAPI exposés en vérifiant les endpoints API associés pour une authentification faible. Il fournit également des modèles de commandes pour des tests de vulnérabilité manuels.
  • Des outils supplémentaires comme automatic-api-attack-tool, Astra, et restler-fuzzer offrent des fonctionnalités adaptées pour les tests de sécurité API, allant de la simulation d'attaques au fuzzing et à l'analyse de vulnérabilités.
  • Cherrybomb: C'est un outil de sécurité API qui audite votre API à partir d'un fichier OAS (l'outil est écrit en Rust).

Ressources d'apprentissage et de pratique

  • OWASP API Security Top 10: Lecture essentielle pour comprendre les vulnérabilités API courantes (OWASP Top 10).
  • API Security Checklist: Une checklist complète pour sécuriser les API (GitHub link).
  • Logger++ Filters: Pour chasser les vulnérabilités API, Logger++ propose des filtres utiles (GitHub link).
  • API Endpoints List: Une liste organisée de endpoints API potentiels pour les tests (GitHub gist).

Références

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks