Falsification de requête côté serveur

Les vulnérabilités liées à la falsification des requêtes côté serveur se produisent lorsqu'un utilisateur est en mesure d'amener une application à effectuer des requêtes HTTP vers un domaine déterminé par l'attaquant. Si une application a accès à des réseaux privés/internes, un attaquant peut également amener l'application à envoyer des requêtes à des serveurs internes. 

Nous allons examiner cela de plus près à l'aide de quelques exemples afin de mieux comprendre ce qu'il en est en pratique.

Considérez une API qui prend l'URL d'un utilisateur et génère une image de l'URL fournie par l'utilisateur, par exemple pour la prévisualisation ou l'exportation d'une page. 

ts
let url = request.params.url ;

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

return render.export() ;

Le paramètre URL étant contrôlé par l'utilisateur, il permet à un attaquant d'accéder à n'importe quelle URL. Dans certains cas, en fonction de la bibliothèque utilisée pour accéder à l'URL, il peut même s'agir de fichiers locaux utilisant le schéma "file://".  

Une façon courante d'abuser d'une vulnérabilité SSRF, lorsqu'elle est hébergée sur AWS, est de l'utiliser pour accéder à l'API AWS Metadata qui peut contenir des informations d'identification pour l'API AWS. Cela peut conduire à l'accès à d'autres ressources AWS au sein du compte, ce qui, comme vous pouvez l'imaginer, n'est pas idéal.

Atténuation

L'atténuation des vulnérabilités du SSRF peut parfois s'avérer très délicate et dépend fortement de ce que le code en question essaie de réaliser. En fonction des exigences, différentes mesures d'atténuation peuvent être mises en place.

Évitez les URL déterminés par l'utilisateur

Dans certains cas, vous pouvez mettre en œuvre une fonctionnalité sans que l'utilisateur ait à fournir une URL arbitraire. Si c'est possible, c'est le moyen le plus efficace d'atténuer le risque de SSRF.

Réduire les capacités 

Si vous mettez en œuvre une fonction d'exportation PDF, on pourrait être tenté d'utiliser un navigateur sans tête et de faire une capture d'écran de la page. Cela n'est pas toujours conseillé, compte tenu de la complexité des navigateurs et du nombre considérable de capacités et de surfaces d'attaque qu'ils exposent.

Il est important d'utiliser l'outil adéquat pour le travail à effectuer. Dans certains cas, un simple client HTTP suffit. Il y a toujours des choses à faire pour minimiser les capacités, et donc la surface d'attaque/les vecteurs disponibles. Par exemple, dans le cas d'un client HTTP :

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

Il y a quelques pièges

Redirections et iframes

Un moyen courant de 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 un utilisateur et à utiliser une "liste de refus" pour empêcher l'accès aux ressources sensibles.

Il convient de noter que cette méthode n'est pas efficace dans la plupart des cas, car elle peut être contournée dans les scénarios où le client suit des redirections HTTP, des redirections HTML/JavaScript ou peut rendre des éléments complexes tels que des iframes.

Un attaquant peut fournir une URL à une application vulnérable qui héberge une page redirigeant vers une ressource sensible par le biais d'une redirection HTTP 301/302, d'une redirection HTML Meta, de la définition de l'URL actuelle avec Javascript au chargement, ou de l'intégration d'une iframe affichant une ressource interne. Cela permet de contourner toute tentative de validation de l'URL d'origine. 

DNS Rebinding
Un autre "type" de redirection peut également être effectué par le biais du DNS. Une façon courante d'essayer d'empêcher les attaques SSRF est de procéder comme suit :

1. Analyse l'URL fournie
2. Prenez le nom d'hôte et effectuez une recherche DNS.
3. Rejeter l'URL s'il s'agit d'une adresse IP interne/privée, ou accepter l'URL s'il s'agit d'une adresse IP publique.

Cette méthode n'est pas vraiment efficace car elle est vulnérable au "DNS Rebinding". Le DNS Rebinding fonctionne en raison du comportement standard de la plupart des piles réseau (telles que celles de Linux et Windows) lorsqu'une connexion TCP est fermée par un hôte distant.
Lorsqu'un hôte distant ferme de force une connexion, il tente de se reconnecter après avoir effectué une nouvelle requête DNS pour rétablir l'adresse IP. 

Cela permet à un pirate de faire ce qui suit :

1. Créez une entrée DNS pour `rebinding.attacker.com` avec une adresse IP publique, un port HTTP ouvert et un TTL (Time-to-live) très court.
2. Soumettez l'URL (exemple : https://rebinding.attacker.com/) à l'application vulnérable. Elle vérifie que l'IP résolue n'est pas privée, ce qui n'est pas le cas, et procède ensuite à l'opération demandée en pensant qu'elle est sûre
3. Une fois la connexion HTTP établie, l'entrée DNS pour "rebinding.attacker.com" est remplacée par une adresse IP interne.
4. La connexion HTTP est fermée de force
5. L'application doit alors résoudre à nouveau l'adresse IP de "rebinding.attacker.com", qui pointe désormais vers une adresse IP interne.
6. Étant donné que la protection de la résolution IP a déjà eu lieu, que la nouvelle résolution de l'entrée DNS et la reconnexion ont toutes lieu dans le noyau, l'application n'est pas consciente du fait que l'IP a maintenant changé.

Cela permet de contourner la protection contre la fourniture d'URL qui se résolvent en adresses IP privées. 

IPv4 contre IPv6

L'utilisation de l'IPv6 est un autre moyen courant de contourner les listes de refus. Comme toutes les adresses IPv4 peuvent être exprimées en termes d'adresse IPv6, il est souvent possible de contourner les listes de refus en utilisant une adresse IPv6 qui correspond également à une adresse IPv4 à laquelle on souhaite accéder.