Filtre IE8 XSS: qu’est-ce que ça fait vraiment?

Internet Explorer 8 dispose d’une nouvelle fonctionnalité de sécurité, un filtre XSS qui tente d’intercepter les tentatives de script intersite. C’est décrit ainsi:

Le filtre XSS, nouveauté d’Internet Explorer 8, détecte le JavaScript dans les requêtes URL et HTTP POST. Si JavaScript est détecté, le filtre XSS recherche des preuves de reflection, des informations qui seraient renvoyées au site Web attaquant si la demande d’attaque était soumise sans modification. Si une reflection est détectée, le filtre XSS nettoie la demande d’origine afin que le JavaScript supplémentaire ne puisse pas être exécuté.

Je trouve que le filtre XSS intervient même lorsqu’il n’y a pas de “preuve de reflection”, et je commence à penser que le filtre remarque simplement lorsqu’une demande est faite sur un autre site et que la réponse contient du JavaScript.

Mais même cela est difficile à vérifier car l’effet semble aller et venir. IE a différentes zones, et juste quand je pense avoir reproduit le problème, le filtre ne se déclenche plus, et je ne sais pas pourquoi.

Quelqu’un at-il des conseils sur la façon de lutter contre cela? Qu’est-ce que le filtre cherche vraiment? Y at-il un moyen pour un bon gars de POST des données sur un site tiers qui peut renvoyer le HTML à afficher dans un iframe et ne pas déclencher le filtre?

Contexte: je charge une bibliothèque JavaScript à partir d’un site tiers. Que JavaScript recueille des données à partir de la page HTML en cours et les publie sur le site tiers, qui répond avec du HTML à afficher dans un iframe. Pour le voir en action, visitez une page AOL Food et cliquez sur l’icône “Imprimer” juste au-dessus de l’histoire.

Qu’est-ce que ça fait vraiment? Il permet à des tiers de se connecter à une version endommagée de votre site.

Il se déclenche quand [quelques conditions sont réunies et] il voit une chaîne dans la soumission de requête qui existe également dans la page et qui, selon elle, pourrait être dangereuse.

Cela suppose que si existe à la fois dans la chaîne de requête et le code de la page, cela doit être dû au fait que votre script côté serveur n’est pas sécurisé et reflète cette chaîne comme un balisage sans s’échapper.

Mais bien sûr, mis à part le fait que c’est une requête parfaitement valide, quelqu’un aurait pu le taper par hasard, il est également possible qu’ils correspondent car quelqu’un a regardé la page et en a délibérément copié une partie. Par exemple:

http://www.bing.com/search?q=%3Cscript+type%3D%22text%2Fjavascript%22%3E

Suivez-le dans IE8 et j’ai réussi à saboter votre page Bing afin qu’elle génère des erreurs de script, et que les bits de résultat des fenêtres contextuelles ne fonctionnent pas. Essentiellement, cela donne à un attaquant dont le lien est suivi une licence pour sélectionner et désactiver des parties de la page qu’il n’aime pas – et cela pourrait même inclure d’autres mesures de sécurité telles que les scripts de framebuster.

Qu’est-ce que IE8 considère comme potentiellement dangereux? Beaucoup de choses plus étranges que cette simple balise de script. par ex . De plus, il semble correspondre à un ensemble de modèles «dangereux» utilisant un système de modèle de texte (probablement une expression régulière), au lieu de tout type d’parsingur HTML tel que celui qui finira par parsingr la page elle-même. Oui, utilisez IE8 et votre navigateur pařṣin̈́͜g HT̈́͜ML w̧̼̜it̏̔h ͙r̿e̴̬g̉̆e͎x͍͔̑̃̽̚.

La protection XSS en regardant les chaînes dans la requête est totalement fausse . Il ne peut pas être “corrigé”; le concept même est insortingnsèquement défectueux. Mis à part le problème d’intervenir quand il n’est pas voulu, il ne peut jamais vraiment vous protéger des attaques les plus élémentaires – et les attaquants contourneront sûrement ces blocs, car IE8 sera plus largement utilisé. Si vous avez oublié d’échapper correctement à votre sortie HTML, vous serez toujours vulnérable. toute la «protection» XSS doit vous offrir un faux sentiment de sécurité. Malheureusement, Microsoft semble aimer ce faux sentiment de sécurité; il existe également une «protection» XSS similaire dans ASP.NET, côté serveur.

Donc, si vous avez une idée sur la création d’une application Web et que vous avez correctement échappé à la sortie HTML comme un bon garçon, désactivez cette intrusion indésirable, impraticable et erronée en affichant l’en-tête:

 X-XSS-Protection: 0 

