Qu'est-ce que l'en-tête http «X-XSS-Protection»?

J'ai donc joué avec HTTP pour le plaisir en telnet maintenant (c'est-à-dire en tapant telnet google.com 80et en mettant des GET et des POST aléatoires avec différents en-têtes et autres), mais je suis tombé sur quelque chose que google.com transmet dans ses en-têtes que je je ne sais pas.

J'ai parcouru http://www.w3.org/Protocols/rfc2616/rfc2616.html et je n'ai trouvé aucune définition pour cet en-tête http particulier que google semble jaillir:

GET / HTTP/1.1

HTTP/1.1 200 OK
Date: Wed, 01 Feb 2012 03:42:24 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=6ddbc0a0342e7e63:FF=0:TM=1328067744:LM=1328067744:S=4d4farvCGl5Ww0C3; expires=Fri, 31-Jan-2014 03:42:24 GMT; path=/; domain=.google.com
Set-Cookie: NID=56=PgRwCKa8EltKnHS5clbFuhwyWsd3cPXiV1-iXzgyKsiy5RKXEKbg89gWWpjzYZjLPWTKrCWhOUhdInOlYU56LOb2W7XpC7uBnKAjMbxQSBw1UIprzw2BFK5dnaY7PRji; expires=Thu, 02-Aug-2012 03:42:24 GMT; path=/; domain=.google.com; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

1000

Quelqu'un sait ce que X-XSS-Protectionc'est?

X-XSS-Protection est un en-tête HTTP compris par Internet Explorer 8 (et les versions plus récentes). Cet en-tête permet aux domaines d'activer et de désactiver le «filtre XSS» d'IE8, ce qui empêche certaines catégories d'attaques XSS. IE8 a le filtre activé par défaut, mais les serveurs peuvent s’éteindre en définissant

   X-XSS-Protection: 0

Voir également http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header. aspx

