La catégorie A10:2021 se penche sur un type de vulnérabilité particulièrement préoccupant dans les applications web modernes : la Falsification de Requête Côté Serveur (Server-Side Request Forgery, ou SSRF).
Bien que cette catégorie présente un taux d'incidence relativement faible, elle se distingue par un potentiel élevé d'exploitation et d'impacts, qui justifient une attention accrue.
Découvrez un cas d’attaque
En juillet 2019, Capital One, une des plus grandes banques et émetteurs de cartes de crédit des États-Unis, a été victime d'une attaque SSRF (Server-Side Request Forgery) majeure. Cet incident, connu sous le nom de "Capital One Breach", reste l'un des exemples les plus notables d'exploitation de vulnérabilités SSRF.
L'attaque a été orchestrée par un attaquant qui a exploité une vulnérabilité SSRF dans la configuration d'une application web hébergée sur un service de cloud computing.
Grâce à cette faille, l'attaquant a pu envoyer des requêtes falsifiées depuis le serveur de Capital One vers un service de gestion des métadonnées, lui permettant d'accéder à des rôles et des autorisations qu'il ne devait normalement pas avoir.
Cette vulnérabilité a permis à l'attaquant d'obtenir des clés d'accès qui lui ont donné accès à plus de 100 millions de comptes clients de Capital One. Les données compromises incluaient des noms, adresses, numéros de sécurité sociale, scores de crédit et historiques de paiement.
Cette brèche a eu un impact massif, non seulement sur la sécurité des données des clients, mais aussi sur la réputation et la confiance envers Capital One.
L'incident de Capital One souligne l'importance de sécuriser les applications web contre les vulnérabilités SSRF, en particulier dans les environnements cloud.
Il démontre également les conséquences potentiellement désastreuses d'une telle attaque, mettant en évidence le besoin de vigilance, de tests de sécurité rigoureux et d'une conception sécurisée des applications.
Appréhendez la falsification de requête côté serveur
Je n’ai pas bien compris le principe de l’attaque SSRF, en quoi ça consiste ?
Les attaques SSRF ciblent directement le serveur en exploitant la capacité de l'application à envoyer des requêtes à d'autres systèmes.
L'essence des failles SSRF est de manipuler une application pour qu'elle fasse des requêtes non autorisées. Si ces demandes parviennent à passer les contrôles de sécurité, l'attaquant peut alors accéder à des ressources ou des services qui devraient normalement être hors de portée.
Imaginons une situation où une entreprise héberge le site, myssrf.com, qui est vulnérable aux attaques SSRF. La même entreprise possède également un intranet, intranet.bestcompany.com, accessible uniquement en interne.
Un attaquant pourrait exploiter la faille sur myssrf.com pour envoyer une requête malveillante à intranet.bestcompany.com. Le serveur de l'intranet, considérant la requête comme venant de l'intérieur du réseau, pourrait accepter la requête. Ce type d'attaque utilise l'application vulnérable comme un cheval de Troie pour pénétrer dans des zones normalement inaccessibles.
Les services généralement protégés de l'accès externe, tels que les serveurs de messagerie, bases de données, serveurs web, serveurs de fichiers et plateformes cloud, peuvent être compromis. Même un pare-feu robuste peut se révéler inefficace, car les attaques SSRF agissent de l'intérieur du serveur.
Protégez-vous de la falsification de requête côté serveur
Comment puis-je alors me protéger des failles SSRF ?
Pour vous protéger de ces failles, vous devrez multiplier les axes de défense.
Mesure au niveau réseau
La segmentation du réseau est une méthode efficace qui consiste à isoler les fonctionnalités d'accès aux ressources distantes dans des réseaux distincts. Cette segmentation limite l'impact potentiel d'une attaque SSRF en confinant la portée de l'attaque à un sous-ensemble du réseau.
Quelles sont les actions que je dois mettre en pratique ?
Supposons que vous développiez une application web de commerce électronique. Cette application stocke des informations sensibles telles que les détails des utilisateurs et les informations de commande dans une base de données interne. Pour renforcer la sécurité et se protéger contre les failles SSRF, vous décidez d'appliquer des mesures de segmentation réseau.
Vous créez deux réseaux distincts :
un réseau de front-end où s'exécute le serveur web accessible par les utilisateurs,
et un réseau de back-end isolé où réside la base de données.
Cette segmentation est réalisée à l'aide d'un pare-feu physique ou d'un pare-feu virtuel (dans le cas d'une infrastructure cloud), qui contrôle strictement le trafic entre ces deux réseaux.
Une mesure intéressante serait de configurer votre pare-feu pour n'autoriser que les requêtes SQL spécifiques du serveur web au serveur de base de données, empêchant ainsi toute autre forme de trafic. Cela signifie que même si un attaquant parvenait à exploiter une vulnérabilité SSRF sur le serveur web, il ne pourrait pas utiliser cette faille pour initier des requêtes malveillantes vers des systèmes internes ou vers Internet, car le pare-feu bloque ces tentatives.
Mesures au niveau applicatif
1. Validation et assainissement des entrées : Toutes les données d'entrée fournies par le client doivent être rigoureusement validées et assainies. Cela inclut la vérification des schémas d'URL, des ports, et des destinations contre une liste blanche d'adresses autorisées.
Un schéma d'URL indique le protocole utilisé pour accéder à une ressource sur Internet ou localement. Par exemple,http:// indique une connexion non sécurisée à un site web, https:// indique une connexion sécurisée, et file:// est utilisé pour accéder à des fichiers locaux sur un serveur.
Pourquoi mettre en place cette protection ?
Imaginez que vous avez une application web qui permet aux utilisateurs de charger des images en fournissant une URL. L'application récupère ensuite l'image à cette URL pour la traiter ou l'afficher.
Un attaquant soumet une URL commençant par file:// pointant vers un fichier local sensible sur le serveur, tel qu'un fichier de configuration ( file:///etc/passwd sur un système Linux, par exemple). Si l'application ne vérifie pas le schéma de l'URL et tente d'accéder au fichier, elle peut involontairement divulguer des informations sensibles à l'attaquant.
2. Gestion des Réponses et Redirections : Évitez d'envoyer des réponses brutes aux clients et désactivez les redirections HTTP.
Mesures complémentaires
1. Séparez les services importants : Ne placez pas des services sensibles ou critiques sur les mêmes serveurs que ceux qui sont exposés au public. Pensez à isoler les services importants dans des zones sécurisées.
2. Utilisez des réseaux sécurisés pour les tâches sensibles : Pour les zones vraiment importantes de votre application, envisagez d'utiliser des connexions sécurisées comme les VPN, qui sont comme des tunnels privés et sécurisés dans l'internet.
En suivant ces étapes, vous pouvez protéger votre application web contre les attaques SSRF. Pensez à la sécurité comme à une série de barrières et de contrôles, plutôt que comme une seule grande muraille. Chaque mesure de sécurité que vous mettez en place est une barrière supplémentaire contre les attaquants.
En résumé
L’attaque Capital One Breach est un exemple frappant où une vulnérabilité SSRF a conduit à une brèche de sécurité majeure, mettant en évidence l'importance d'une architecture et d'une configuration sécurisées.
Les attaques SSRF exploitent la capacité d'une application à faire des requêtes vers des systèmes internes ou externes, permettant aux attaquants d'accéder à des ressources normalement inaccessibles.
La prévention des attaques SSRF demande une approche de défense en profondeur, combinant des mesures de sécurité à différents niveaux du système.
Chaque barrière de sécurité supplémentaire diminue le risque d'une exploitation réussie, protégeant ainsi les données sensibles et la réputation de l'entreprise.
Dans la prochaine partie, nous verrons l'importance d'intégrer les principes de développement sécurisé dès la conception de votre application web, pour prévenir de telles vulnérabilités et renforcer la sécurité globale de votre système. Mais avant ça, testez vos compétences, dans le quiz qui suit !