dans vos réponses HTTP. (Et en utilisant ValidateRequest="false" dans vos pages si vous utilisez ASP.NET.)

Pour tout le monde, qui continue à assembler des chaînes en PHP sans prendre soin de l’encoder correctement … vous pouvez tout aussi bien le laisser. Ne vous attendez pas à ce que cela protège réellement vos utilisateurs, mais votre site est déjà cassé, alors qui se soucie de savoir si ça casse un peu plus, non?

Pour le voir en action, visitez une page AOL Food et cliquez sur l’icône “Imprimer” juste au-dessus de l’histoire.

Ah oui, je peux voir cette rupture dans IE8. Pas immédiatement évident où IE a fait le hack au contenu qui l’a arrêté en cours d’exécution … la seule demande http://h30405.www3.hp.com/print/start que je peux voir qui est un candidat pour le filtre XSS est celle-ci à http://h30405.www3.hp.com/print/start :

 POST /print/start HTTP/1.1 Host: h30405.www3.hp.com Referer: http://recipe.aol.com/recipe/oatmeal-butter-cookies/142275? csrfmiddlewaretoken=undefined&characterset=utf-8&location=http%253A%2F%2Frecipe.aol.com%2Frecipe%2Foatmeal-butter-cookies%2F142275&template=recipe&blocks=Dd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%28%2B.%2F%2C%28%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk%7Cpspm%3Db3%3Fd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%7D%2F%27%2B%2C.%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk... 

ce paramètre blocks continue avec les pages plus de charabia. Vraisemblablement, il y a quelque chose qui (par coïncidence?) Se reflète dans le code HTML renvoyé et déclenche l’une des idées erronées d’IE8 sur l’apparence d’un exploit XSS.

Pour résoudre ce problème, HP doit inclure le serveur h30405.www3.hp.com dans l’en-tête X-XSS-Protection: 0 .

Vous devez m’envoyer (ericlaw @ microsoft) une capture réseau (www.fiddlercap.com) du scénario que vous pensez incorrect.

Le filtre XSS fonctionne comme suit:

  1. XSSFILTER est-il activé pour ce processus?
    Si oui – passez à la vérification suivante Si non – ignorez le filtre XSS et continuez le chargement
  2. Un “document” est-il chargé (comme un cadre, pas un sous-téléchargement)? Si oui – passez à la vérification suivante Si non – ignorez le filtre XSS et continuez le chargement
  3. Est-ce une demande HTTP / HTTPS? Si oui – passez à la vérification suivante Si non – ignorez le filtre XSS et continuez le chargement
  4. Est-ce que RESPONSE contient l’en-tête x-xss-protection? Oui: Valeur = 1: Filtre XSS activé (pas de vérification d’urlaction) Valeur = 0: Filtre XSS désactivé (pas de vérification d’URLaction) Non: passez à la vérification suivante
  5. Le site se charge-t-il dans une zone où URLAction active le filtrage XSS? (Par défaut: Internet, approuvé, restreint) Si oui – passez à la vérification suivante Si non – ignorez le filtre XSS et continuez le chargement
  6. Est-ce qu’une demande intersite? (En-tête du référent: le nom de domaine complet (post-redirection) complet de l’en-tête du référent de requête HTTP correspond-il au nom de domaine complet de l’URL en cours de récupération?) Si oui, ignorez XSS Filter l’URL dans la demande doit être stérilisée.
  7. L’heuristique indique-t-elle que les données de la réponse proviennent de données dangereuses REQUEST DATA? Si oui – modifiez la réponse.

Maintenant, les détails exacts de # 7 sont assez compliqués, mais fondamentalement, vous pouvez imaginer qu’IE fait une correspondance entre les données de requête (URL / corps de message) et les données de réponse (corps de script). modifié.

Dans le cas de votre site, vous voudrez regarder le corps du POST sur http://h30405.www3.hp.com/print/start et la réponse correspondante.

En fait, c’est pire que cela pourrait paraître. Le filtre XSS peut rendre les sites sécuritaires dangereux. Lisez ici: http://www.h-online.com/security/news/item/Security-feature-of-Internet-Explorer-8-unsafe-868837.html

De cet article:

Cependant, Google désactive le filtre XSS d’IE en envoyant l’en-tête X-XSS-Protection: 0, ce qui le rend insensible.

Je ne sais pas assez sur votre site pour juger si cela peut être une solution, mais vous pouvez probablement essayer. Plus en détail, la discussion technique sur le filtre, et comment le désactiver est ici: http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html