• X-XSS-Protection: 1 : Forcer la protection XSS (utile si la protection XSS a été désactivée par l'utilisateur)

• X-XSS-Protection: 0 : Désactiver la protection XSS

• Le jeton mode=blockempêchera le navigateur (navigateurs IE8 + et Webkit) de restituer les pages (au lieu de les nettoyer) si une attaque de réflexion XSS potentielle (= non persistante) est détectée.

/! \ Attention, mode=blockcrée une vulnérabilité dans IE8 ( plus d'informations ).

Plus d'informations: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx et http://blog.veracode.com / 2014/03 / directives-pour-la-configuration-des-en-têtes de sécurité /

Cet en-tête de réponse peut être utilisé pour configurer la protection XSS réfléchie intégrée d'un agent utilisateur. Actuellement, seuls Internet Explorer, Google Chrome et Safari (WebKit) de Microsoft prennent en charge cet en-tête.

Internet Explorer 8 a inclus une nouvelle fonctionnalité pour empêcher les attaques de script intersite réfléchies, connues sous le nom de filtre XSS . Ce filtre s'exécute par défaut dans les zones de sécurité Internet, Trusted et Restricted. Les pages de zone Intranet locales peuvent activer la protection en utilisant le même en-tête.

À propos de l'en-tête que vous avez publié dans votre question,

L'en-tête X-XSS-Protection: 1; mode=blockactive le filtre XSS. Plutôt que de nettoyer la page, lorsqu'une attaque XSS est détectée, le navigateur empêche le rendu de la page.

En mars 2010, nous avons ajouté à la prise en charge IE8 un nouveau jeton dans l'en-tête X-XSS-Protection, mode = block.

X-XSS-Protection: 1; mode=block

Lorsque ce jeton est présent, si une attaque potentielle de réflexion XSS est détectée, Internet Explorer empêchera le rendu de la page. Au lieu d'essayer de nettoyer la page pour supprimer chirurgicalement l'attaque XSS, IE ne rendra que «#».

Internet Explorer reconnaît une éventuelle attaque de script intersite. Il enregistre l'événement et affiche un message approprié à l'utilisateur. L'article MSDN décrit le fonctionnement de cet en-tête.

Comment ce filtre fonctionne dans IE ,

Plus d'informations sur cet article, https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-iv-the-xss-filter/

Le filtre XSS fonctionne comme un composant IE8 avec une visibilité sur toutes les demandes / réponses circulant dans le navigateur. Lorsque le filtre découvre un XSS probable dans une demande intersite, il identifie et neutralise l'attaque si elle est rejouée dans la réponse du serveur. Les utilisateurs ne sont pas confrontés à des questions auxquelles ils ne peuvent pas répondre - IE bloque simplement l'exécution du script malveillant.

Avec le nouveau filtre XSS, les utilisateurs d'IE8 Beta 2 rencontrant une attaque XSS de type 1 verront une notification comme celle-ci:

Notification d'attaque IE8 XSS

La page a été modifiée et l'attaque XSS est bloquée.

Dans ce cas, le filtre XSS a identifié une attaque de script intersite dans l'URL. Il a neutralisé cette attaque car le script identifié a été rejoué dans la page de réponse. De cette façon, le filtre est efficace sans modifier une demande initiale au serveur ou bloquer une réponse entière.

L'événement Filtre de script intersite est enregistré lorsque Windows Internet Explorer 8 détecte et atténue une attaque de script intersite (XSS). Des attaques de script intersite se produisent lorsqu'un site Web, généralement malveillant, injecte (ajoute) du code JavaScript dans des demandes par ailleurs légitimes à un autre site Web. La demande d'origine est généralement innocente, comme un lien vers une autre page ou un script CGI (Common Gateway Interface) fournissant un service commun (comme un livre d'or). Le script injecté tente généralement d'accéder à des informations ou services privilégiés que le deuxième site Web n'a pas l'intention d'autoriser. La réponse ou la demande reflète généralement les résultats vers le site Web malveillant. Le filtre XSS, une nouvelle fonctionnalité d'Internet Explorer 8, détecte JavaScript dans les requêtes URL et HTTP POST. Si JavaScript est détecté, le filtre XSS recherche des preuves de réflexion, des informations qui seraient renvoyées au site Web attaquant si la demande d'attaque était soumise sans changement. Si une réflexion est détectée, le filtre XSS nettoie la demande d'origine afin que le JavaScript supplémentaire ne puisse pas être exécuté. Le filtre XSS enregistre ensuite cette action en tant qu'événement de filtre de script intersite. L'image suivante montre un exemple de site qui est modifié pour empêcher une attaque de script intersite.

Source: https://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

Les développeurs Web peuvent souhaiter désactiver le filtre pour leur contenu. Ils peuvent le faire en définissant un en-tête HTTP:

X-XSS-Protection: 0

Plus d'informations sur les en-têtes de sécurité dans,

• Lignes directrices pour la définition des en-têtes de sécurité

• En-têtes HTTP de sécurité - X-XSS-PROTECTION

• Protection MDN Docs X-XSS

Vous pouvez voir dans cette liste d'en-têtes HTTP utiles .

X-XSS-Protection: cet en-tête active le filtre de script intersite (XSS) intégré aux navigateurs Web les plus récents. Il est généralement activé par défaut de toute façon, donc le rôle de cet en-tête est de réactiver le filtre pour ce site Web particulier s'il a été désactivé par l'utilisateur. Cet en-tête est pris en charge dans IE 8+ et dans Chrome (je ne sais pas quelles versions). Le filtre anti-XSS a été ajouté dans Chrome 4. Son inconnu si cette version respectait cet en-tête.

TL; DR: Tous les sites Web (/ applications) bien écrits doivent émettre un en-tête X-XSS-Protection: 0et oublier cette fonctionnalité. Si vous voulez avoir une sécurité supplémentaire que de meilleurs agents utilisateurs peuvent fournir, utilisez un en- Content-Security-Policytête strict .

Longue réponse:

En-tête HTTP X-XSS-Protection est l'une de ces choses que Microsoft a introduites dans Internet Explorer 8.0 (MSIE 8) qui était censée améliorer la sécurité des sites Web mal écrits.

L'idée est d'appliquer une sorte d'heuristique pour essayer de détecter l'attaque XSS par réflexion et neutraliser automatiquement l'attaque.

La partie problématique de ceci est "l'heuristique" et la "stérilisation". L'heuristique provoque des faux positifs et la stérilisation ne peut pas être effectuée en toute sécurité car elle provoque des effets secondaires qui peuvent être utilisés pour implémenter des attaques XSS et des attaques DoS sur des sites Web parfaitement sûrs.

La mauvaise partie est que si un site Web n'émet pas l'en-tête, X-XSS-Protectionle navigateur se comportera comme si l'en-tête X-XSS-Protection: 1avait été émis. Le pire, c'est que cette valeur est la valeur la moins sûre de toutes les valeurs possibles pour cet en-tête!

Pour un site Web sécurisé donné (c'est-à-dire que le site n'a pas de vulnérabilités de réflexion XSS), cette fonctionnalité de "protection XSS" permet les attaques suivantes:

X-XSS-Protection: 1permet à l'attaquant de bloquer sélectivement des parties de JavaScript et de maintenir le reste des scripts en cours d'exécution. Ceci est possible car les heuristiques de cette fonctionnalité sont simplement "si la valeur d'un paramètre GET est trouvée dans la partie de script de la page source, le script sera automatiquement modifié de manière dépendante de l'agent utilisateur". Dans la pratique, l'attaquant peut par exemple ajouter un paramètre transformant incorrectement des données en texte brut en code JavaScript exécutable .disablexss=<script src="framebuster.js" et le navigateur supprimera automatiquement la chaîne en<script src="framebuster.js" de la source de page réelle. Notez que le reste de la page continue de s'exécuter et que l'attaquant vient de supprimer cette partie de la sécurité de la page. En pratique, tout JS dans la source de page peut être modifié. Dans certains cas, une page sans vulnérabilité XSS ayant un contenu réfléchi peut être utilisée pour exécuter le JavaScript sélectionné sur la page en raison de la stérilisation

X-XSS-Protection: 1; mode=blockpermet à l'attaquant de divulguer des données de la page source en utilisant le comportement de la page comme canal latéral. Par exemple, si la page contient du code JavaScript dans le sens de var csrf_secret="521231347843", l'attaquant ajoute simplement un paramètre supplémentaire, par exemple leak=var%20csrf_secret="3et si la page n'est PAS bloquée, le 3premier chiffre était incorrect. L'attaquant essaie à nouveau, cette fois leak=var%20csrf_secret="5et le chargement de la page sera abandonné. Cela permet à l'attaquant de savoir que le premier chiffre du secret est 5. L'attaquant continue alors de deviner le chiffre suivant.

En fin de compte, si votre site est plein d'attaques par réflexion XSS, l'utilisation de la valeur par défaut de 1réduira un peu la surface d'attaque. Cependant, si votre site est sécurisé et que vous n'en émettez pas X-XSS-Protection: 0, votre site sera vulnérable avec tout navigateur prenant en charge cette fonctionnalité. Si vous souhaitez une défense approfondie des navigateurs contre les vulnérabilités XSS encore inconnues sur votre site, utilisez un en- Content-Security-Policytête strict . Cela n'ouvre pas votre site aux vulnérabilités connues.

Actuellement, cette fonctionnalité est activée par défaut dans MSIE, Safari et Google Chrome. Auparavant, cela était activé dans Edge, mais Microsoft a déjà supprimé cette fonctionnalité erronée d'Edge . Mozilla Firefox n'a jamais implémenté cela.

Voir également:

https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html https://blog.innerht.ml/the-misunderstood-x-xss-protection/ http: / /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf https://www.slideshare.net/masatokinugawa/xxn-en https://bugs.chromium.org/p/chromium/issues/detail?id=396544 https: // bugs.chromium.org/p/chromium/issues/detail?id=498982