Qu’est-ce que la SSRF ?

La SSRF est un type de faille de sécurité qui se produit lorsqu’un attaquant manipule une application web ou une API afin de lui faire envoyer des requêtes à des ressources internes, ce qui peut entraîner un accès non autorisé, une exposition de données, la compromission du système et l’exécution de code à distance. Les attaquants contournent la validation des entrées et forcent les applications à accéder à des destinations web malveillantes, même si elles sont protégées par un pare-feu ou une solution de réseau privé virtuel (VPN).

Qu’est-ce qu’une attaque SSRF et comment fonctionne-t-elle ?

Lors d’une attaque SSRF, l’attaquant manipule généralement une 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 de récupérer des données depuis une ressource distante. L’attaquant peut ainsi amener le serveur ciblé à envoyer des requêtes vers des destinations arbitraires, ce qui peut entraîner divers risques de sécurité.

Ces attaques peuvent également se produire lorsque 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 backend. Un attaquant peut alors envoyer des requêtes à ces services de confiance afin d’extraire des informations sensibles ou d’effectuer des actions non autorisées.

À mesure que les applications web modernes offrent aux utilisateurs finaux des fonctionnalités pratiques, la récupération d’une URL est devenue un cas d’usage courant. Par conséquent, les attaques SSRF sont de plus en plus fréquentes. Leur gravité augmente également avec la généralisation des API et des services cloud, ainsi qu’avec la décentralisation et la complexification croissantes des architectures informatiques.

La SSRF fait partie du Top 10 de l’OWASP des risques de sécurité des applications, une liste largement reconnue des risques de sécurité les plus critiques pour les applications web. La SSRF fait également partie des dix principaux risques de sécurité de l’OWASP qui sont communs aux applications et aux API, et nécessite une attention particulière lors de la mise en œuvre de solutions de sécurité.

Voici comment fonctionne une attaque SSRF :

• L’application permet aux données saisies par l’utilisateur de déterminer l’URL ou la ressource cible d’une requête côté serveur. Ces données peuvent provenir de paramètres d’une URL, de champs de formulaire remplis par l’utilisateur ou d’autres sources de données.
• L’attaquant envoie une requête spécialement conçue en manipulant les données saisies afin de cibler une ressource à laquelle il souhaite accéder ou qu’il souhaite exploiter. Cette ressource peut être un serveur interne, un service backend, une API ou d’autres systèmes internes protégés par des pare-feu et inaccessibles depuis le réseau externe.
• Le serveur traite les données malveillantes saisies par l’utilisateur et crée une requête vers l’URL spécifiée. Cette requête est effectuée par le serveur, et non par le navigateur de l’utilisateur : il s’agit donc d’une requête côté serveur.
• Si le serveur ciblé se trouve au sein d’un réseau interne, l’attaquant peut tenter d’accéder à des informations sensibles provenant de ressources internes et de les récupérer, puis d’exfiltrer ces données vers un emplacement externe qu’il contrôle. La SSRF peut également servir à analyser les ports des systèmes internes, ce qui permet à l’attaquant d’identifier d’éventuelles faiblesses et vulnérabilités.
• 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, voire à la compromission d’environnements cloud entiers.

Exemple d’attaque SSRF

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éverser des images afin de les traiter et qui leur offre la possibilité de fournir l’URL d’une image à traiter. Cependant, au lieu de fournir l’URL d’une image légitime, l’attaquant envoie une entrée soigneusement conçue contenant une URL malveillante qui pointe vers une ressource interne du serveur d’applications, telle qu’un fichier interne ou une base de données backend. Le serveur d’applications traite aveuglément l’URL malveillante et, conformément aux instructions de l’attaquant, envoie une requête à la ressource interne indiquée par l’URL afin de récupérer des données sensibles ou d’interroger une base de données, puis renvoie les données à l’attaquant.

Une fois le serveur compromis, l’attaquant peut également envoyer 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 dont dispose le serveur compromis. Ces attaques peuvent entraîner un accès non autorisé à des données, une interruption de service ou la compromission de systèmes internes.

Trois types fondamentaux d’attaques SSRF

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

Attaque SSRF standard

Lors d’une attaque SSRF classique, l’attaquant injecte une URL malveillante dans les données saisies par l’utilisateur, ce qui amène le serveur à envoyer une requête à la ressource spécifiée. L’attaquant peut observer directement la réponse du serveur et recueillir des informations sur le réseau interne, notamment sur la manière de récupérer des données ou d’identifier les services accessibles.

Attaque SSRF aveugle

Lors d’attaques SSRF aveugles, l’attaquant ne reçoit pas directement la réponse du serveur. Il détermine plutôt indirectement si l’attaque SSRF a réussi ou échoué en observant les changements dans le comportement de l’application.

L’attaquant soumet une entrée spécialement conçue, obligeant le serveur à envoyer une requête à une ressource externe ou interne. Il recherche ensuite 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 lui permettent de déterminer si l’attaque SSRF a réussi, même s’il ne voit pas directement la réponse.

Attaque SSRF aveugle basée sur le temps

