Top 10 de l'OWASP relatif aux risques de sécurité des API : vulnérabilité côté serveur de type SSRF

La vulnérabilité côté serveur de type SSRF figure en septième position sur la liste des 10 principaux risques de sécurité des API établie par l’Open Worldwide Application Security Project® (OWASP).

La SSRF est une tactique malveillante qui permet aux pirates d’abuser des fonctionnalités du serveur pour accéder à des zones auxquelles il ne devrait pas pouvoir accéder librement. Les pirates peuvent envoyer des requêtes sortantes arbitraires à partir d’un serveur, recueillir des informations sur des systèmes internes non accessibles au public ou interroger des points de terminaison de métadonnées.

Vecteurs d’attaque

Les exploits SSRF se produisent lorsque les pirates trouvent un point de terminaison API qui peut accéder à un identifiant de ressource uniforme (URI) fourni par l’utilisateur. Dans une attaque SSRF classique, les pirates sondent les points d’accès à la recherche de réponses contenant des informations qu’ils peuvent exploiter. Cela peut être, par exemple, l’analyse des codes d’état HTTP. Une attaque SSRF aveugle ne donne pas lieu à un feedback direct, mais permet à un pirate de déduire des informations qui peuvent être utilisées pour tromper les serveurs afin qu’ils fournissent un accès.

L'OWASP considère que les attaques par vulnérabilité côté serveur de type SSRF sont des attaques peu complexes.

Failles de sécurité

La mauvaise validation des URI est fréquente mais aussi, assez facile à détecter. Les requêtes API de routine et l’analyse de la réponse résultante peuvent révéler des informations potentielles que les pirates ont la possibilité d’exploiter. La détection des failles de sécurité dans les API suite à des attaques SSRF aveugles est un peu plus délicate.

Selon l’OWASP, les pratiques modernes en matière de développement d’applications sont plus courantes et plus dangereuses. Les développeurs accèdent généralement à des ressources externes sur la base des données fournies par l’utilisateur. Les fournisseurs de cloud, Docker ou Kubernetes, peuvent exposer la gestion et le contrôle sur des chemins prévisibles ce qui en fait une cible facile pour une telle attaque si des protections appropriées ne sont pas mises en place.

En raison de la façon dont les applications sont connectées, il peut être difficile de limiter le trafic sortant. Le risque d’une attaque de type SSRF est donc toujours présent.

Impacts sur les entreprises

L’OWASP estime que l’impact des attaques SSRF sur les entreprises est modéré, bien qu’elles puissent entraîner de sérieux problèmes.

Par exemple, les pirates peuvent utiliser les informations obtenues pour analyser les ports ou pour repérer les services internes qui peuvent être utilisés pour contourner les firewalls ou d’autres systèmes de sécurité. Cela peut permettre aux pirates d’accéder à des données sensibles ou de mener des attaques par déni de service (DoS). Les serveurs peuvent aussi être utilisés comme proxies pour dissimuler des activités malveillantes.

Fonctionnement des attaques par vulnérabilité côté serveur de type SSRF

La vulnérabilité de type SSRF côté serveur se produit lorsqu’une API extrait une ressource distante mais n’exige pas la validation de l’URL fournie par l’utilisateur. Cela permet aux pirates de forcer l’application à envoyer une réponse vers une destination inattendue, même si elle est protégée par un VPN ou un firewall.

Une attaque typique pourrait opérer comme suit :

• Les pirates recherchent les champs d'entrée ou les paramètres utilisés par l'utilisateur pour effectuer des demandes HTTP.
• Une demande malveillante est envoyée pour manipuler les paramètres vulnérables.
• En spécifiant des adresses IP internes, des noms d’hôtes locaux ou des réseaux privés, les pirates incitent le serveur à faire des requêtes vers des ressources qui devraient normalement être restreintes.
• Les pirates accèdent ensuite à des données sensibles ou propriétaires.
• Une fois l’accès accordé, les pirates peuvent se déplacer latéralement au sein des systèmes ou lancer des attaques sur d’autres systèmes du réseau.

Les attaques SSRF peuvent également permettre d’accéder à des ressources externes. Par exemple, les pirates peuvent spécifier des URL d’API tierces.

L’OWASP donne un exemple de la manière dont les attaques SSRF peuvent être exécutées dans le monde réel. Les réseaux sociaux permettant aux utilisateurs de télécharger des photos de profil peuvent générer un appel d’API pour l’URL d’une image. Les pirates peuvent envoyer une URL malveillante et lancer une analyse des ports sur le réseau interne en utilisant le point de terminaison de l’API pour repérer les ports ouverts.

Détecter les vulnérabilités liées à la vulnérabilité côté serveur de type SSRF

La détection des attaques SSRF nécessite une combinaison d'outils automatisés et de tests manuels :

• L'examen du code source permet d'identifier les vecteurs d'attaque potentiels lorsque des données d'entrée fournies par l'utilisateur font des demandes HTTP.
• Les tests manuels, qui consistent à fournir des modifications d’URL, des adresses IP et des protocoles dans les champs de saisie afin de vérifier s’ils sont traités correctement ou s’ils produisent des résultats inattendus.
• Les tests d’inclusion de fichiers locaux pour tenter d’accéder à des fichiers contenant des données sensibles sur des serveurs locaux. Il s’agit notamment de sonder le réseau pour voir si les requêtes de plages IP internes ou de segments restreints permettent d’accéder à des ressources non autorisées.
• L’examen régulier des journaux pour repérer des modèles de requêtes inattendus, tels que des requêtes adressées à des ressources internes ou à des destinations inhabituelles.

Les outils d’analyse des applications web et les cadres de test SSRF automatisés peuvent automatiquement explorer les API et tester les applications pour détecter les failles de sécurité.

Prévenir les vulnérabilités liées à la vulnérabilité côté serveur de type SSRF

La prévention de ces vulnérabilités nécessite le déploiement de pratiques fondamentales de cybersécurité, notamment l’application du principe du moindre privilège (POLP) et de l’accès Zero Trust. N’autorisez pas l’ajout de données par l’utilisateur sans les avoir préalablement validées, quelle que soit leur origine.

Il ne faut jamais supposer que les ressources internes sont protégées lorsqu’elles ne sont pas directement exposées à l’Internet. Une fois que les pirates ont pénétré votre réseau, toute faille de sécurité peut leur permettre d’accéder à des ressources non connectées. Il est donc fortement recommandé d’isoler le dispositif de récupération des ressources dans votre réseau. En général, ces fonctions sont utilisées pour récupérer des ressources distantes et non des ressources internes.

Dans la mesure du possible, limitez la circulation pour permettre l'accès aux listes :

• Schémas d’URL et ports
• Types de médias pour des fonctionnalités spécifiques
• Téléchargement de ressources

Vous devez également désactiver les redirections HTTP et, comme toujours, veiller à ce que les correctifs et les mises à jour des logiciels soient installés et utiliser un Web Application Firewall.