Sécurité des applications Web - Menaces et contre-mesures

Auteur: Mohamed CHINY Durée necessaire pour le cours de Sécurité des applications Web - Menaces et contre-mesures Niveau recommandé pour le cours de Sécurité des applications Web - Menaces et contre-mesures Supports vidéo non disponibles pour ce cours Exercices de renforcement non disponibles pour ce cours Quiz non disponibles pour ce cours

Page 13: Vulnérabilité SSRF (Server-Side Request Forgery)

Toutes les pages

La vulnérabilité SSRF (Server-Side Request Forgery)

Qu'est ce que le SSRF?

L'idée derrière la vulnérabilité SSRF (Server-Side Request Forgery) n'est pas nouvelle. En effet, SSRF représente plutôt une famille de vulnérabilités que nous avons déjà traité dans ce cours, comme l'injection de code arbitraire, le LFI ou encore le RFI.

La présence de la vulnérabilité SSRF dans une application Web permet au pirate d'interagir frauduleusement avec les ressources non exposées du serveur Web. Il s'agit là de ressources qui ne figurent pas forcément dans le dossier d'hébergement (document root) ou qui nécessitent des privilèges spéciaux pour être accessibles ou encore qui sont accessibles via des pages prévues à cette effet et non pas à travers le reste des pages (qui pourraient potentiellement renfermer la faille SSRF).

L'exploitation de la vulnérabilité SSRF pourrait donner lieu à l'une des actions suivantes:
  • Accès non autorisé à une ressource du serveur Web (images, document PDF...)
  • Accès non autorisé à une ressource non exposée, comme un fichier système ou une ressource qui ne figure pas dans le dossier d'hébergement
  • Accès à un service Web non prévu à travers l'application Web (comme un service qui tourne sur un port d'écoute autre que le port prévu comme 80 ou 443 par exemple)
  • Exécution d'une commande système à travers la page vulnérable...

La vulnérabilité SSRF peut également compromettre les applications Web qui utilisent les API mal sécurisées.
Vous avez certainement remarqué que la liste des exploits énumérés ci-dessus peuvent être réussis à travers d'autres vulnérabilités traitées dans ce cours comme le XSS, le LFI, l'injection de code... ce qui signifie que le SSRF peut constituer une combinaison de plusieurs autres vulnérabilités basiques.

Exploitation de la vulnérabilité SSRF

Imaginons que le code ci-dessous figure dans l'une des pages d'une application Web:
<?php
if(isset($_GET["url"])){
   if(!empty(trim($_GET["url"])){
      echo file_get_contents($_GET["url"]);
   }
}
?>
Il s'agit d'un code basique qui vérifie si un paramètre nommé "url" est passé à travers l'URL, puis vérifie si ce paramètre contient une valeur non vide après l'avoir démuni des espaces de début et de fin à l'aide la fonction trim().

Imaginons que l'URL de la page qui contient cette vulnérabilité est http://www.site-victime.com/pageVulnérable.php. Dans ce cas, le pirate qui souhaiterait exploiter la vulnérabilité SSRF pourrait forger des requêtes qui ressembleraient à ceci:
  • http://www.site-victime.com/pageVulnérable.php?url=../../etc/passwd: Le pirate tente d'afficher le contenu du fichier système "passwd" qui contient la liste des utilisateurs du système. La séquence "../" peut être répétée autant de fois que nécessaire jusqu'à ce que le chemin relatif coïncide avec l'emplacement du fichier en question.
  • http://www.site-victime.com/pageVulnérable.php?url=http://localhost:10000: Le pirate tente d'afficher la page d'authentification de l'application Webmin qui tourne généralement sur le port 10000. Cette application est très souvent utilisée par les administrateurs système car elle simplifie la gestion et la configuration des services à travers une interface graphique intuitive et simple.
  • http://www.site-victime.com/pageVulnérable.php?url=http://192.168.20.40: Le pirate tente d'accéder à une ressource (machine, serveur, imprimante réseau ou tout autre équipement connecté au réseau) dont l'adresse IP privée est 192.168.20.40. Bien entendu, cette ressource est sensée faire tourner un service Web accessible via le protocole HTTP.

Comment s'en protéger?

Au niveau du code source

Comme la plupart des vulnérabilités Web, la vulnérabilité SSRF pourrait survenir à cause du mauvais contrôle des entrées d'une application Web. En effet, le code de l'exemple précédent ne contient aucune vérification eu paramètre "url" ce qui est potentiellement dangereux.

La bonne méthode de coder consiste à prendre en compte l'aspect sécurité au moment de la conception et l'implémentation de l'application (Security by Design), et l'une des opérations les plus basiques consiste à renforcer la vérification des entrées du site Web (formulaire, URLs, Cookies...) avant de les traiter. Pour cela, on peut par exemple:
  • Créer une White List des URL autorisés à travers le $_GET
  • Interdir le crowling des dossiers en supprimant les occurrences ../ présentes dans les valeurs d'entrée.
  • Spécifier la liste de caractères autorisés dans les valeurs d'entrées (par exemple: caractères alphabétiques et chiffres seulement)
  • Imposer l'extension de l'URL passé en argument (bien que celà pourrait être détourné à l'aide de la vulnérabilité Null Byte Injection que nous avons déjà traité dans ce cours).

Au niveau de la configuration du serveur

Il est capital d'indiquer au serveur Web le périmètre autorisé pour accéder aux ressources. A titre d'exemple, il serait judicieux de lui interdir l'accès aux ressources externes à travers les adresses IP publiques ou privées. Cela pourrait être fait à l'aide de simples règles applicables en local à l'aide d'iptables par exemple ou au niveau du Firewall qui contrôle la zone où est installé le serveur Web.