Dans le paysage numérique d'aujourd'hui, les attaques informatiques sont de plus en plus sophistiquées et omniprésentes. Parmi les menaces auxquelles sont confrontées les entreprises et les systèmes en ligne, il existe une attaque particulièrement dangereuse appelée Server-Side Request Forgery (SSRF).
Dans cet article, nous allons explorer en détail ce qu'est une attaque SSRF, ses implications pour la sécurité informatique et les mesures de prévention à prendre pour s'en protéger.
Comprendre le fonctionnement d'une attaque SSRF
A partir d’une application web vulnérable, les SSRF permettent d’interagir avec le serveur afin d’en extraire des fichiers et de trouver ses autres services actifs. Mais, cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les adresses IP et ports ouverts.
L’idée générale est la suivante : si une fonctionnalité permet d’interagir avec des ressources (exemple : chargement d’une image dans l’application ou redirection vers une page), alors l’attaquant pourra tenter de soumettre une requête au serveur de telle sorte que la ressource recherchée soit interne au serveur (fichiers, services, ressources disponibles en localhost seulement) ou à son réseau.
Prenons pour exemple l'extrait de code suivant :
<?php
$url = $_GET['url']; // Récupère l'URL fournie par l'utilisateur
// Vérifie si l'URL est définie
if (isset($url)) {
// Effectue une requête HTTP vers l'URL fournie
$content = file_get_contents($url);
echo $content
// Redirige l'utilisateur vers une page de succès
header("Location: https://example.com/success.html");
exit;
}
else{
// Si l'URL est n'est pas renseignée, affiche un message d'erreur
echo("Veuillez renseigner une URL svp");
exit;
}
?>
On remarque deux choses : d'une part, le paramètre url n’est pas contrôlé avant son utilisation dans file_get_contents($url), et d’autre part, le contenu est écrit (echo $content;) avant de faire une redirection.
Cet extrait de code est vulnérable à l'attaque SSRF. Car, en réalité le paramètre url peut prendre plusieurs valeurs qui peuvent nous permettre d'accéder aux ressources du serveur applicatif. Comme valeur possibles, nous pouvons citer :
- http://localhost/server-status : accès à une fonction apache du serveur
- http://localhost:8080 : accès à un service (8080) du serveur
- file:///etc/passwd : accès à un fichier du serveur
On voit ici que la vulnérabilité SSRF donne potentiellement de nombreuses possibilités à un attaquant. En fait, il ne s’agit ici que de quelques exemples. C’est en réalité la fonction PHP file_get_contents qui ouvre la brèche. Cette vulnérabilité SSRF ne se limite bien sûr pas à PHP et le même principe peut être retrouvé avec d'autres technologies web.
Quelles solutions ?
Comme la plupart des vulnérabilités Web, la vulnérabilité SSRF pourrait survenir à cause du mauvais contrôle des entrées dans une application web. En effet, le code de l'exemple précédent ne contient aucune vérification du 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.
Au niveau du serveur web, il est capital d'indiquer le périmètre autorisé pour accéder aux ressources.