Qu'est-ce que SSRF ?

Lors d'une attaque SSRF, l'attaquant manipule généralement l'entrée utilisée 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 ne nettoie pas une URL saisie par un utilisateur avant d'extraire des données d'une ressource distante. L'attaquant peut obliger le serveur ciblé à effectuer des requêtes vers des destinations arbitraires, ce qui peut entraîner divers risques de sécurité. 

Ces attaques peuvent également se produire si la ressource ciblée entretient des relations de confiance avec d’autres systèmes, tels qu’un service de métadonnées cloud ou des API back-end, permettant à un attaquant de faire des requêtes à 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 récupération d’une URL est devenue un scénario courant. En conséquence, l’incidence de la SSRF est en augmentation. En outre, la gravité du SSRF augmente à mesure que les API et les services cloud sont devenus plus répandus et que les architectures informatiques sont devenues plus décentralisées et complexes.

SSRF est l'un des 10 principaux risques de sécurité des applications de l'OWASP , une compilation largement reconnue des risques de sécurité des applications Web les plus critiques. SSRF est également l'un des dix principaux risques de sécurité de l'OWASP communs aux applications et aux API , et mérite 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 pour une requête côté serveur. Cette entrée peut provenir de paramètres dans une URL, d'entrées utilisateur à partir de champs de formulaire ou d'autres sources de données.
• L'attaquant soumet une requête spécialement conçue, manipulant l'entrée pour pointer vers une ressource à laquelle l'attaquant souhaite accéder ou qu'il souhaite 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-feu 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 demande est effectuée du point de vue du serveur et non du navigateur de l'utilisateur, ce qui en fait une demande côté serveur.
• Si le serveur ciblé se trouve dans un réseau interne, l’attaquant peut tenter d’accéder et de récupérer des informations sensibles à partir de ressources internes, puis d’exfiltrer ces données vers un emplacement externe contrôlé par l’attaquant. SSRF peut également être utilisé pour analyser les ports des systèmes internes, aidant ainsi l'attaquant à identifier les faiblesses et vulnérabilités potentielles.
• Les attaques SSRF sont particulièrement préoccupantes dans les environnements 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 services sensibles à l’exploitation de systèmes internes et même à la compromission d’environnements cloud entiers.

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

Imaginez une application Web non sécurisée qui permet aux utilisateurs de télécharger des images à traiter, avec une fonctionnalité qui permet aux utilisateurs de fournir une URL vers une image qu'ils souhaitent traiter. Cependant, au lieu de fournir une URL d’image légitime, l’attaquant soumet une entrée soigneusement conçue contenant une URL malveillante qui pointe vers une ressource interne sur le serveur d’application, comme un fichier interne ou une base de données principale. Le serveur d'applications traite aveuglément l'URL malveillante et, suite à la saisie de l'attaquant, envoie 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 faire des requêtes à des systèmes externes, rechercher des vulnérabilités ou interagir avec des 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 de service 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 le cadre de la saisie de l'utilisateur, ce qui incite le serveur à effectuer une demande à la ressource spécifiée. L'attaquant peut observer directement la réponse du serveur et recueillir des informations sur le réseau interne, par exemple sur la manière de récupérer des données ou d'identifier les services accessibles.

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

L'attaquant soumet une entrée spécialement conçue, forçant le serveur à faire une demande à 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 s’il ne voit pas directement la réponse.

Les attaques SSRF aveugles basées sur le temps impliquent d'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 d’autres attaques SSRF, l’attaquant soumet une entrée malveillante, ce qui amène le serveur à effectuer une demande à une ressource externe ou interne. L’attaquant observe le temps que met l’application à répondre. Les retards dans le temps de réponse peuvent indiquer que le SSRF a réussi. L'attaquant ajuste de manière itérative la charge utile et surveille les délais pour extraire des informations sur le réseau interne ou les ressources.

Pour vous protéger contre les attaques SSRF, mettez en œuvre une combinaison de mesures de cybersécurité préventives, notamment : 

