Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 





















Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Les failles XSS en question

février 2022 par Roberto Chemama et Antoine Planque, étudiants en Master 1 Informatique : parcours Cybersécurité à l’Université de Paris (ex-Paris Descartes)

Les applications qui s’exécutent dans un environnement Web font intervenir bon nombre de technologies que ce soit côté client (type de navigateur, version de navigateur, …) que côté serveur (type de serveur, système de gestion de base de données…) et génèrent donc une grande surface d’attaque.

© maraga

En effet, l’OWASP qui est une association qui travaille sur la sécurité des applications Web, a publié la liste des dix vulnérabilités majeures qu’on peut retrouver dans cet environnement.
En 2021, cette liste est mise à jour pour la troisième fois pour dévoiler une catégorisation de ces failles.

Celle qui nous intéresse dans cet article est la faille XSS qui passe de la nomenclature A07:2017-Cross-Site Scripting (XSS) à A03:2021-Injection.

Ce n’est pas par hasard si la faille XSS est désormais catégorisée dans les injections car elle consiste à injecter des fragments de code (HTML, JavaScript) dans une page Web qui l’interprète comme quelque chose de légitime.

1) Aperçu de la faille XSS et de ses différents types

On peut distinguer trois principaux types de failles XSS : Reflected XSS, Stored XSS, DOM XSS.
L’exploitation de la faille réfléchie se fait habituellement via une URL qui va afficher une page de résultat.
La faille stockée s’exploite en stockant le contenu malicieux dans la base de données.
Quant à la faille DOM, tout se passe directement dans le navigateur de la victime sans utiliser le serveur web.
Les failles réfléchies et DOM sont dites non-permanentes, c’est-à-dire que le script n’est pas stocké sur le serveur web, à la différence de la faille stockée dite permanente où le contenu malicieux est stocké sur le serveur web.

Cette description de ces trois types de failles nous amène à nous intéresser à un quatrième type de faille XSS : la faille Blind XSS.

2) Une faille XSS plus obscure : la faille Blind XSS

La faille Blind XSS est beaucoup moins évoquée que les trois précédentes et pourtant elle peut être plus dévastatrice.

En effet, elle entre dans la catégorie des failles persistantes et c’est une variante des failles stockées et réfléchies.

Elle consiste en l’injection d’une charge utile (payload) malveillante à un endroit de l’application web qui sera exécutée a posteriori à un autre endroit de l’application Web voire dans une autre application Web.

Prenons l’exemple d’un utilisateur malveillant qui poste un message dans le chat d’un forum. La charge utile contenue dans le message se retrouve stockée en base de la même manière que les autres messages du chat. D’une part, elle peut être réfléchie (exécutée) par le prochain utilisateur qui veut poster un message dans le chat car son navigateur chargera tous les commentaires dont le malveillant. D’autre part, elle peut être réfléchie lors de la consultation des logs (fichiers de journalisation) par l’administrateur du forum donc dans une autre application.

Du point de vue de l’attaquant, cette faille est plus difficile à mettre en place car elle nécessite d’avoir une vue de l’ensemble de l’application Web et des communications entre les modules de cette dernière.

La charge utile peut ne jamais être exécutée dans le cas où la zone piégée n’est pas visitée ; c’est un peu comme une bouteille qu’on envoie à la mer sans savoir où elle arrivera.

3) La sécurisation de ces failles et les moyens de s’en prémunir

Pour identifier si un site est vulnérable aux failles XSS il faut le tester. Aujourd’hui les attaquants utilisent des outils d’automatisation afin d’être plus productifs et c’est ce que nous devons utiliser pour faire nos pentests. Les outils les plus connus pour évaluer la sécurité des applications web sont BurpSuite et OWASP ZAP (Zed Attack Proxy).

La sécurisation d’une application web contre la faille XSS a principalement lieu au niveau du code. Par exemple, en PHP on utilise des méthodes particulières tel que htmlspecialchars() qui convertit les caractères spéciaux telles que les balises en entités HTML ou htmlentities() qui filtre toutes les entités HTML. Il est aussi recommandé d’activer le paramètre HttpOnly sur les cookies qui empêche leur récupération via JavaScript.

Malgré que la faille XSS soit une faille connue depuis longtemps, elle reste tout de même présente au sein de nombreux sites web notamment développés par des novices mais pas que. En effet, on a su il y a plusieurs jours que le logiciel de messagerie de Free, Zimbra, a été victime de plusieurs vagues de phishing comportant des liens exploitant la faille XSS. Les attaquants auraient pu avoir accès à des données de messagerie, des pièces jointes et des cookies.
Le machine learning pourrait aider à développer la sécurité contre la faille XSS. Des recherches faites à l’Université de Edmonton Concordia au Canada ont montré un intérêt pour la détection de la faille Blind XSS via les classificateurs N-gram et SVM utilisés pour le machine learning.

Etant donné que de nombreux sites web contiennent un grand nombre de failles encore aujourd’hui, des bug bounty sont parfois mis en place par les propriétaires de ces sites afin de les rendre mieux sécurisés. Des récompenses très intéressantes sont parfois données par ces entreprises. En 2020 une équipe de white hackers pilotée par Sam Curry (un jeune homme de 20 ans) a reçu 288 000 dollars d’Apple pour avoir identifié plusieurs failles de sécurité dont des failles XSS.


Voir les articles précédents

    

Voir les articles suivants