Day #11 of
#100DaysOfCyber | Exploitation d'un
#SSRF
Avant hier, on a vu la théorie derrière le SSRF (Server-Side Request Forgery). Aujourd'hui, place au lab pratique de PortSwigger pour voir comment ça se passe concrètement dans Burp Suite.
Le scénario : L'application propose une fonctionnalité pour vérifier le stock d'un produit. Pour ce faire, le backend prend un paramètre nommé stockApi contenant une URL, effectue la requête HTTP lui-même, puis renvoie le résultat au client.
C'est le paradis pour un attaquant si l'entrée n'est pas nettoyée.
L'exploitation en 2 étapes :
- Reconnaissance interne (localhost) : En interceptant la requête avec Burp, on modifie la valeur de stockApi pour cibler l'interface locale du serveur : http://localhost/admin.
Le serveur s'exécute, interroge sa propre interface d'administration (normalement inaccessible depuis Internet) et nous renvoie gentiment le code HTML.
On découvre les routes d'administration, notamment celle permettant de supprimer des utilisateurs.
L'attaque (Suppression de compte) : Maintenant qu'on connaît la structure de la route sensible, on pousse le serveur à exécuter l'action destructrice à notre place. Il suffit d'envoyer : stockApi=http://localhost/admin/delete?username=carlos. Le serveur traite la demande en local avec ses propres privilèges d'admin, et le compte de Carlos est supprimé. Lab validé.
#Le serveur fait aveuglément confiance aux requêtes qui viennent de 127.0.0.1 ou localhost, pensant qu'elles viennent forcément d'un admin légitime connecté en interne.
C'est pour ça qu'interdire explicitement les IP privées et valider les URL via une liste blanche stricte côté backend est non négociable.
#Un dev qui comprend la sécurité.
#Un pentester qui comprend le code.
@PamIbrahimaBaba @_makh0u @guissehMaabo @sudo_su_ @LebzoDev
#Cybersecurity #WebSecurity #SSRF #PortSwigger #Pentest #BurpSuite #Backend #FullStack