La SSRF : falsification de requête côté serveur

Certaines applications ont pour fonction de aller chercher quelque chose pour vous : afficher l’aperçu d’un lien, importer une image depuis une adresse, vérifier un service externe, générer un PDF à partir d’une page. Pour cela, c’est le serveur qui émet une requête vers l’adresse fournie. Imaginez un coursier à qui l’on dit « va chercher ce colis à cette adresse ». Si personne ne vérifie l’adresse, on peut l’envoyer dans des endroits où lui seul a le droit d’entrer, et dont vous ignorez l’existence : le sous-sol de l’entreprise, l’armoire du directeur. C’est la SSRF (Server-Side Request Forgery).

Le principe

Une application accepte une adresse (ou un nom d’hôte) fournie par l’utilisateur et émet une requête vers elle depuis le serveur. La requête n’est donc pas faite depuis le poste de l’utilisateur, mais depuis une machine placée à l’intérieur du réseau de l’organisation, souvent plus privilégiée :

• elle peut atteindre des services internes invisibles depuis Internet (tableaux de bord d’administration, bases de données, services de supervision) ;
• elle bénéficie de la confiance réseau dont jouissent les machines internes entre elles ;
• elle peut atteindre des interfaces de métadonnées d’environnements cloud, accessibles uniquement depuis la machine elle-même, qui peuvent livrer des informations d’identification ;
• elle peut servir de relais pour « scanner » le réseau interne, en observant les différences de réponse.

Un schéma simplifié :

Utilisateur  --(adresse fournie)-->  Application web (serveur)  --(requête)-->  Ressource
                                         |                                      interne ou externe
                                         +--- le serveur fait la requête à la place de l'utilisateur

Où se cachent les fonctions à risque

Dans votre carte de l’application, repérez tout paramètre dont la valeur ressemble à une adresse (url=, image=, callback=, source=).

Comment un auditeur raisonne, sans toucher d’adresses réelles

Le test d’une SSRF doit être particulièrement mesuré, car il peut atteindre des systèmes que l’on n’a pas le droit de toucher. La démarche :

1. Vérifier le périmètre : les systèmes internes sont-ils inclus dans la mission ? Sinon, on s’arrête au constat de principe, sans chercher à les atteindre.
2. Détecter si le serveur émet une requête, avec un service que vous contrôlez, dans votre laboratoire : votre propre serveur de test enregistre les connexions entrantes. Si l’application vient y frapper, la fonction est confirmée.
3. Observer les différences de comportement : réponse affichée ou non (SSRF dite « complète » ou « aveugle »), messages d’erreur, temps de réponse.
4. Raisonner sur l’impact à partir de ce que le serveur pourrait joindre dans votre architecture de laboratoire (une seconde machine virtuelle représentant un « service interne »).
5. Documenter sans collecter d’informations sensibles réelles.

Dans un labo, la configuration idéale comporte deux machines virtuelles : l’application vulnérable et une machine « interne » qui n’est pas joignable directement depuis votre poste. La démonstration de la faille consiste à montrer que l’application, elle, peut la joindre : preuve de l’impact sans aucun risque pour un tiers.

Pourquoi les contrôles naïfs échouent

Quelques défenses insuffisantes, que les auditeurs rencontrent souvent :

• Une liste noire d’adresses internes : il existe de nombreuses écritures équivalentes d’une même adresse (formats alternatifs, noms de domaine qui pointent vers une adresse interne, redirections). Les listes noires sont fragiles.
• Vérifier le nom avant la requête : le nom peut pointer vers une adresse interne au moment de la requête (la résolution DNS peut changer entre le contrôle et l’utilisation).
• Suivre les redirections : un site externe « autorisé » peut rediriger la requête vers une adresse interne.
• Se contenter de filtrer la réponse : la requête a déjà été émise, avec ses effets éventuels.

Les défenses efficaces

• Liste blanche stricte de destinations quand c’est possible : seules quelques adresses ou domaines sont autorisés. Mieux : ne pas accepter d’adresse libre, mais un identifiant que le serveur traduit en destination connue.
• Valider le schéma (seul le HTTPS, par exemple) et refuser les protocoles inutiles.
• Résoudre le nom, vérifier l’adresse obtenue, puis se connecter à cette adresse précise, en refusant les plages réservées (privées, locales, de métadonnées).
• Désactiver ou contrôler les redirections.
• Segmenter le réseau : le serveur d’application ne doit pas pouvoir joindre les services internes dont il n’a pas besoin (règles de pare-feu sortantes). C’est la défense de fond.
• Protéger les interfaces de métadonnées cloud avec les mécanismes d’authentification renforcée proposés par le fournisseur, et limiter les droits associés à l’identité de la machine (moindre privilège).
• Ne pas renvoyer les réponses brutes à l’utilisateur ; journaliser les requêtes sortantes.

// Principe : l'utilisateur choisit un identifiant, pas une adresse
$sources = [
    'actualites' => 'https://flux.exemple.test/actualites.xml',
    'meteo'      => 'https://flux.exemple.test/meteo.xml',
];
$cle = $_GET['source'] ?? '';
if (!isset($sources[$cle])) { http_response_code(400); exit; }
$contenu = telecharger($sources[$cle]);   // adresse issue de la liste, jamais du client

À vous de jouer

Exercice d’analyse, sans attaquer quoi que ce soit.

1. Une application propose « Importer une photo de profil depuis une adresse ». Quelle faille potentielle et quel paramètre surveilleriez-vous ?
2. Décrivez un laboratoire à deux machines virtuelles permettant de démontrer l’impact de façon sûre.
3. Rédigez les trois défenses que vous recommanderiez en priorité.

Vous avez parcouru les failles de contrôle d’accès et de logique. Le chapitre suivant se concentre sur les défauts de configuration et de composants, souvent plus « banals » mais très fréquents.