Sécurisez vos applications web avec l'OWASP

Nouvelle entrée dans ce classement du Top 10 édition 2021, c’est la dernière vulnérabilité que vous allez pouvoir appréhender.

Les failles SSRF, pour Server Side Request Forgery, ou “falsification de requête côté serveur”, font leur apparition grâce à une enquête menée auprès des membres de la communauté sécurité.

Le 30 septembre 2019 apparaît dans la base de données des Common Vulnerabilities and Exposures (CVE) une faille notée 10.0, c'est-à-dire critique au maximum. Cette entrée touche le CMS WordPress, et ce, par le biais d’un plug-in appelé “Visualizer”. Plus récemment encore, le 21 mars 2021, une faille SSRF est mise en avant dans le produit Microsoft Exchange Server. L’exploitation de cette vulnérabilité dans un produit Microsoft Exchange Server, qui est la solution de serveur d’email de Microsoft, pourrait permettre d’accéder (entre autres) à l’ensemble des emails stockés, et de ce fait à la récupération de données sensibles, comme des mots de passe, ou des données confidentielles.

L’objectif premier des failles SSRF est la lecture de fichiers sur le serveur, à la différence des CSRF, les Cross Site Request Forgery, qui sont, elles, conçues pour exécuter une requête à l’insu d’un autre utilisateur.

Le principe des failles SSRF est simple : il consiste en l'envoi d’une requête pour obtenir des ressources. Si cette requête n’est pas détectée comme étant non autorisée, via des contrôles sur la requête, les ressources pourront être transmises. 

La demande de ressources peut provoquer des effets assez problématiques. Sur des solutions cloud, comme AWS, Google Cloud ou un Cloud OVH, les coûts sont souvent indexés sur les ressources utilisées. Vous imaginez bien que toute requête augmentant significativement les ressources utilisées augmente d’autant la facture… Et dans les risques, il y a aussi, dans le cas de mails, le risque d’être répertorié comme étant une source de spam, d’être mis dans une liste noire et de voir vos emails non distribués ou non lus.

Prenons un cas plus concret. Votre entreprise héberge sur l’un de ses serveurs un site, disonsmyssrf.comqui abrite un site expliquant le fonctionnement de différentes failles de l’OWASP. Ce site est malheureusement vulnérable.

Disons qu’en plus de ça, votre entreprise possède un intranet, accessible uniquement par les membres physiquement présents dans la société :intranet.bestcompany.com.

Pour faire simple, un attaquant pourrait exploiter la faille présente sur le sitemyssrf.compour envoyer une requête sur le siteintranet.bestcompany.com. Celui-ci acceptera la requête, du fait que le serveur est présent dans les locaux du serveur intranet. Pour le pare-feu aussi, les requêtes viendraient de l’intérieur du réseau, et ne seraient pas forcément bloquées de ce fait.

D’un certain point de vue, on se retrouve avec une sorte de principe de cheval de Troie.

Vous imaginez bien que l’attaque ciblant l’intérieur du serveur, les services fermés à toute opération extérieure ne sont pas protégés pour autant.

De ce fait, des informations peuvent être récupérées sur des éléments comme :

• le serveur mail ;

• la base de données ;

• le serveur web ;

• le serveur de fichier ;

• la plateforme cloud.

Et si vous pensiez être protégé par votre firewall, faites attention. Les failles SSRF fonctionnent en interne du serveur. L’application web d’où vient l’attaque n’est qu’un intermédiaire.

Pour vous protéger de ces failles, vous devrez multiplier les axes de défense.

Pour l’architecte ou le développeur, la principale façon de contrer ces failles est d’effectuer un contrôle sur le contenu qui est envoyé.

• Toute information envoyée vers un serveur via l’application web doit être nettoyée de tous caractères non voulus par exemple.

• Mais ce n’est pas tout. La mise en place de tests pour savoir si le contenu provient bien d’une liste blanche peut être une solution. Couplé à la mise en place d’une liste blanche, vous réduirez grandement les risques d’exploitation par SSRF.

• De plus, n’envoyez pas de réponses brutes, qui pourraient permettre de déduire la présence d’une faille. Toutes les réponses envoyées par l’application doivent être retravaillées.

Mais côté intégrateur/acheteur aussi, des éléments sont à mettre en place pour réduire les risques. Votre infrastructure doit contrôler tout le trafic réseau interne.

La mise en place d’outils d’analyse réseau doit être présente pour mettre en avant des communications entre des serveurs qui n’ont pas forcément de raisons d'avoir de transit l’un envers l’autre.