Qu’est-ce que le cross-scripting?

imageXSS pour cross-site scripting est en fait une méthode pour outrepasser la sécurité des navigateurs côté client via de l’injection de scripts. Ces scripts permettent à des hackers de récupérer différents types d’information ou encore de faire faire des actions à la machine de l’utilisateur (voir schéma ci-contre).

Un problème qui a son importance! Notamment quand on assiste à la démultiplication des accès et usages sur le Web.

Il existe différents types d’attaque XSS, je vous renvoie vers le site suivant pour plus d’informations: http://www.xssed.com/xssinfo#Types

 

Le filtre XSS IE8, comment fonctionne-t-il?

Le filtre XSS d’IE8 est un composant à part entière qui analyse les réponses qui transitent par la navigateur. Son rôle est d’identifier et neutraliser l’exécution de scripts non souhaitée. Il se concentre sur les imagevulnérabilités de type-1. Ce que l’on peut trouver sous le termes d’attaque XSS non persistante. C’est le type d’attaque le plus courant, il se traduit par la génération dynamique d’une réponse par le serveur où on peut injecter du code côté client si l’application ou le site Web n’applique pas l’encodage HTML.

 

 

Lors de l’identification de XSS on peut distinguer 3 grandes phases gérées par le filtre :

  • L’exécution scripting est bloquée
  • La réponse est modifiée
  • L’utilisateur est notifié

Le XSS filter ne se contente pas d’évaluer les URLs et les données en POST, il est capable de définir si oui ou non une attaque a été relayée dans la réponse du serveur. Il peut ainsi bloquer la partie identifiée comme potentiellement dangereuse et ne pas modifier entièrement la réponse.

Lors du développement du filtre, trois conditions ont dû être prises en compte:

  • Compatibilité: ne pas avoir une incidence sur le contenu ou la plus faible possible
  • Sécurité: être capable de bloquer la plupart des attaques tant que l’on respecte l’équilibre avec la performance et la compatibilité.
  • Performance: les utilisateurs préfèrent un navigateur rapide. Même si cela signifie que le navigateur est moins sécurisé, il faut donc trouver un juste milieu….pas simple! :)image

On peut d’ailleurs noter qu’initialement on parlait de MIME filter pour l’analyse des réponses entre le client et le serveur Web. Trop coûteux au niveau performance, on a basculé l’analyse au niveau MSHTML, tout simplement au niveau du moteur de rendu.

La performance a également été traitée en appliquant le filtre que pour le contenu où potentiellement une vulnérabilité existe via l’exécution d’un script. Par exemple, il ne sera pas utilisé pour du contenu de type image.

Un point essentiel de l’analyse du filtre est lorsque l’URL initiale est différente de l’URL de destination ou encore lorsqu’on ne peut pas déterminer une source lors d’une sélection d’un favori par exemple.

Nous voulions vous présenter brièvement ce mécanisme qui prend toute son importance, tous les grands sites Web ont subi/fait subir des vulnérabilités XSS. Premier post d’une longue série sur toutes les nouveautés en termes de sécurité, compatibilité et développement!! :)

 

Stay tuned
Vincent