Qu’est-ce que SSRF ?

Dans une attaque SSRF, l’attaquant manipule généralement les données utilisées pour spécifier l’URL cible d’une requête HTTP côté serveur. Cela peut se produire lorsqu’une application ne valide pas ou n’assainit pas l’URL saisie par un utilisateur avant d’extraire des données d’une ressource distante. L’attaquant peut faire en sorte que le serveur ciblé exécute des requêtes vers des destinations arbitraires, ce qui peut entraîner divers risques pour la sécurité.

Ces attaques peuvent également se produire si la ressource ciblée a des relations de confiance avec d’autres systèmes, tels qu’un service de métadonnées du cloud ou des API back-end, ce qui permet à un attaquant d’adresser des demandes à ces services de confiance et d’extraire des informations sensibles ou d’effectuer des actions non autorisées.

Les applications web modernes offrant aux utilisateurs finaux des fonctionnalités pratiques, la recherche d’une URL est devenue un scénario courant. Par conséquent, l’incidence de la SSRF augmente. La gravité de la SSRF augmente également à mesure que les API et les services du cloud deviennent plus répandus et que les architectures informatiques deviennent plus décentralisées et plus complexes.

Le SSRF est l’un des principaux risques de sécurité d’application du OWASP Top 10, une compilation largement reconnue des risques de sécurité d’application les plus critiques. Le SSRF est également l’un des principaux risques de sécurité du OWASP Top 10 qui sont communs aux applications et aux API, et qui doivent faire l’objet d’une attention particulière lors de la mise en œuvre de solutions de sécurité.

Voici comment fonctionne une attaque SSRF :

• L’application permet à l’utilisateur de déterminer l’URL ou la ressource cible d’une requête côté serveur. Cette entrée peut provenir des paramètres d’une URL, des entrées de l’utilisateur dans les champs d’un formulaire ou d’autres sources de données.
• L’attaquant soumet une requête spécialement conçue, en manipulant l’entrée pour qu’elle pointe vers une ressource à laquelle il veut accéder ou qu’il veut exploiter. Cette ressource peut être un serveur interne, un service back-end, une API ou d’autres systèmes internes qui se trouvent derrière des pare-feux et ne sont pas accessibles depuis le réseau externe.
• Le serveur traite l’entrée malveillante de l’utilisateur et construit une requête vers l’URL spécifiée. Cette requête est faite du point de vue du serveur, et non du navigateur de l’utilisateur, ce qui en fait une requête côté serveur.
• Si le serveur ciblé se trouve dans un réseau interne, l’attaquant peut tenter d’accéder aux ressources internes et d’en extraire des informations sensibles, puis d’exfiltrer ces données vers un site externe contrôlé par l’attaquant. Le SSRF peut également être utilisé pour scanner les ports des systèmes internes, ce qui aide l’attaquant à identifier les faiblesses et les vulnérabilités potentielles.
• Les attaques SSRF sont particulièrement préoccupantes dans les environnements du cloud où les instances peuvent avoir accès à des services de métadonnées sensibles.
• L’impact d’une attaque SSRF peut être grave, allant de l’accès non autorisé à des données et des services sensibles à l’exploitation de systèmes internes, voire à la compromission d’environnements entiers du cloud.

Voici comment une attaque SSRF peut se dérouler dans la réalité.

Imaginez une application web non sécurisée qui permet aux utilisateurs de télécharger des images à des fins de traitement, avec une fonction qui permet aux utilisateurs de fournir une URL à une image qu’ils veulent traiter. Cependant, au lieu de fournir une URL d’image légitime, l’attaquant soumet une entrée soigneusement élaborée contenant une URL malveillante qui pointe vers une ressource interne sur le serveur d’application, telle qu’un fichier interne ou une base de données back-end. Le serveur d’application traite aveuglément l’URL malveillante et, suite à l’entrée de l’attaquant, fait une demande à la ressource interne spécifiée par l’URL pour récupérer des données sensibles ou interroger une base de données et renvoyer les données à l’attaquant.

