IE8 filtre XSS: qu'est-il vraiment le faire?

Qu'est-ce que ça fait vraiment? Il permet à des tiers de créer un lien vers une version modifiée de votre site.

il s'active quand [quelques conditions sont remplies et] il voit une chaîne dans la soumission de requête qui existe aussi mot à mot dans la page, et qui pourrait être dangereuse.

Il suppose que si <script>something()</script> existe à la fois dans la chaîne de requête et dans le code de la page, alors ce doit être parce que votre script côté serveur n'est pas sûr et a reflété cette chaîne directement en tant que markup sans s'échapper.

Mais bien sûr, en dehors du fait que c'est parfaitement valide requête quelqu'un pourrait avoir tapé qui correspond, par hasard, il est tout aussi possible qu'ils correspondent parce que quelqu'un a regardé la page et délibérément copié une partie. Par exemple:

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

suivez ça dans IE8 et j'ai réussi à saboter votre Bing page donc il va donner des erreurs de script, et les bits de résultat pop-out ne fonctionnera pas. Essentiellement, il donne à un attaquant dont le lien est suivi la licence de choisir et désactiver les parties de la page qu'il n'aime pas - et qui pourrait même inclure d'autres mesures liées à la sécurité comme les scripts framebuster.

Qu'est-ce que IE8 considère comme "potentiellement dangereux"? Bien plus et bien plus étrange que cette étiquette de script. par exemple. Qui plus est, il semble correspondre à un ensemble de modèles 'dangereux' utilisant un système de motif de texte (probablement regex), au lieu de n'importe quelle sorte D'analyseur HTML comme celui qui finira par par analyser la page elle-même. Oui, utilisez IE8 et votre navigateur est pařing HTML avec regex.

' XSS protection’ en regardant les chaînes dans la requête est totalement bidon. Il ne peut pas être "fixé"; le concept même est intrinsèquement défectueux. Outre le problème d'intervenir lorsqu'il n'est pas voulu, il ne peut jamais vraiment vous protéger de tout sauf les attaques les plus basiques - et les attaquants vont sûrement contourner des blocs tels que IE8 devient plus largement utilisé. Si vous avez oublié d'échapper à votre sortie HTML correctement, vous serez toujours vulnérable; tout ce que XSS "protection" A à vous offrir est un faux sentiment de sécurité. Malheureusement Microsoft semble aimer ce faux sentiment de sécurité; il y a similaire XSS "protection" dans ASP.NET aussi, du côté du serveur.

donc si vous avez un indice sur webapp création et vous avez été correctement échapper à la sortie au format HTML comme un bon garçon, il est certainement une bonne idée de désactiver cette indésirable, impraticable, de l'entêtement d'intrusion par la sortie de l'en-tête:

X-XSS-Protection: 0

dans vos réponses HTTP. (Et à l'aide de ValidateRequest="false" dans vos pages si vous utilisez ASP.NET.)

pour tous les autres, qui élancent encore les chaînes ensemble en PHP sans prendre soin de coder correctement... eh bien, vous pourriez aussi bien le laisser sur. Ne vous attendez pas à réellement protéger votre utilisateurs, mais votre site est déjà cassé, alors qui se soucie si il casse un peu plus, non?

pour le voir en action, visitez la page des aliments AOL 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 piratage du contenu qui l'a arrêté l'exécution cependant... la seule requête cross-domaine que je peux voir qui est un candidat pour le filtre XSS est celui-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...

blocks parameter continue avec des pages plus charabia. Sans doute il est quelque chose il y a cela (par coïncidence?) est reflété dans le HTML retourné et déclenche l'une des idées dérangées de IE8 de ce à quoi ressemble un exploit XSS.

pour corriger cela, HP doit faire le serveur à h30405.www3.hp.com include the X-XSS-Protection: 0 en-tête.