Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-918 : falsification de requête côté serveur (SSRF)

CWE-918 : falsification de requête côté serveur (SSRF)

Section intitulée « CWE-918 : falsification de requête côté serveur (SSRF) »

Vingt-deuxième du CWE Top 25 2025. Le libellé officiel est Server-Side Request Forgery (SSRF), « falsification de requête côté serveur ». Le catalogue signale aussi l’ancienne appellation XSPA, pour cross-site port attack, tombée en désuétude depuis que le nuage a donné à cette faiblesse une cible bien plus intéressante que des ports ouverts.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Section intitulée « Ce que la classe recouvre exactement »

Le serveur reçoit d’un composant en amont une adresse (ou une demande équivalente), récupère le contenu de cette adresse, et ne s’assure pas suffisamment que la requête part vers la destination attendue.

Trois éléments de cette définition délimitent la classe. Il faut que le serveur émette une requête, ce qui exclut tout ce qui ne sort pas. Il faut que la destination soit influencée depuis l’extérieur, directement ou indirectement. Et il faut que la vérification de cette destination soit insuffisante : ce qui inclut les vérifications contournées par une redirection, un nom de domaine qui résout vers une adresse interne, ou une notation d’adresse inhabituelle.

Le point que l’on sous-estime est la position du serveur. L’intérêt de la faiblesse ne tient pas à ce que le serveur sait, mais à ce qu’il peut joindre : le réseau interne, les services d’administration qui n’écoutent que sur la boucle locale, et surtout les services de métadonnées des plateformes de nuage, qui distribuent des identifiants à qui les interroge depuis l’intérieur de la machine. Le serveur n’est pas la cible : il est le véhicule.

Une nuance utile pour lire un rapport : la classe couvre aussi les cas où la réponse n’est pas rendue à l’attaquant. Une falsification aveugle, où seul le fait que la requête soit partie est observable, reste une falsification : et suffit souvent, puisqu’elle permet de cartographier le réseau interne ou de déclencher des actions sur des services sans authentification.

Sa place dans l’arbre

Section intitulée « Sa place dans l’arbre »

CWE-918 est une base dont le parent, dans la vue de recherche, est CWE-441, « intermédiaire ou mandataire involontaire », plus connu sous le nom de député confus. Ce rattachement est la meilleure explication conceptuelle de la faiblesse : le problème n’est pas une donnée mal filtrée, c’est une confusion d’autorité. Une entité dotée de privilèges agit pour le compte d’une entité qui n’en a pas, sans distinguer son intention propre de l’instruction reçue.

Le même parent couvre d’autres membres de cette famille, et notamment la falsification de requête inter-sites, qui est le cas symétrique : là, le député confus est le navigateur de la victime ; ici, c’est le serveur. Deux faiblesses très différentes dans leurs effets, un seul défaut de raisonnement.

Dans la vue simplifiée, le parent est CWE-610, « référence contrôlée de l’extérieur vers une ressource dans une autre sphère », qui dit la même chose dans le vocabulaire des sphères de confiance.

Pourquoi elle est si haut

Section intitulée « Pourquoi elle est si haut »

Parce que le nuage a transformé un inconvénient en clé. Un serveur qui peut interroger le service de métadonnées de sa propre instance peut obtenir des identifiants temporaires valables pour les ressources du compte. C’est exactement ce que décrit la page du site sur la SSRF vers le service de métadonnées : la faiblesse ne donne pas accès à une page interne, elle donne accès à une identité.

Parce que les fonctions légitimes qui l’ouvrent sont partout. Récupérer l’aperçu d’un lien, importer une image depuis une adresse, vérifier un service distant, appeler un webhook fourni par le client, convertir un document référencé par URL : toutes ces fonctionnalités consistent, par conception, à faire émettre au serveur une requête vers une adresse choisie par l’utilisateur.

Parce que les protections réseau ne la voient pas. La requête part de l’intérieur, vers l’intérieur, depuis un serveur légitime. Un pare-feu périmétrique ne la rencontre jamais ; c’est tout le propos des failles invisibles au pare-feu.

Parce que les filtres naïfs échouent. Interdire les adresses privées par comparaison de chaînes ne résiste ni aux redirections, ni aux noms de domaine qui résolvent vers une adresse interne, ni aux notations d’adresse alternatives. La vérification doit porter sur l’adresse réellement atteinte, après résolution : et être refaite à chaque redirection suivie.

Le mécanisme, et où le site le traite

Section intitulée « Le mécanisme, et où le site le traite »

