Sécurité et confidentialité des applications Web :
Problématique du Cross Site Scripting (XSS)

Survol de la présentation

Les applications Web étant de plus en plus utilisées et de plus en plus complexes, les problématiques reliées à la sécurité et à la confidentialité des informations transigant par celles-ci se font de plus en plus présentes. Un de ces problèmes de plus en plus fréquent est malheureusement mal connu et souvent mal expliqué: c'est le Cross Site Scripting (XSS), ou le scripting par sites croisés.

1. Cross Site Scripting (XSS) : La définition courte
2. Particularités du XSS (2)
3. Les risques du Cross Site Scripting
4. Les types d'applications Web potentiellement vulnérables
5. 1er cas exemple : les applications Webmail
6. 2e cas exemple : les sites de commerce électronique avec revues d'utilisateurs
7. 3e cas exemple : les messages d'erreur
8. 4e cas exemple : les blogues
9. Outils et méthodes pour éviter et détecter le XSS
10. Références

Il n'existe pas à proprement dit de traduction pour Cross Site Scripting, le terme qui me semblait le plus proche est le scripting par sites croisés.

Particularités du XSS (1)

• La vulnérabilité affecte le client et non le serveur de l'application Web. (*)
• Utilise une faiblesse au niveau de la validation des paramètres en entrées, ou de leur analyse syntaxique. (Comme l'injection SQL ou le dépassement de pile)
• L'utilisation de SSL, ou d'autres mécanismes de chiffrement n'élimine pas le problème.
• Il est relativement difficile (parfois impossible) de détecter ce type d'intrusion.
• Les pare-feux conventionnels n'ont pas d'effet non plus sur ce type d'attaques.

(*) Le client est attaqué par « ricochet » en utilisant le serveur.

Particularités du XSS (2)

• Le XSS touche l'exécution de DHTML non autorisé sur un fureteur, plus spécifiquement l'exécution de javascript, de (X)HTML ou de CSS.
• Deux type de XSS : Permanent et Transitoire
• Le XSS permanent est identique pour tous les utilisateurs, le DHTML provient normalement d'une base de données, mise à jour par l'application contenant la faiblesse.
• Une page infectée par le XSS transitoire est générée dynamiquement à partir d'un lien url contenant toute l'attaque. Ce type d'attaque nécessite de l'ingenierie sociale. Elle cible un utilisateur particulier (ex: par e-mail).
• Les paramètres du url comprenant l'attaque sont généralement camouflés en utilisant les codes hexadécimaux.

(*) Le client est attaqué par « ricochet » en utilisant le serveur de l'application Web.

Les risques d'une attaque XSS

• Affichage de contenu subversif semblant provenir d'un site (ex: publicité, attaque à l'image de marque)
• Redirection vers un autre site
  • Pour confondre l'utilisateur
  • Pour profiler l'utilisateur
  • Pour attaquer ce site. Ex: par dépassement de pile
• Vol d'information (session, d'information entrée sur la page infectée, autres informations stockées dans les cookies)
• Dans certains cas, le risque peut être mitigé. En effet, il est souvent possible que de s'attaquer soit même (dans le cas des pages de confirmation par exemple).

Le XSS peut servir au vol d'identité ou à l'attaque de l'image d'une entreprise

Les types d'applications Web potentiellement vulnérables

En fait, tous les sites web sont potentiellement vulnérables. Des failles XSS ont été trouvées dans les pages d'erreur de serveurs Web (Microsoft IIS et Apache Tomcat entre autres) et dans des modules fortement utilisés (sur PHP et ASP entre autres).

Certaines applications sont potentiellement plus vulnérables puisqu'elles acceptent des paramètres qui sont réaffichés dans des pages HTML

• Les Webmail (Yahoo, HotMail, etc.)
• Sites de commerce électronique (achats, banques)
• Journaux électronique (weblogs, blogues)
• Sites de clavardages

Note: N'importe quoi dans la requête HTTP peut être modifié pour effectuer une attaque XSS, pas seulement le query string.

1er cas exemple : les applications Webmail

