TL; DR: Tous les sites Web (/ applications) bien écrits doivent émettre un en-tête X-XSS-Protection: 0
et oublier cette fonctionnalité. Si vous voulez avoir une sécurité supplémentaire que de meilleurs agents utilisateurs peuvent fournir, utilisez un en- Content-Security-Policy
tê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-Protection
le navigateur se comportera comme si l'en-tête X-XSS-Protection: 1
avait é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: 1
permet à 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=block
permet à 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="3
et si la page n'est PAS bloquée, le 3
premier chiffre était incorrect. L'attaquant essaie à nouveau, cette fois leak=var%20csrf_secret="5
et 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 1
ré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-Policy
tê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