Une fois le serveur compromis, l’attaquant peut également adresser des requêtes à des systèmes externes, rechercher des vulnérabilités ou interagir avec les services auxquels le serveur a accès. L’impact d’une attaque SSRF peut varier en fonction de l’architecture du système et des autorisations du serveur compromis. Les attaques peuvent conduire à un accès non autorisé aux données, à une interruption des services ou à la compromission des systèmes internes.

Les attaques SSRF peuvent être classées en différents types en fonction de la manière dont l’attaquant interagit avec le serveur et extrait des informations.

Dans une attaque SSRF standard, l’attaquant injecte une URL malveillante dans l’entrée de l’utilisateur, ce qui déclenche une requête du serveur vers la ressource spécifiée. L’attaquant peut observer directement la réponse du serveur et recueillir des informations sur le réseau interne, comme la manière de récupérer des données ou d’identifier les services accessibles.

Dans les attaques SSRF à l’aveugle, l’attaquant ne reçoit pas directement la réponse du serveur, mais confirme indirectement le succès ou l’échec de l’attaque SSRF en observant les changements de comportement de l’application.

L’attaquant soumet une entrée conçue pour forcer le serveur à faire une requête à une ressource externe ou interne. L’attaquant recherche des changements observables dans l’activité de l’application, tels que des différences dans les messages d’erreur, les temps de réponse ou d’autres effets secondaires. Ces informations aident l’attaquant à déduire si le SSRF a réussi, même si l’attaquant ne voit pas directement la réponse.

Les attaques SSRF aveugles temporelles consistent à exploiter les retards dans les réponses du serveur pour déduire le succès ou l’échec du SSRF sans voir directement la réponse.

Comme dans les autres attaques SSRF, l’attaquant soumet une entrée malveillante qui amène le serveur à adresser une requête à une ressource externe ou interne. L’attaquant observe le temps de réponse de l’application. Des retards dans le temps de réponse peuvent indiquer que le SSRF a réussi. L’attaquant ajuste itérativement la charge utile et surveille les retards pour extraire des informations sur le réseau ou les ressources internes.

Pour se protéger contre les attaques du SSRF, il convient de mettre en œuvre une combinaison de mesures préventives de cybersécurité, notamment :

• Une validation des entrées : valider et assainir rigoureusement les entrées fournies par l’utilisateur, en particulier lorsque l’application envoie des requêtes à des ressources externes. Mettre en place une liste d’URL autorisées, en n’autorisant que les domaines de confiance ou les URL spécifiques auxquels l’application doit accéder. S’assurer que seuls les protocoles attendus, tels que http et https, sont autorisés et éviter d’autoriser des protocoles potentiellement risqués tels que file:// ou ftp://, qui sont souvent exploités dans les attaques SSRF. Valider également que les URL fournies par les utilisateurs respectent les modèles ou les formats attendus, afin de réduire la probabilité d’injecter des URL malveillantes.
• Des Listes d’autorisation pour les hôtes et les adresses IP : maintenir une liste d’autorisation pour les hôtes et les adresses IP avec lesquels l’application est autorisée à interagir. Cela peut aider à restreindre les demandes à des destinations fiables et prévues, réduisant ainsi la surface d’attaque pour le SSRF.
• Restreindre l’accès aux ressources internes. Mettre en œuvre une segmentation du réseau pour limiter l’exposition des ressources internes. Veiller à ce que les serveurs externes aient un accès minimal aux systèmes et services internes. Configurer des Web Application Firewall (WAF) et des contrôles d’accès pour restreindre les connexions sortantes du serveur d’application. N’autoriser que les connexions nécessaires et prédéfinies et bloquer le trafic sortant inutile. Déployer un proxy inverse pour servir d’intermédiaire entre l’application et les ressources externes. Configurer le proxy pour contrôler les ressources externes auxquelles l’application peut accéder, ce qui ajoute une couche de contrôle supplémentaire.

