Là où les notes sur le XSS, le CSRF et le clickjacking exploitent le navigateur de la victime, les vulnérabilités qui suivent s’attaquent directement au serveur. Elles partagent un trait commun : elles naissent presque toujours d’une confiance mal placée dans une donnée fournie par le client.
Téléversement de fichiers non maîtrisé
Un formulaire d’upload qui ne valide que superficiellement ce qu’il reçoit s’expose à un contournement classique : téléverser un fichier nommé img.jpg.php, dont le contenu réel n’a rien d’une image :
<?php
passthru($_GET[1]);
?>Si le serveur web exécute tout fichier .php quel que soit ce qui le précède dans le nom, l’attaquant obtient l’exécution de code arbitraire par simple visite de l’URL du fichier téléversé.
Les vérifications habituelles — extension autorisée, validité du format JPEG — ne suffisent pas toujours : un fichier peut être un JPEG parfaitement valide et contenir, dans ses métadonnées EXIF, du code qui sera interprété si le serveur les traite sans filtrage. Le type MIME déclaré par le client, de même, se falsifie trivialement côté requête — il ne doit jamais servir de seule validation.
Redirection ouverte
Une redirection ouverte (open redirect) survient lorsqu’un paramètre contrôlé par l’utilisateur détermine la destination d’une redirection HTTP, sans validation contre une liste de domaines autorisés. Le danger n’est pas direct : c’est un vecteur de phishing, l’attaquant diffusant un lien vers le domaine légitime et de confiance, qui redirige ensuite discrètement la victime vers un site malveillant — l’URL affichée dans le message d’hameçonnage restant, jusqu’au dernier moment, celle du site de confiance.
Manipulation du verbe HTTP
Le verb tampering exploite une politique de contrôle d’accès qui ne couvre pas uniformément toutes les méthodes HTTP : une règle qui bloque GET /admin mais oublie POST /admin, ou HEAD /admin, laisse ouverte une porte que le développeur croyait fermée. C’est un rappel que le contrôle d’accès doit s’appliquer à la ressource, indépendamment de la méthode employée pour y accéder.
Traversée de chemin
Le path traversal exploite une construction de chemin de fichier qui incorpore, sans normalisation ni validation, une entrée utilisateur. Une séquence comme ../../etc/passwd, glissée dans un paramètre censé désigner un nom de fichier local, permet de sortir du répertoire prévu et de lire — voire d’écrire — des fichiers arbitraires sur le système, pour peu que les permissions du processus serveur le permettent.
Server-Side Request Forgery
La SSRF détourne un serveur pour qu’il émette, en son propre nom, une requête vers une destination choisie par l’attaquant — typiquement en fournissant une URL en paramètre d’une fonctionnalité légitime (aperçu d’image, webhook, import de document). Le serveur, disposant souvent d’un accès réseau que l’attaquant n’a pas directement, devient un relais : il peut ainsi être contraint d’interroger des services internes normalement inaccessibles depuis l’extérieur, ou les métadonnées d’une instance cloud (souvent accessibles sans authentification depuis l’intérieur du réseau), révélant des identifiants ou des informations de configuration sensibles1.
Footnotes
-
Pour un développement plus complet, voir Understanding web vulnerability: Server-Side Request Forgery. ↩