Je suis en train de faire des tests d'intrusion sur mon hôte local avec OWASP ZAP, et il continue de signaler ce message:
L'en-tête Anti-MIME-Sniffing X-Content-Type-Options n'a pas été défini sur 'nosniff'
Cette vérification est spécifique à Internet Explorer 8 et Google Chrome. Assurez-vous que chaque page définit un en-tête Content-Type et les options X-CONTENT-TYPE-OPTIONS si l'en-tête Content-Type est inconnu.
Je n'ai aucune idée de ce que cela signifie et je n'ai rien trouvé en ligne. J'ai essayé d'ajouter:
<meta content="text/html; charset=UTF-8; X-Content-Type-Options=nosniff" http-equiv="Content-Type" />
mais je reçois toujours l'alerte.
Quelle est la bonne façon de régler le paramètre?
Cela empêche le navigateur de faire une recherche de type MIME. La plupart des navigateurs respectent désormais cet en-tête, notamment Chrome/Chromium, Edge, IE> = 8.0, Firefox> = 50 et Opera> = 13. Voir:
L'envoi du nouvel en-tête de réponse X-Content-Type-Options avec la valeur nosniff empêchera Internet Explorer d'empêcher MIME de rechercher une réponse en dehors du type de contenu déclaré.
MODIFIER:
Oh, et c'est un en-tête HTTP, pas une option de balise méta HTML.
Voir aussi: http://msdn.Microsoft.com/en-us/library/ie/gg622941 (v = vs.85) .aspx
Description
Définir l'en-tête de réponse HTTP X-Content-Type-Options
d'un serveur sur nosniff
demande aux navigateurs de désactiver en-tête le contenu ou la détection MIME qui est utilisé pour remplacer la réponse Content-Type
de deviner et de traiter les données. en utilisant un type de contenu implicite. Bien que cela puisse être pratique dans certains scénarios, cela peut également conduire à certaines des attaques énumérées ci-dessous. Si vous configurez votre serveur pour renvoyer l'en-tête de réponse X-Content-Type-Options
HTTP défini sur nosniff
, les navigateurs prenant en charge la détection MIME utiliseront le Content-Type
fourni par le serveur et n'interpréteront pas le contenu en tant que type de contenu différent.
Support du navigateur
L'en-tête de réponse HTTP X-Content-Type-Options
est pris en charge par Chrome, Firefox et Edge, ainsi que par d'autres navigateurs. La dernière prise en charge du navigateur est disponible dans le tableau de compatibilité du navigateur MDN (Mozilla Developer Network) pour les options X-Content-Type:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
Attaques prises en compte
MIME Confusion Attack active les attaques via les sites de contenu généré par les utilisateurs en permettant aux utilisateurs de charger du code malveillant qui sera ensuite exécuté par des navigateurs qui interpréteront les fichiers utilisant d'autres types de contenu, par exemple implicite application/javascript
vs explicite text/plain
. Cela peut entraîner une attaque "drive-by download" qui est un vecteur d’attaque courant pour le phishing. Les sites dont le contenu généré par l'utilisateur hôte doit utiliser cet en-tête pour protéger leurs utilisateurs. Ceci est mentionné par VeraCode et OWASP qui dit ce qui suit:
Cela réduit l'exposition aux attaques de téléchargement au volant et aux sites proposant du contenu téléchargé par l'utilisateur qui, grâce à une dénomination intelligente, pourrait être traité par MSIE comme un fichier HTML exécutable ou dynamique.
Hotlinking non autorisée peut également être activé par Content-Type
sniffing. En établissant un lien direct avec des sites disposant de ressources dans un seul but, par exemple En visionnant ces applications, les applications peuvent compter sur le sniffing de type de contenu et générer beaucoup de trafic sur des sites à des fins autres que celles prévues par leurs conditions de service, par exemple. GitHub affiche le code JavaScript pour l'affichage, mais pas pour l'exécution:
Certains utilisateurs non humains embêtants (notamment des ordinateurs) ont commencé à "lier" des actifs via la fonction de vue brute - en utilisant l'URL brute comme
src
pour une balise<script>
ou<img>
. Le problème est que ce ne sont pas des actifs statiques. La vue de fichier brut, comme toute autre vue dans une application Rails, doit être rendue avant d'être renvoyée à l'utilisateur. Cela se traduit rapidement par de lourdes pertes de performances. Dans le passé, nous avons été obligés de bloquer le contenu populaire diffusé de cette manière, car il imposait une charge excessive à nos serveurs.
# prevent mime based attacks
Header set X-Content-Type-Options "nosniff"
Cet en-tête empêche les attaques "mime". Cet en-tête empêche Internet Explorer de détecter une réponse du type de contenu déclaré par MIME, car l'en-tête indique au navigateur de ne pas remplacer le type de contenu de la réponse. Avec l'option nosniff, si le serveur dit que le contenu est text/html, le navigateur le restituera sous la forme text/html.
Pour les serveurs Microsoft IIS, vous pouvez activer cet en-tête via votre fichier web.config
:
<system.webServer>
<httpProtocol>
<customHeaders>
<remove name="X-Content-Type-Options"/>
<add name="X-Content-Type-Options" value="nosniff"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Et vous avez terminé.
L'en-tête HTTP de la réponse X-Content-Type-Options est un marqueur utilisé par le serveur pour indiquer que les types MIME annoncés dans les en-têtes Content-Type ne doivent pas être modifiés ni suivis. Cela permet de désactiver la détection de type MIME ou, en d'autres termes, de dire que les webmasters savaient ce qu'ils faisaient.
Syntaxe:
Options de type de contenu X: nosniff
Directives:
nosniff Bloque une requête si le type demandé est 1. "style" et que le type MIME n'est pas "text/css" ou 2. "script" et le type MIME n'est pas un type MIME JavaScript.
Remarque: nosniff s'applique uniquement aux types "script" et "style". L'application de nosniff aux images s'est également révélée incompatible avec les sites Web existants.
Spécification:
https://fetch.spec.whatwg.org/#x-content-type-options-header