Qu'est-ce que le cross-site scripting (XSS) ?

Selon l'OWASP (Open Web Application Security Project), les attaques XSS appartiennent à l'une des trois catégories suivantes : XSS reflété, XSS stocké et XSS Document Object Model (DOM). Ils sont détaillés ci-dessous. 

Une attaque XSS réfléchie se produit lorsqu'un pirate informatique livre un script malveillant à une application Web vulnérable, que le serveur renvoie ensuite dans la réponse HTTP. Le navigateur de la victime exécute le script malveillant dans le cadre de la réponse HTTP, compromettant l’utilisateur légitime et envoyant des informations privées au pirate. 

Les attaques XSS réfléchies ciblent généralement les messages d'erreur ou les pages de résultats du moteur de recherche, car il est facile d'envoyer un e-mail malveillant avec un lien sur lequel de nombreux utilisateurs cliqueront. Lorsque l'utilisateur clique sur le lien, le serveur reçoit la demande contenant le script malveillant, et comme il n'est pas stocké, il répond en renvoyant un code à l'utilisateur. Lorsque les entrées des utilisateurs ne sont pas correctement validées et désinfectées, ou lorsque les données sont dupliquées de manière dangereuse à partir d’une demande, il existe un risque de vulnérabilités XSS reflétées. 

La première ligne de défense contre les attaques XSS consiste à filtrer le contenu et à vérifier les entrées des utilisateurs. Vous pouvez utiliser les listes de sécurité et les listes de blocage des fournisseurs de script pour rejeter les modèles de données à risque. 

De plus, vous pouvez mettre en œuvre une politique de sécurité du contenu (CSP) stricte pour vous aider à identifier la source des scripts en ligne, réduisant ainsi le risque d'attaques XSS réfléchies. Un CSP robuste vous permet de contrôler les scripts et les emplacements des pages Web où ils peuvent être chargés et exécutés. 

L'interface DOM permet le traitement et la manipulation du contenu des pages Web en lisant et en modifiant les documents HTML et XML. Les attaques XSS basées sur DOM introduisent des modifications malveillantes dans le contexte DOM du navigateur de la victime, ce qui entraîne l'exécution involontaire du code côté client. 

Les attaques XSS basées sur DOM, contrairement aux attaques XSS reflétées et stockées, ne stockent pas le script malveillant et ne le livrent pas au serveur. Dans cette attaque, le navigateur de la victime est la seule vulnérabilité. Étant donné qu’elles sont plus difficiles à comprendre que d’autres catégories, les vulnérabilités basées sur les DOM sont rares, sophistiquées et difficiles à surmonter. De plus, les scanners de vulnérabilité automatisés et les pare-feu d'applications Web ne peuvent pas les identifier facilement. 

Vous pouvez utiliser les mêmes techniques pour éviter cette attaque que celles des deux autres, mais vous devez faire particulièrement attention à désinfecter le code côté client. Deux solutions efficaces consistent à empêcher les sources contrôlées par l’utilisateur de modifier les fonctions JavaScript potentiellement dangereuses (appelées « sinks ») ou à autoriser uniquement un contenu fiable en utilisant une liste sécurisée. Avec ces précautions, les chaînes qui pourraient mettre en danger le DOM ne seront pas envoyées dans les puits. Vous pouvez également désinfecter les données à l’aide de la fonctionnalité de navigateur intégrée, réduisant ainsi le risque de problèmes liés aux modifications de l’analyseur. 

Une nouvelle défense contre ce type d'attaque consiste à utiliser des types fiables. Il s’agit d’un mécanisme de sécurité du navigateur qui garantit que toutes les parties risquées du DOM ne peuvent être utilisées que par des données qui ont passé une politique prédéfinie. Il empêche les chaînes arbitraires d'être transmises à des puits potentiellement dangereux, ce qui aide le navigateur à différencier le code des données, éliminant ainsi la principale source de vulnérabilité. 

The DOM interface enables the processing and manipulation of web page contents by reading and modifying HTML and XML documents. DOM-based XSS attacks introduce malicious changes to the DOM context of the victim’s browser, causing the client-side code to be executed in unintended ways.

DOM-based XSS attacks, unlike reflected and stored XSS attacks, do not store the malicious script or deliver it to the server. In this attack, the victim's browser is the sole vulnerability. Since they’re more difficult to understand than other categories, DOM-based vulnerabilities are uncommon, sophisticated, and challenging to overcome. Moreover, automated vulnerability scanners and web application firewalls can’t easily identify them.

You can use the same techniques to prevent this attack as those for the other two, but you must take extra care to sanitize the client-side code. Two effective solutions are to prevent user-controlled sources from changing potentially dangerous JavaScript functions (known as sinks) or to allow only trustworthy content by using a safelist. With these precautions, strings that might endanger the DOM won't be sent to sinks. You can also sanitize the data using built-in browser functionality, reducing the risk of parser change-related problems.

A novel defense against this type of attack is to use trusted types. This is a browser security mechanism that ensures that all risky parts of the DOM can only be used by data that has passed a predefined policy. It prevents arbitrary strings from being passed to potentially dangerous sinks, which helps the browser differentiate between code and data—removing the main source of vulnerability.