Le site traite les deux faces du sujet. SSRF vers le service de métadonnées et vol d’identifiants cloud décrit la cible la plus rentable et les protections de plateforme qui la ferment. Bloquer les requêtes côté serveur et la désérialisation traite la défense applicative et explique pourquoi les contrôles réseau classiques sont hors jeu.

Deux renvois pour les vecteurs voisins : l’attaque XXE montre qu’un analyseur XML mal configuré produit une falsification de requête sans qu’aucune fonction d’import n’existe dans l’application, et le webhook forgé sans signature vérifiée traite la symétrie : ici l’adresse sortante est fournie par le client, là c’est la requête entrante qui n’est pas authentifiée.

Côté architecture, sécuriser une passerelle d’API comme point de contrôle est le bon niveau pour placer la sortie sous surveillance : un relais unique pour les appels sortants, avec sa liste de destinations autorisées.

Ce qu’une équipe en fait

Section intitulée « Ce qu’une équipe en fait »

Lister les destinations autorisées, jamais les destinations interdites. Une liste blanche de domaines, résolue et vérifiée au moment de l’appel, est la seule défense qui tienne. Dans la plupart des applications, cette liste compte moins de dix entrées.

Vérifier après résolution, et à chaque redirection. Le contrôle porte sur l’adresse IP effectivement contactée, comparée aux plages interdites, et doit être refait pour chaque saut : c’est précisément là que les filtres maison tombent.

Fermer le service de métadonnées par les mécanismes de la plateforme, qui existent et exigent désormais une requête signée ou un en-tête spécifique. C’est le contrôle qui transforme la faiblesse la plus rentable en désagrément.

Faire sortir par un relais dédié, dans un segment sans accès au réseau d’administration. Une falsification réussie n’atteint alors que ce que le relais peut joindre.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Une équipe qui traite cette faiblesse comme un problème de filtrage d’adresses écrit une liste noire, la trouve satisfaisante, et laisse ouverte la seule porte qui compte. Le défaut ne se voit pas à l’usage : la fonctionnalité d’import ou d’aperçu marche parfaitement, et les requêtes sortantes vers l’intérieur ne figurent dans aucun tableau de bord, puisqu’elles n’ont traversé aucun équipement de filtrage. Quand elle est exploitée sur une infrastructure en nuage, la conséquence n’est pas une fuite de page interne mais l’obtention d’identifiants valides du compte, avec lesquels l’attaquant agit ensuite par les interfaces officielles de la plateforme : ce qui rend sa présence presque indistinguable d’une activité d’exploitation normale. L’enquête doit alors reconstituer, dans les journaux de la plateforme, lesquelles des actions légitimes ne l’étaient pas, exercice long et incertain.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

De nombreux sites proposent des fonctions qui consistent à aller chercher quelque chose à une adresse que l’utilisateur fournit : afficher l’aperçu d’un lien, importer une image, vérifier qu’un service distant répond, envoyer une notification à l’adresse indiquée par un client.

Pour cela, le serveur du site émet lui-même la requête. Or le serveur n’est pas placé là où est l’utilisateur : il est à l’intérieur du réseau de l’entreprise ou du centre de données, et il peut joindre des services que personne ne peut atteindre depuis l’extérieur (interfaces d’administration, bases de données, et, sur les plateformes d’informatique en nuage, un service interne qui distribue les identifiants d’accès de la machine).

Si l’utilisateur fournit l’adresse de l’un de ces services internes au lieu d’une adresse publique, le serveur va les chercher et, souvent, rapporte le résultat. Ce n’est pas une effraction : on a demandé à quelqu’un qui possède les clés d’aller chercher un dossier, et il l’a fait.

C’est le défaut que le catalogue CWE appelle CWE-918. Deux choses le rendent redoutable. D’abord, les protections classiques n’y peuvent rien : la requête part de l’intérieur vers l’intérieur, et ne traverse aucun des filtres placés aux frontières. Ensuite, sa cible la plus intéressante n’est pas une information mais une identité : en obtenant les identifiants de la machine, l’attaquant continue son travail à travers les interfaces officielles de la plateforme, où ses actions ressemblent à celles d’un administrateur ordinaire.

La protection consiste à renverser la logique du filtrage : au lieu d’interdire des adresses (liste toujours incomplète), n’autoriser que celles dont on a besoin, et vérifier la destination réellement atteinte plutôt que celle qui a été écrite.

À lire aussi

Pages voisines

CWE-918 : falsification de requête côté serveur (SSRF)

Elle cite

: les deux pages se citent l’une l’autre.