Falsification de requête côté serveur

Les vulnérabilités de type Server-Side Request Forgery surviennent lorsqu'un utilisateur est en mesure d'amener une application à effectuer des requêtes HTTP vers un domaine déterminé par un attaquant. Si l'application a accès à des réseaux privés ou internes, l'attaquant peut également forcer l'application à envoyer des requêtes vers des serveurs internes.

Nous allons examiner cela plus en détail avec quelques exemples afin de mieux comprendre ce à quoi cela ressemble en pratique.

Prenons l'exemple d'une API qui récupère une URL fournie par un utilisateur et génère une image de la page correspondante, par exemple pour un aperçu ou une exportation.

ts
let url = request.params.url;

let response = http.get(url);
let render = response.render();

return render.export();

Comme le paramètre URL est contrôlé par l'utilisateur, cela permet à un attaquant d'accéder à n'importe quelle URL de son choix. Dans certains cas, selon la bibliothèque utilisée pour accéder à l'URL, il est même possible d'accéder à des fichiers locaux via le protocole « file:// ».

Une méthode courante pour exploiter une vulnérabilité SSRF, lorsqu'elle est hébergée sur AWS, consiste à l'utiliser pour accéder à l'API de métadonnées AWS, qui peut contenir des identifiants pour l'API AWS. Cela peut mener à un accès non autorisé à d'autres ressources AWS au sein du compte, ce qui, comme vous pouvez l'imaginer, est loin d'être idéal.

Atténuation

L'atténuation des vulnérabilités SSRF peut s'avérer complexe et dépend fortement de l'objectif du code concerné. Selon les besoins, différentes mesures de protection peuvent être mises en place.

Éviter les URL déterminées par l'utilisateur

Dans certains cas, vous pouvez concevoir une fonctionnalité qui ne repose pas sur une URL arbitraire fournie par l'utilisateur. Si cela est possible, c'est le moyen le plus efficace d'atténuer le risque de SSRF.

Réduire les capacités

Si vous implémentez une fonction d'exportation PDF, vous pourriez être tenté d'utiliser simplement un navigateur sans interface graphique (headless) pour prendre une capture d'écran de la page. Ce n'est pas toujours conseillé, compte tenu de la complexité des navigateurs et du nombre important de fonctionnalités et de surfaces d'attaque qu'ils exposent.

Il est important d'utiliser l'outil adapté à la tâche. Parfois, un simple client HTTP suffit. Il est toujours possible de limiter les capacités, et donc la surface ou les vecteurs d'attaque disponibles. Par exemple, pour un client HTTP :

• Désactiver le suivi des redirections
• Désactiver tous les protocoles autres que HTTPS

Il existe quelques pièges

Redirections et iframes

Une méthode courante pour se protéger contre le SSRF sur des ressources privées (adresses IP ou noms d'hôtes internes) consiste à analyser l'URL fournie par l'utilisateur et à utiliser une « liste noire » pour empêcher l'accès aux ressources sensibles.

Il est important de noter que cette méthode n'est pas efficace dans la plupart des cas, car elle peut être contournée lorsque le client suit des redirections HTTP, des redirections HTML/JavaScript, ou peut afficher des éléments complexes comme des iframes.

Un attaquant peut fournir à une application vulnérable une URL pointant vers une page qui redirige vers une ressource sensible, que ce soit via une redirection HTTP 301/302, une balise Meta HTML, une redirection JavaScript au chargement, ou l'intégration d'une iframe affichant une ressource interne. Cela contourne efficacement toute tentative de validation de l'URL initiale.

Rebinding DNS
Un autre « type » de redirection peut également être effectué via le DNS. Une méthode courante pour tenter de prévenir les attaques SSRF consiste à procéder comme suit :

1. Analyser l'URL fournie
2. Récupérer le nom d'hôte et effectuer une résolution DNS
3. Rejeter l'URL si elle correspond à une adresse IP interne/privée, ou l'accepter s'il s'agit d'une adresse IP publique

Cette méthode n'est pas réellement efficace car elle est vulnérable au « DNS Rebinding ». Le DNS Rebinding exploite le comportement standard de la plupart des piles réseau (comme celles de Linux et Windows) lorsqu'une connexion TCP est fermée par un hôte distant.
Lorsqu'un hôte distant ferme brutalement une connexion, le système tente de se reconnecter après avoir effectué une nouvelle requête DNS pour résoudre à nouveau l'adresse IP.

Cela permet à un attaquant de procéder comme suit :

1. Créer une entrée DNS pour `rebinding.attacker.com` avec une adresse IP publique disposant d'un port HTTP ouvert et un TTL (Time-to-live) très court
2. Soumettre l'URL (exemple : https://rebinding.attacker.com/) à l'application vulnérable. Celle-ci vérifie que l'adresse IP résolue n'est pas privée, ce qui est le cas, puis poursuit l'opération demandée en pensant qu'elle est sécurisée
3. Une fois la connexion HTTP établie, l'entrée DNS de « rebinding.attacker.com » est modifiée pour pointer vers une adresse IP interne
4. La connexion HTTP est fermée brutalement
5. Cela force l'application à résoudre à nouveau l'adresse IP de « rebinding.attacker.com », qui pointe désormais vers une adresse IP interne
6. Comme la protection par résolution IP a déjà eu lieu, et que la nouvelle résolution DNS ainsi que la reconnexion s'effectuent au niveau du noyau, l'application n'est pas informée que l'adresse IP a changé

Cela permet de contourner efficacement la protection contre la fourniture d'URL résolvant vers des adresses IP privées.

IPv4 vs IPv6

Une autre méthode courante pour contourner une « liste noire » consiste à utiliser l'IPv6. Étant donné que toutes les adresses IPv4 peuvent être exprimées sous forme d'adresses IPv6, il est souvent possible de contourner les listes noires en utilisant une adresse IPv6 qui correspond également à l'adresse IPv4 à laquelle on souhaite accéder.