BenoitPiette.COM

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

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.

Point suivant >>
1

Le Cross Site Scripting : La définition courte

Le Cross Site Scripting (XSS) est une attaque exploitant une faiblesse d'un site web qui valide mal ses paramètres en entrée. Un malfaiteur envoie du DHTML en paramètre à l'application. Celle-ci envoie ensuite ce DHTML à un autre utilisateur. Le DHTML provenant d'une tierce partie servira à afficher du contenu subversif, rediriger l'utilisateur vers un autre site ou à voler l'information du client accessible par le site Web.

L'acronyme du Cross Site Scripting est XSS et non CSS. Le CSS (Cascading Style Sheet), est un langage utilisé pour séparer les styles de la sémantique et du contenu des pages Web.

Point suivant>> <<Point précédent >>Table des matières <<
2

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.

Point suivant>> <<Point précédent >>Table des matières <<
3

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.

Point suivant>> <<Point précédent >>Table des matières <<
4

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

Point suivant>> <<Point précédent >>Table des matières <<
5

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.

Point suivant>> <<Point précédent >>Table des matières <<
6

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é
Point suivant>> <<Point précédent >>Table des matières <<
7

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.

Point suivant>> <<Point précédent >>Table des matières <<
8

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.

Point suivant>> <<Point précédent >>Table des matières <<
9

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.

Point suivant>> <<Point précédent >>Table des matières <<
10

Outils et méthodes pour éviter le XSS

  1. Toujours valider les paramètres en entrée et n'accepter que ce qui est explicitement autorisé. Cela inclut le paramètre provenant du query string et des requête POST ainsi que tout ce qui provient des entêtes HTTP (variable CGI, SERVER_NAME, etc)
  2. Encoder le HTML en sortie (changer < par &lt;)
  3. Certains environnements de développement / framework le font par défaut (ASP.NET par exemple)
  4. Auditer les applications Web à l'interne et à l'externe
  5. Faire attention à la réutilisation de composantes qui n'ont pas été développées avec la sécurité en tête (XP ?!?)
  6. Pare-feux applicatifs (application firewalls) (toutefois, ceux-ci ne couvrent pas tout)
  7. Protéger chaque accès critique par mot de passe. Ex: L'utilisateur doit entrer son mot de passe à nouveau à chaque point critique (modification de profil, mise à jour de base de données, achats, etc.).
Point suivant>> <<Point précédent >>Table des matières <<
11

Copyright 2002-2004 Benoit Piette, tous droits réservés

Point suivant>> <<Point précédent >>Table des matières <<