1. Un utilisateur malfaisant envoie un courriel à la victime.
2. Le courriel contient un script javascript
3. La victime se connecte à l'application Webmail en entrant son code utilisateur et mot de passe
4. La connexion est sécurisée par SSL
5. Le serveur envoie un cookie au client contenant un identificateur unique de session.
6. La session a une durée de 20 minutes, pendant ce temps, le cookie est utilisé pour authentifier l'utilisateur.
7. L'utilisateur lit le message malfaisant
8. Malheureusement, l'application affiche le message tel quel, sans le valider
9. Comme javascript est nécessaire pour utiliser le webmail, le javascript s'exécute.
10. Le javascript accède au cookie contenant la session, et redirige le client vers un autre serveur en envoyant à celui-ci la session en paramètre
11. Le serveur malfaisant reçoit la session de la victime et redirige le client vers la page précédente
12. La victime remarque que l'interface utilisateur du webmail est disparue pendant deux secondes, mais ne s'inquiète pas.
13. L'utilisateur malfaisant a maintenant quelques minutes pour accéder au compte webmail et effectuer un vol d'identité

2e cas exemple : les sites de commerce électronique avec revues d'utilisateurs

1. Un utilisateur malfaisant poste une critique d'un disque sur un site de commerce électronique.
2. L'application Web ne valide pas correctement l'entrée et sauvegarde la critique qui contient un script
3. La victime se rend sur le site pour effectuer des achats avec sa carte de crédit.
4. Le serveur envoie un cookie au client contenant un identificateur unique de session.
5. La session a une durée de 20 minutes, pendant ce temps, le cookie est utilisé pour authentifier l'utilisateur.
6. La connexion est sécurisée par SSL
7. L'utilisateur lit le message malfaisant
8. Comme javascript est nécessaire pour utiliser le site de commerce électronique, le javascript s'exécute.
9. Le javascript accède au cookie contenant la session, et redirige le client vers un autre serveur en envoyant à celui-ci la session en paramètre
10. Le serveur malfaisant reçoit la session de la victime et redirige le client vers la page précédente
11. La victime remarque que l'interface utilisateur du site de commerce électronique est disparue pendant deux secondes, mais ne s'inquiète pas.
12. L'utilisateur malfaisant a maintenant quelques minutes pour accéder au compte du site de commerce électronique et effectuer des achats au nom de l'utilisateur

Note: La différence avec le 1er cas est que le message infecté est public.

3e cas exemple : messages d'erreur

1. Une application Web contient une page d'erreur 404 du type : La page "/pagerronnee" n'existe pas.
2. L'application Web réécrit le URL en entrée
3. L'application Web ne valide pas correctement l'entrée et la réaffiche directement.
4. L'utilisateur malfaisait envoie un courriel à la victime contenant un lien vers la page d'erreur.
5. Les paramètres de ce url sont camouflés et contiennent un script exécutable.
6. La victime suit le lien et est ensuite redirigée vers un autre site.
7. La victime pense être sur le site A, mais est en fait sur le site B.
8. Le serveur B peut alors collecter de l'information sur la victime qui pense être sur le site A.

Note: Ce type de XSS nécessite de l'ingénierie sociale et est de type transitoire.

4e cas exemple : les blogues

1. Un utilisateur malfaisant poste un message sur un blogue.
2. L'application Web ne valide pas correctement l'entrée et sauvegarde le message qui contient un script
3. La victime se rend sur le site pour lire le blogue.
4. Le serveur envoie un cookie au client contenant un identificateur unique de session.
5. La session a une durée de 20 minutes, pendant ce temps, le cookie est utilisé pour authentifier l'utilisateur.
6. La connexion est sécurisée par SSL
7. L'utilisateur lit le message malfaisant
8. Comme javascript est nécessaire pour utiliser le blogue, le javascript s'exécute.
9. Le javascript accède au cookie contenant la session, et redirige le client vers un autre serveur en envoyant à celui-ci la session en paramètre
10. Le serveur malfaisant reçoit la session de la victime et redirige le client vers la page précédente
11. La victime remarque que l'interface utilisateur du blogue est disparue pendant deux secondes, mais ne s'inquiète pas.
12. L'utilisateur malfaisant a maintenant quelques minutes pour accéder au compte weblog et effectuer un vol d'identité

Note: La différence avec le 1er cas est que le message infecté est public.

Références

1. Très bon document sur le XSS [en] [PDF].
2. Autre document intéressant [en] .
3. FAQ sur le XSS [en].
4. The Anatomy of Cross Site Scripting [en].
5. Recherche sur Cross Site Scripting sur Security Focus [en]
6. Cross Site Scripting avancé, utilisant la méthode HTTP POST [en]
7. Entrée de blogue très intéressante sur comment protéger les sections critiques d'un site contre le Cross Site Scripting [en]
8. Dernière faille XSS sur Hotmail et Yahoo publiée la vieille de cette présentation [en]