Introduction

Les attaques de type Server-Side Request Forgery (SSRF) sont des vulnérabilités Web qui permettent à un attaquant d'induire l'application côté serveur à effectuer des requêtes vers des emplacements non désirés. Dans une attaque SSRF typique, l'attaquant peut faire en sorte que le serveur établisse une connexion avec des services internes uniquement au sein de l'infrastructure de l'organisation.

Dans d'autres cas, ils peuvent forcer le serveur à se connecter à des systèmes externes, ce qui peut entraîner la divulgation de données sensibles telles que les informations d'identification d'autorisation. Une attaque SSRF réussie peut souvent conduire à des actions non autorisées ou à l'accès à des données au sein de l'organisation, soit dans l'application vulnérable elle-même, soit sur d'autres systèmes centraux avec lesquels l'application peut communiquer.

Attaque contre le système

L'attaquant induit l'application à envoyer une requête HTTP au serveur hébergeant l'application, via son interface de bouclage. Cela implique généralement de fournir une URL avec un nom d'hôte tel que 127.0.0.1 (une adresse IP réservée qui pointe vers l'adaptateur de bouclage) ou localhost (un nom couramment utilisé pour le même adaptateur).

Par exemple, considérons une application de shopping qui permet à l'utilisateur de voir si un article est en stock dans un magasin particulier. Pour fournir des informations sur les stocks, l'application doit appeler diverses API REST de back-end. La fonction est mise en œuvre en passant l'URL vers le point de terminaison de l'API de back-end pertinent via une requête HTTP du frontend, et le navigateur exécute cette requête :

 POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

stockApi=http://stock.alibaba.net:8081/product/stock/check%3FproductId%3D6%26storeId%3D1

Dans cette situation, un attaquant peut modifier la requête pour spécifier une URL locale vers le serveur lui-même. Par exemple :

 POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

stockApi=http://localhost/admin

Ici, le serveur récupère le contenu de l'URL /admin et le renvoie à l'utilisateur. Lorsque la requête vers l'URL /admin provient de la machine locale elle-même, les contrôles d'accès normaux sont contournés. L'application accorde un accès complet aux fonctionnalités administratives car la requête semble provenir d'un emplacement approuvé.

Pourquoi les applications se comportent-elles de cette manière et font implicitement confiance aux demandes provenant de la machine locale ? Cela peut se produire pour diverses raisons :

1. La vérification de contrôle d'accès peut être mise en œuvre dans un composant différent situé devant le serveur d'application. Lorsqu'une connexion est établie avec le serveur lui-même, la vérification est contournée.
2. À des fins de récupération après sinistre, l'application peut autoriser l'accès administratif sans authentification à tout utilisateur provenant de la machine locale. Cela permet à un administrateur de récupérer le système s'ils perdent leurs informations d'identification.
3. L'interface d'administration peut écouter sur un numéro de port différent de celui de l'application principale et peut donc ne pas être directement accessible par les utilisateurs.

Ce genre de relation de confiance, où les demandes provenant de la machine locale sont traitées différemment des demandes régulières, est souvent ce qui rend SSRF une vulnérabilité critique.

Attaque contre le back-end

Un autre type de relation de confiance qui survient souvent avec les attaques par injection d'une requête côté serveur (SSRF) est lorsque le serveur d'application peut interagir avec d'autres systèmes centraux qui ne sont pas directement accessibles par les utilisateurs. Ces systèmes ont souvent des adresses IP privées non routables. Étant donné que les systèmes back-end sont généralement protégés par la topologie du réseau, ils ont souvent des postures de sécurité plus faibles. Dans de nombreux cas, les systèmes back-end internes contiennent des fonctionnalités sensibles accessibles sans authentification par quiconque peut interagir avec les systèmes.

Dans l'exemple précédent, supposons qu'il y ait une interface d'administration à l'URL principale https://192.168.0.68/admin. Ici, un attaquant peut exploiter la vulnérabilité SSRF pour accéder à l'interface d'administration en soumettant la demande suivante :

 POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

stockApi=http://192.168.0.21/admin

Comment prévenir cette attaque ?

Utiliser des filtres d'entrée basés sur une liste blanche

Certaines applications bloquent les entrées contenant des noms d'hôtes tels que 127.0.0.1 et localhost, ou des URL sensibles telles que /admin. Dans cette situation, il y a une solution de contournement :

Utilisation d'une autre représentation IP de 127.0.0.1, telle que 2130706433, 017700000001, ou 127.1.

Enregistrer votre propre nom de domaine qui se résout en 127.0.0.1. Masquer les chaînes bloquées en utilisant un encodage d'URL ou une variation de cas. Utilisation de filtres d'entrée basés sur une liste noire Certaines applications n'autorisent que les entrées qui correspondent, commencent par, ou contiennent une liste blanche de valeurs autorisées. La spécification d'URL contient un certain nombre de fonctionnalités qui sont susceptibles d'être négligées lors de l'implémentation d'une analyse et d'une validation d'URL ad hoc :

Vous pouvez intégrer des informations d'identification dans une URL avant le nom d'hôte, en utilisant le caractère @ : https://expected-host@attacker-host Vous pouvez utiliser le caractère # pour indiquer un fragment d'URL : https://attacker-host#expected-host Vous pouvez exploiter la hiérarchie de nommage DNS pour placer l'entrée requise dans un nom DNS entièrement qualifié que vous contrôlez : https://expected-host.attacker-host Vous pouvez encoder des caractères dans l'URL pour confondre le code d'analyse d'URL. Cela est particulièrement utile si le code implémentant le filtre gère les caractères codés en URL différemment du code qui exécute la requête HTTP principale. Vous pouvez utiliser des combinaisons de ces techniques ensemble. Les filtres peuvent être contournés avec une redirection Il est parfois possible de contourner tout type de défense basée sur des filtres en exploitant une vulnérabilité de redirection ouverte. Dans l'exemple SSRF précédent, supposons que l'URL soumise par l'utilisateur est strictement validée pour empêcher une exploitation malveillante du comportement SSRF. Cependant, l'application dont les URL sont autorisées contient une vulnérabilité de redirection ouverte. Si l'API utilisée pour effectuer la demande HTTP back-end prend en charge les redirections, vous pouvez créer une URL qui satisfait le filtre et génère une demande redirigée vers la cible back-end souhaitée. Par exemple :

 /product/nextProduct?currentProductId=6&path=http://attacke-user.net

Cela nous redirige vers http://attacker-user.net et nous pouvons contourner cet obstacle en utilisant :

 POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 124

stockApi=http://alibaba.net/product/nextProduct?currentProductId=6&path=http://192.168.0.21/admin

Cette exploitation SSRF fonctionne car l'application valide d'abord que l'URL stockAPI fournie est sur un domaine autorisé, ce qui est le cas. L'application demande ensuite l'URL fournie, ce qui déclenche la redirection ouverte. Elle suit la redirection et effectue une demande à l'URL interne choisie par l'attaquant.

Renforcer la couche applicative

Il est conseillé de ne pas se fier uniquement à la couche réseau et d'utiliser une vérification directe de l'application. Nettoyez toujours toute entrée que l'utilisateur envoie à votre application. Supprimez les caractères indésirables, normalisez l'entrée (guillemets doubles au lieu de guillemets simples, par exemple). Ainsi, créez des validations de rôle au niveau des points d'extrémité.

Activer l'authentification sur tous les services

Assurez-vous que l'authentification est activée sur tous les services s'exécutant sur votre réseau, même s'ils ne le requièrent pas. Des services tels que memcached, redis, mongo et autres ne nécessitent pas d'authentification pour les opérations normales, mais cela signifie qu'ils peuvent être exploités.