Quand dois-je utiliser l'en-tête HTTP "X-Content-Type-Options: nosniff"
J'ai effectué des tests d'intrusion avec OWASP ZAP et l'alerte suivante s'affiche pour toutes les demandes: X-Content-Type-Options Header Missing .
Je comprends l'en-tête et pourquoi il est recommandé. Cela s’explique très bien dans cette question de StackOverflow .
Cependant, j'ai trouvé diverses références qui indiquent qu'il n'est utilisé que pour les fichiers .js et .css, et qu'il pourrait en fait être une chose bad de définir l'en-tête pour d'autres types MIME:
- Note: nosniff ne s'applique qu'aux types "script" et "style". L'application de nosniff aux images s'est également révélée incompatible avec les sites Web existants.[1]
- Firefox a rencontré des problèmes lors de la prise en charge de nosniff pour les images (Chrome ne la prend pas en charge ici).[2]
- Remarque: les navigateurs modernes ne respectent l'en-tête des scripts et des feuilles de style. L'envoi de l'en-tête d'autres ressources (telles que des images) lorsqu'ils sont servis avec un type de support incorrect peut créer des problèmes dans les anciens navigateurs.[3]
Les références ci-dessus (et d'autres) indiquent qu'il est mauvais de définir simplement cet en-tête pour toutes les réponses. Malgré le fait de suivre des liens pertinents et d'effectuer des recherches sur Google, je ne pouvais trouver aucune raison derrière cet argument.
Quels sont les risques/problèmes associés à la définition de X-Content-Type-Options: nosniff et pourquoi devrait-il être évité pour les types MIME autres que text/css et text/javascript?
Ou, s'il n'y a pas de risques/problèmes, pourquoi Mozilla (et d'autres) suggère-t-il qu'il y en a?
La réponse de Sean Thorburn m'a été très utile et m'a indiqué du bon matériel, c'est pourquoi j'ai décerné la prime. Cependant, j'ai maintenant creusé un peu plus et je pense avoir la réponse dont j'ai besoin, ce qui s'avère être le contraire de la réponse donnée par Sean.
Je vais donc répondre à mes propres questions:
Les références ci-dessus (et d'autres) indiquent qu'il est mauvais de définir simplement cet en-tête pour toutes les réponses. Malgré le fait de suivre des liens pertinents et d'effectuer des recherches sur Google, je ne pouvais trouver aucune raison derrière cet argument.
Il y a une mauvaise interprétation ici - ce n'est pas ce qu'ils indiquent.
Les ressources que j'ai trouvées au cours de mes recherches faisaient référence au fait que l'en-tête n'était respecté que pour "types de script et de style", ce que j'ai interprété comme signifiant des fichiers servis sous la forme text/javascript ou text/css.
Cependant, ils se réfèrent réellement au contexte dans lequel le fichier est chargé, et non au type MIME dans lequel il est servi. Par exemple, les balises <script> ou <link rel="stylesheet">.
Compte tenu de cette interprétation, tout a plus de sens et la réponse devient claire:
Vous devez servir les fichiers tous avec un en-tête nosniff pour réduire le risque d'attaques par injection provenant du contenu de l'utilisateur.
Servir uniquement des fichiers CSS/JS avec cet en-tête est inutile, car ces types de fichiers seraient acceptables dans ce contexte et ne nécessiteraient aucun reniflage supplémentaire.
Cependant, pour les autres types de fichiers, en interdisant le sniffing, nous garantissons que seuls les fichiers dont le type MIME correspond au type attendu sont autorisés dans chaque contexte. Cela réduit le risque qu'un script malveillant soit masqué dans un fichier image (par exemple) de manière à contourner les contrôles de téléchargement et à permettre aux scripts tiers d'être hébergés à partir de votre domaine et intégrés à votre site.
Quels sont les risques/problèmes associés à la définition de X-Content-Type-Options: nosniff et pourquoi devrait-il être évité pour les types MIME autres que text/css et text/javascript?
Ou, s'il n'y a pas de risques/problèmes, pourquoi Mozilla (et d'autres) suggère-t-il qu'il y en a?
Il n'y a pas de problème.
Les problèmes décrits sont des problèmes de risque de rupture de la compatibilité avec les sites existants. Les recherches de Mozilla ont indiqué que l'application d'une option nosniff sur les balises <img> endommagerait de nombreux sites en raison d'une mauvaise configuration du serveur et que l'en-tête est donc ignoré dans les contextes d'image.
D'autres contextes (par exemple, les pages HTML, les téléchargements, les polices, etc.) n'utilisent pas le sniffing, ne présentent pas de risque associé ou ont des problèmes de compatibilité qui empêchent le sniffing d'être désactivé.
Par conséquent, ils ne suggèrent pas que vous devriez éviter l'utilisation de cet en-tête, du tout.
Cependant, les problèmes dont ils parlent donnent lieu à une note de bas de page importante pour cette discussion:
Si vous utilisez un en-tête nosniff, assurez-vous de fournir également le bon en-tête Content-Type!
Quelques références qui m'ont aidé à mieux comprendre ceci:
- La norme WhatWG Fetch qui définit cet en-tête.
- Une discussion et code commit relatif à cet en-tête pour l'outil de vérification du site webhint.io .
Je voudrais coller à js, css, texte/html, json et xml.
Google recommande l'utilisation de jetons CSRF indescriptibles fournis par les ressources protégées pour d'autres types de contenu. c’est-à-dire générer le jeton à l’aide d’une ressource js protégée par l’en-tête nosniff.
Vous pouvez l'ajouter à tout, mais ce serait fastidieux et, comme vous l'avez mentionné ci-dessus, vous risqueriez de rencontrer des problèmes de compatibilité et d'utilisation.
https://www.chromium.org/Home/chromium-security/corb-for-developers