• Validation des entrées. Validez et nettoyez rigoureusement les entrées fournies par l'utilisateur, en particulier lorsque l'application envoie des demandes à des ressources externes. Implémentez la liste blanche d'URL, autorisant uniquement les domaines de confiance ou les URL spécifiques auxquels l'application doit accéder. Assurez-vous que seuls les protocoles attendus, tels que http et https, sont autorisés et évitez d'autoriser des protocoles potentiellement risqués tels que file:// ou ftp://, qui sont souvent exploités dans les attaques SSRF. Validez également que les URL fournies par les utilisateurs adhèrent aux modèles ou formats attendus, réduisant ainsi le risque d’injection d’URL malveillantes.
• Listes autorisées pour les hôtes et les adresses IP. Maintenez une liste blanche des hôtes et des adresses IP autorisés avec lesquels l'application est autorisée à interagir. Cela peut aider à restreindre les requêtes aux destinations fiables et prévues, réduisant ainsi la surface d'attaque pour SSRF. 
• Restreindre l'accès aux ressources internes. Mettre en œuvre la segmentation du réseau pour limiter l’exposition des ressources internes. Assurez-vous que les serveurs externes ont un accès minimal aux systèmes et services internes. Configurez les pare-feu d’applications Web (WAF) et les contrôles d’accès pour restreindre les connexions sortantes du serveur d’applications. Autorisez uniquement les connexions nécessaires et prédéfinies et bloquez le trafic sortant inutile. Déployez un proxy inverse pour agir comme intermédiaire entre l’application et les ressources externes. Configurez le proxy pour contrôler les ressources externes auxquelles l'application peut accéder, en ajoutant une couche de contrôle supplémentaire.

Comment ces mesures préventives aident-elles à prévenir les attaques SSRF ? Regardons 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 publications. Ce système traite les URL fournies par l'utilisateur sans validation d'entrée appropriée. Un attaquant, conscient du manque de validation des entrées, tente d’exploiter le système en fournissant une URL malveillante pointant vers une ressource interne, telle qu’un point de terminaison d’API interne ou un serveur de base de données. Cependant, l’équipe de sécurité de l’application améliore la validation des entrées 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 conçue pour exploiter la faille SSRF, mais la validation d'entrée détecte désormais l'URL malveillante. La validation d'entrée 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 d'entrée 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 implémentant 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 de sécurité réseau traditionnelles telles que les pare-feu et les contrôles d'accès pour accéder à des informations et des ressources sensibles qui sont généralement protégées au sein du réseau interne d'une organisation et qui ne sont pas destinées à être directement accessibles depuis Internet. Étant donné que les attaques SSRF présentent 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 des meilleures pratiques, notamment des WAF, une validation des entrées appropriée, des contrôles d’accès et une segmentation du réseau, pour atténuer la menace des vulnérabilités SSRF et se protéger contre une exploitation potentielle.

Les solutions F5 WAF bloquent et atténuent un large éventail de risques découlant du Top 10 de l'OWASP , y compris SSRF. Les solutions F5 WAF combinent des protections de signature et comportementales, y compris des renseignements sur les menaces de F5 Labs et une sécurité automatisée via l'apprentissage automatique (ML) pour suivre le rythme des menaces émergentes. Ils allègent le fardeau et la complexité de la sécurisation cohérente des applications dans les environnements cloud, sur site et périphériques, et sont disponibles dans un choix d'options de déploiement. BIG-IP Advanced WAF est une solution robuste qui peut protéger vos applications contre les attaques SSRF et fournir une solution provisoire 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 plate-forme de sécurité en tant que service facile à utiliser.  

Les solutions F5 Web Application and API Protection (WAAP) défendent l'intégralité de la surface d'attaque des applications modernes avec des protections complètes qui incluent WAF, la sécurité des API , l'atténuation des attaques DDoS L3-L7 et la défense des robots contre l'automatisation malveillante et les menaces automatisées. La plateforme distribuée simplifie 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 dans des écosystèmes plus larges.