Day #26 of
#100DaysOfCyber | Sécurité Dev : Le Reverse Engineering d’API
Hier, on a vu comment une documentation d'API oubliée en prod pouvait détruire la sécurité d'un site.
Mais en situation réelle, la doc est souvent désactivée. Alors, comment fait un pentester pour attaquer une API s'il n'a pas le mode d'emploi ?
C'est là qu'intervient le
#Reverse #Engineering d'API.
Le concept est simple : on va observer passivement comment l'application frontend discute avec son backend pour deviner et reconstruire la structure de l'API, ses routes et ses paramètres cachés.
3 étapes pour Reverse Engineering d'API :
➖ 1. L'analyse du trafic : On utilise un proxy comme Burp Suite pour intercepter toutes les requêtes HTTP/HTTPS générées lorsqu'on clique sur le site. On note la structure des URLs (ex: /api/v2/products/10) et le format des données (JSON, XML).
➖ 2. Deviner la structure : Les développeurs suivent souvent des conventions de nommage (REST).
Si on voit une route GET /api/v1/users/42, on peut légitimement tester l'existence de :
- GET /api/v1/users (pour lister)
- POST /api/v1/users (pour créer)
- DELETE /api/v1/users/42 (pour supprimer)
➖ 3. Le Fuzzing de paramètres : Même sans doc, on peut deviner les variables acceptées par le backend. Si une mise à jour de profil envoie {"name": "Mahmoud"}, on va tenter d'injecter des clés cachées comme {"role": "admin"} ou {"is_premium": true} (le Mass Assignment) pour voir comment le serveur réagit.
Pourquoi c'est crucial pour un Dev ?
Beaucoup de devs pensent encore que si une route d'API n'est pas écrite sur le site ou dans une doc publique, personne ne la trouvera.
Un attaquant motivé mettra quelques mn surtout avec les outils à cartographier vos endpoints backend juste en regardant les requêtes réseau de son navigateur.
C'est pourquoi il faut un contrôle d'accès strict sur chaque route, documentée ou non
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@_makh0u
#Cybersecurity #WebSecurity #APISecurity #ReverseEngineering #PortSwigger #Backend #FullStack