Les attaques SSRF aveugles basées sur le temps consistent à exploiter les délais de réponse du serveur afin de déterminer si l’attaque SSRF a réussi ou échoué, 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 à envoyer une requête vers une ressource externe ou interne. L’attaquant observe le temps que met l’application à répondre. Des délais de réponse peuvent indiquer que l’attaque SSRF a réussi. L’attaquant ajuste la charge utile de manière itérative et surveille les délais afin d’extraire des informations sur le réseau interne ou ses ressources.

Comment se protéger contre les attaques SSRF

Pour vous protéger contre les attaques SSRF, mettez en œuvre plusieurs mesures préventives de cybersécurité telles que :

• Validation des entrées. Validez et assainissez rigoureusement les données saisies par les utilisateurs, en particulier lorsque l’application envoie des requêtes à des ressources externes. Mettez en place une liste d’autorisation d’URL afin de n’autoriser que les domaines de confiance ou les URL spécifiques auxquels l’application doit accéder. Veillez à n’autoriser que les protocoles prévus, tels que http et https, et évitez les protocoles potentiellement dangereux comme file:// ou ftp://, souvent exploités dans les attaques SSRF. Vérifiez également que les URL fournies par les utilisateurs respectent les modèles ou formats attendus afin de réduire le risque d’injection d’URL malveillantes.
• Listes d’autorisation pour les hôtes et les adresses IP. Tenez à jour une liste d’autorisation des hôtes et des adresses IP avec lesquels l’application est autorisée à interagir. Cela permet de limiter les requêtes aux destinations fiables et prévues, réduisant ainsi la surface d’attaque des attaques SSRF.
• Restreindre l’accès aux ressources internes. Mettre en œuvre une segmentation du réseau afin de limiter l’exposition des ressources internes. Veiller à ce que les serveurs accessibles depuis l’extérieur disposent d’un accès minimal aux systèmes et services internes. Configurer des pare-feu d’applications web (WAF) et des contrôles d’accès afin de restreindre les connexions sortantes du serveur d’applications. Autoriser uniquement les connexions nécessaires et prédéfinies, et bloquer le trafic sortant superflu. Déployer un proxy inverse servant d’intermédiaire entre l’application et les ressources externes. Configurer le proxy afin de contrôler les ressources externes auxquelles l’application peut accéder, ajoutant ainsi une couche de contrôle supplémentaire.

Comment ces mesures préventives contribuent-elles à empêcher 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 afin d’intégrer des images externes dans leurs publications. Ce système traite les URL fournies par les utilisateurs sans valider correctement les données saisies. Conscient de cette absence de validation, un attaquant 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 chargée de la sécurité de l’application renforce la validation des données saisies afin d’imposer des règles strictes aux URL acceptées. Le système commence à vérifier que les URL fournies par les utilisateurs respectent les formats attendus, et l’équipe met en place une liste blanche de domaines autorisés pour les ressources externes.

L’attaquant publie le message avec une URL spécialement conçue pour exploiter la faille SSRF, mais la validation des entrées détecte désormais l’URL malveillante. Celle-ci est rejetée lors du traitement, ce qui empêche l’application d’envoyer une requête à la ressource interne indiquée par l’attaquant. L’attaque SSRF est ainsi déjouée grâce au renforcement de la validation des entrées : le système n’autorise aucune requête non autorisée vers les ressources internes, préservant ainsi l’intégrité et la sécurité des systèmes internes.

En mettant en œuvre une validation des entrées, l’application peut rejeter ou assainir les entrées malveillantes, empêchant ainsi les requêtes non autorisées et réduisant le risque d’attaques SSRF.

Comment F5 peut vous aider

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, afin d’accéder à des informations et à des ressources sensibles 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 comme des systèmes, les organisations doivent mettre en œuvre des mesures de sécurité robustes et appliquer les bonnes pratiques, notamment en utilisant des WAF, en validant correctement les entrées, en mettant en place des contrôles d’accès et en segmentant le réseau, afin d’atténuer la menace liée aux 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 Top 10 de l’OWASP, notamment les attaques SSRF. Les solutions WAF de F5 combinent des protections basées sur les signatures et les comportements, notamment les renseignements sur les menaces de F5 Labs et une sécurité automatisée reposant sur le machine learning (ML), afin de suivre l’évolution des menaces. Elles réduisent la charge et la complexité liées à la sécurisation cohérente des applications dans les environnements cloud, sur site et en périphérie, et proposent plusieurs options de déploiement. BIG-IP Advanced WAF est une solution robuste qui protège vos applications contre les attaques SSRF et offre une protection temporaire essentielle contre les vulnérabilités logicielles, tandis que F5 Distributed Cloud WAF sécurise les applications où qu’elles se trouvent, tout en simplifiant considérablement les opérations grâce à une plateforme de sécurité as-a-Service facile à utiliser.

Les solutions F5 de protection des applications web et des API (WAAP) protègent l’ensemble de la surface d’attaque des applications modernes grâce à des protections complètes comprenant un WAF, la sécurité des API, l’atténuation des attaques DDoS de couches 3 à 7 et une protection contre les bots, l’automatisation malveillante et les menaces automatisées. Cette plateforme distribuée permet de déployer facilement des politiques cohérentes, d’étendre la sécurité à l’ensemble de vos applications et API, quel que soit leur environnement d’hébergement, et d’intégrer la sécurité au cycle de vie des API ainsi qu’aux écosystèmes plus larges.