서버 요청 위조

Les vulnérabilités liées à la falsification des requêtes côté serveur se produisent lorsqu'un utilisateur parvient à demander à une application d'envoyer des requêtes HTTP à 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 examinerons cela de plus près à l'aide de quelques exemples pour mieux comprendre à quoi cela ressemble en action.

Prenez l'exemple d'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 l'aperçu ou l'exportation d'une page.

ts
let url = request.params.url ;

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

renvoie render.export () ;

Comme le paramètre URL est contrôlé par l'utilisateur, il permet à un attaquant d'accéder simplement à l'URL de son choix. Dans certains cas, selon la bibliothèque utilisée pour accéder à l'URL, il peut même s'agir de fichiers locaux en utilisant le schéma « file ://».

Une manière courante d'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 informations d'identification pour l'API AWS. Cela peut entraîner un accès supplémentaire à d'autres ressources AWS du compte, ce qui, comme vous pouvez l'imaginer, n'est pas idéal.

Mesures d'atténuation

L'atténuation des vulnérabilités SSRF peut parfois être très délicate et dépend largement de l'objectif du code en question. En fonction des exigences, différentes mesures d'atténuation peuvent être mises en place.

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

Dans certains cas, vous pouvez implémenter une fonctionnalité sans qu'un utilisateur fournisse une URL arbitraire. Si c'est possible, c'est le moyen le plus efficace d'atténuer le risque de SSRF.

Minimiser les capacités

Si vous implémentez une fonction d'exportation de PDF, vous pourriez être enclin à utiliser simplement un navigateur sans interface et à prendre une capture d'écran de la page. Ce n'est pas toujours conseillé, étant donné la complexité des navigateurs et le grand nombre de fonctionnalités et de surfaces d'attaque qu'ils exposent.

Il est important d'utiliser le bon outil pour la tâche à accomplir. Dans certains cas, un simple client HTTP suffira. Il y a toujours des choses qui peuvent être faites pour minimiser les capacités, et donc la surface d'attaque et les vecteurs disponibles. Par exemple, dans le cas d'un client HTTP :

• Désactivez les redirections suivantes
• Désactiver tous les schémas autres que HTTPS

Il y a quelques écoles

Redirections et iframes

Une méthode courante de protection contre le SSRF sur les 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 afficher des éléments complexes tels que des iframes.

Un attaquant peut fournir une URL vers une application vulnérable hébergeant une page redirigeant vers une ressource sensible, soit via une méta-redirection HTTP 301/302, soit via une méta-redirection HTML, soit en définissant l'URL actuelle avec Javascript lors du chargement, soit en intégrant un iframe affichant une ressource interne. Cela permet d'éviter toute tentative de validation de l'URL d'origine.

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

1. Analyser l'URL fournie
2. Prenez le nom d'hôte et effectuez une recherche DNS
3. Rejetez l'URL si elle renvoie à une adresse IP interne/privée, ou acceptez 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 ». La reliaison DNS 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 une connexion de force, il tente de se reconnecter après avoir effectué une autre requête DNS pour résoudre à nouveau l'adresse IP.

Cela permet à un attaquant d'effectuer les opérations suivantes :

1. Créez une entrée DNS pour `rebinding.attacker.com avec une adresse IP publique avec un port HTTP ouvert avec un TTL (Time-to-Live) très court
2. Soumettez l'URL (exemple : https://rebinding.attacker.com/) à l'application vulnérable. Il vérifie que l'adresse IP résolue n'est pas privée, ce qui n'est pas le cas, puis procède à l'opération demandée en croyant qu'elle est sûre
3. Une fois la connexion HTTP établie, l'entrée DNS de « rebinding.attacker.com » est remplacée par une adresse IP interne
4. La connexion HTTP est fermée de force
5. Cela amène l'application à 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 est déjà effective et que la rerésolution de l'entrée DNS et la reconnexion se font toutes dans le noyau, l'application n'est pas consciente du fait que l'adresse IP a maintenant changé

Cela permet de contourner efficacement la protection contre la fourniture d'URL renvoyant à des adresses IP privées.

IPv4 contre IPv6

L'utilisation d'IPv6 est un autre moyen courant de contourner toute « liste 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 souhaiterait accéder.