Comment ces mesures préventives permettent-elles d’éviter les attaques SSRF ? Examinons un scénario hypothétique.

Un système de gestion de contenu en ligne permet aux utilisateurs de saisir des URL pour intégrer des images externes dans leurs messages. Ce système traite les URL fournies par les utilisateurs sans validation d’entrée appropriée. Un attaquant, conscient de l’absence de validation d’entrée, tente d’exploiter le système en fournissant une URL malveillante pointant vers une ressource interne, telle qu’un point de terminaison API interne ou un serveur de base de données. Cependant, l’équipe de sécurité de l’application améliore la validation d’entrée du système pour appliquer des règles strictes sur les URL acceptées. Le système commence à valider que les URL fournies par les utilisateurs adhèrent aux modèles attendus, et l’équipe met en œuvre une liste blanche de domaines autorisés pour les ressources externes.

L’attaquant soumet le message avec une URL élaborée destinée à exploiter la faille SSRF, mais la validation des entrées détecte maintenant l’URL malveillante. La validation des entrées rejette l’URL malveillante pendant le traitement, empêchant l’application de faire une demande à la ressource interne spécifiée par l’attaquant. L’attaque SSRF est contrecarrée par la validation des entrées améliorée : le système n’autorise pas les demandes non autorisées aux ressources internes, et l’intégrité et la sécurité des systèmes internes sont préservées.

En mettant en œuvre la validation des entrées, l’application peut rejeter ou assainir les entrées malveillantes, empêchant ainsi les demandes non autorisées et atténuant le risque d’attaques SSRF.

Les attaques SSRF sont dangereuses car elles permettent aux attaquants de contourner les mesures traditionnelles de sécurité du réseau, telles que les pare-feu et les contrôles d’accès, afin d’accéder aux informations et ressources sensibles qui sont généralement protégées au sein du réseau interne d’une organisation et ne sont pas destinées à être directement accessibles depuis l’Internet. Les attaques SSRF présentant des risques importants pour la confidentialité, l’intégrité et la disponibilité des données et des systèmes, les organisations doivent mettre en œuvre des mesures de sécurité robustes et les meilleures pratiques, y compris les WAFs, la validation appropriée des entrées, les contrôles d’accès et la segmentation du réseau, afin d’atténuer la menace des vulnérabilités SSRF et de se protéger contre leur exploitation potentielle.

Les solutions WAF de F5 bloquent et atténuent un large éventail de risques issus du OWASP Top 10, y compris le SSRF. Les solutions WAF de F5 combinent des protections par signature et comportementales, y compris la threat intelligence de F5 Labs et la sécurité automatisée via machine learning (ML) pour suivre le rythme des menaces émergentes. Elles allègent le fardeau et la complexité de la sécurisation cohérente des applications dans les clouds, sur site et les environnements edge, et sont disponibles dans divers choix d’options de déploiement. BIG-IP Advanced WAF est une solution robuste qui peut garder vos applications à l’abri des attaques SSRF et fournir un arrêt critique pour les vulnérabilités logicielles, tandis que F5 Distributed Cloud WAF sécurise les applications partout avec des opérations considérablement simplifiées grâce à une plateforme de sécurité facile d’utilisation.

Les solutions F5 web Application et API Protection (WAAP) défendent l’intégralité de la surface d’attaque des applications modernes avec des protections complètes qui incluent les WAF, API security, l’atténuation des DDoS L3-L7 et Bot Defense contre les automatisations malveillantes et les menaces automatisées. La plateforme distribuée facilite le déploiement de politiques cohérentes et la mise à l’échelle de la sécurité sur l’ensemble de votre parc d’applications et d’API, quel que soit l’endroit où elles sont hébergées, et intègre la sécurité dans le cycle de vie des API et des écosystèmes plus larges.