---
timestamp: "00:00"
marker: "!"
title: "Introduction aux SSRF et configuration initiale"
quote: "C'est un exemple classique de vulnérabilités SSRF... la première chose que tout pentester vérifierait est l'hôte local."
details:
L'utilisation du navigateur intégré à Burp Suite permet de capturer toutes les requêtes HTTP pour analyse. Bien que la version professionnelle soit utilisée ici, l'édition communautaire gratuite suffit pour la plupart des exercices. La démonstration commence par l'interception d'une requête POST vers /product/stock qui contient un paramètre API_stock prenant une URL comme valeur. Cette URL pointe vers un système interne (http://stock.shop.net:8080), révélant immédiatement une potentielle vulnérabilité SSRF (Server-Side Request Forgery).
L'analyse montre que ce paramètre URL n'est pas correctement validé, permettant potentiellement d'accéder à des ressources internes. L'exemple concret donné est la suppression d'un utilisateur (Carlos) en redirigeant la requête vers l'interface d'administration interne, confirmant ainsi la vulnérabilité. Cette démonstration illustre comment une application publique peut servir de pont pour attaquer des systèmes internes en exploitant les relations de confiance entre composants.
La méthodologie typique d'exploitation SSRF est expliquée : vérification de l'hôte local en premier, puis scan de ports sur d'autres serveurs internes, et enfin recherche de vulnérabilités permettant l'exécution de code à distance. Cette approche progressive sera développée dans les laboratoires suivants.
---
---
timestamp: "00:01"
marker: "!"
title: "Présentation des concepts SSRF et contexte de formation"
quote: "La falsification de requêtes côté serveur est l'un des risques de sécurité les plus critiques auxquels sont confrontées les applications Web aujourd'hui."
details:
L'intervenant Rena Kalil présente sa chaîne YouTube dédiée à la sécurité web, couvrant en profondeur diverses vulnérabilités comme les injections SQL, les injections de commandes, et particulièrement les SSRF qui font partie du Top 10 des risques critiques identifiés par l'OWASP. Ces vulnérabilités permettent à un attaquant d'exploiter les relations de confiance entre systèmes pour accéder à des ressources internes.
Différents formats d'apprentissage sont proposés : contenu gratuit sur YouTube, cours structurés sur Udemy avec support, et une Académie offrant un accès complet à tous les contenus avec support via Discord. Cette approche pédagogique vise à rendre la sécurité accessible à différents niveaux de budget et d'engagement.
L'importance des SSRF est soulignée par des cas réels comme la fuite de données chez Capital One, où cette vulnérabilité a permis d'accéder à des millions de données sensibles. L'expertise de l'intervenant, basée sur son expérience en consulting, apporte une crédibilité pratique aux concepts théoriques présentés.
---
---
timestamp: "00:03"
marker: "!"
title: "Modélisation d'une application vulnérable aux SSRF"
quote: "Que se passe-t-il si ces paramètres... sont contrôlables par l'utilisateur et ne sont pas correctement validés en arrière-plan ?"
details:
Un scénario d'application e-commerce moderne est présenté, avec une architecture distribuée comprenant une application publique, un système interne de gestion des stocks, et un service tiers de paiement. Cette séparation fonctionnelle crée des relations de confiance qui peuvent être exploitées via SSRF.
Deux fonctionnalités critiques sont analysées : la vérification du stock (via requête interne) et le processus d'achat (délégué à un service externe). L'accent est mis sur le manque fréquent de validation des URL dans ces requêtes intersystèmes, permettant à un attaquant de détourner ces fonctionnalités pour accéder à d'autres ressources.
L'exemple montre comment modifier l'URL de vérification de stock pour accéder à une interface d'administration interne, contournant ainsi les contrôles d'accès. L'impact potentiel est triple : atteinte à la confidentialité (accès aux données), à l'intégrité (modification/suppression) et à la disponibilité (perturbation des services).
---
---
timestamp: "00:06"
marker: "!"
title: "Techniques avancées d'exploitation SSRF"
quote: "Je pourrais commencer à enchaîner les vulnérabilités... exploiter la SSRF pour effectuer un contournement d'authentification."
details:
Au-delà de l'accès simple à des interfaces internes, les SSRF permettent des attaques plus sophistiquées comme le scanning de ports sur le réseau interne pour identifier d'autres services vulnérables. Un exemple est donné avec la découverte d'un serveur ColdFusion vulnérable à un contournement d'authentification.
Le chaining de vulnérabilités est expliqué : combiner une SSRF avec d'autres failles (comme Shellshock) pour obtenir une exécution de code à distance. Cette technique est comparée à l'attaque réelle contre Capital One où la SSRF a permis d'accéder aux métadonnées EC2 puis à des buckets S3.
La distinction entre SSRF "inband" (réponse visible directement) et "aveugle" (nécessitant l'exfiltration des données) est introduite, préparant le terrain pour les laboratoires pratiques qui suivront ces différents scénarios.
---
---
timestamp: "00:11"
marker: "!"
title: "Laboratoire 1 : SSRF de base contre le serveur local"
quote: "Modifiez l'URL de vérification des stocks pour accéder à l'interface d'administration sur localhost."
details:
Le premier laboratoire pratique présente une application avec une fonctionnalité de vérification de stock vulnérable. La solution consiste à modifier le paramètre URL pour pointer vers localhost/admin, permettant ainsi d'accéder à une interface d'administration interne normalement inaccessible.
La méthodologie pas à pas inclut : l'interception de la requête avec Burp, l'identification du paramètre vulnérable, la modification de l'URL cible, et la confirmation de la vulnérabilité par la suppression réussie d'un utilisateur. Cette approche démontre comment exploiter une SSRF sans authentification préalable.
Une observation importante est notée : l'accès direct à l'interface admin est bloqué, mais possible via la SSRF, illustrant la relation de confiance entre l'application publique et les composants internes. Ce pattern est courant dans les architectures microservices modernes.