X-Content-Type-Options empêche-t-il vraiment les attaques de reniflement de contenu?
Dans Tangled Web, Michal Zalewski dit:
Évitez d'utiliser Content-Type: application/octet-stream et utilisez plutôt application/binary, en particulier pour les types de documents inconnus. Ne renvoyez pas Content-Type: text/plain.
Par exemple, toute plate-forme d'hébergement de code doit faire preuve de prudence lors du retour d'exécutables ou d'archives source en tant que flux d'application/octet, car il existe un risque qu'elles soient mal interprétées en HTML et affichées en ligne.
La logique text/plain implémentée par la suite dans Internet Explorer et Safari afin de détecter le HTML dans un tel cas est vraiment une mauvaise nouvelle: elle prive les développeurs Web de la possibilité d'utiliser en toute sécurité ce type MIME pour générer des documents en clair spécifiques à l'utilisateur et n'offre aucune alternative . Cela a entraîné un nombre important de vulnérabilités des applications Web, mais à ce jour, les développeurs d'Internet Explorer semblent n'avoir aucun regret et n'ont pas changé le comportement par défaut de leur code.
Le site utilise X-Content-Type-Options:nosniff. L'auteur dit ce qui suit à propos de cet en-tête:
L'utilisation de cet en-tête [X-Content-Type-Options] est fortement recommandée; malheureusement, son support n'a [...] qu'un support limité dans les autres navigateurs. En d'autres termes, il ne peut pas être considéré comme l'unique défense contre le reniflage de contenu.
Quel contenu renifle les attaques X-Content-Type-Options:nosniff n'empêche pas? Quoi Content-Type doit être retourné à l'utilisateur au lieu de text/plain?
Contexte. X-Content-Type-Options: est un en-tête conçu pour défendre contre attaques de reniflement de contenu MIME . Les attaques de reniflement de contenu MIME sont un risque lorsque vous autorisez les utilisateurs à télécharger du contenu (par exemple, des images, des documents, d'autres fichiers) sur votre site Web, où ils peuvent être téléchargés par d'autres utilisateurs.
Comme le dit @Rook, cela n'a rien à voir avec l'écoute/la capture du trafic réseau.
Quelles attaques n'empêche-t-il pas? Parce que X-Content-Type-Options: n'est pris en charge que par certains navigateurs, il ne protège pas les attaques contre les utilisateurs qui utilisent d'autres navigateurs. En particulier, il est supposé sur IE, Chrome et Firefox 5 . Voir aussi Quels sont les risques pour la sécurité de laisser les utilisateurs télécharger du contenu sur mon site? pour certaines autres attaques, cela n'empêche pas, par exemple, le téléchargement de logiciels malveillants ou de contenu indésirable, le téléchargement de contenu exploitant une vulnérabilité dans le navigateur de l'utilisateur, etc.
Quel type de contenu doit être renvoyé? Vous devez renvoyer le type de contenu approprié pour ce fichier. Vous ne devez pas autoriser les utilisateurs à télécharger du contenu non fiable avec des types de contenu dangereux. Pour plus de détails, veuillez voir les réponses aux questions suivantes:
Est-il sûr de stocker et de rejouer les types MIME fournis par l'utilisateur?
Pourquoi devrais-je restreindre le type de contenu des fichiers à télécharger sur mon site?
Comment puis-je être protégé contre les vulnérabilités des images?
Ce sujet a été longuement discuté et documenté ailleurs sur ce site, donc je ne vais pas essayer de répéter tous les conseils utiles qui s'y trouvent.
Mise à jour: je viens d'apprendre que la définition de Content-Type et X-Content-Type-Options les en-têtes appropriés ne suffisent pas pour la sécurité. Apparemment, Flash ignore l'en-tête Content-Type , ce qui pourrait permettre de charger un SWF malveillant, qui peut alors faire tout ce que vous feriez avec un XSS. (Soupir, stupide Flash.) Malheureusement, aucune liste blanche des types de contenu de fichier ne peut arrêter cette attaque. Par conséquent, il semble que la seule solution sûre consiste à héberger le contenu téléchargé par l'utilisateur sur un domaine distinct.
Voici une réponse de Michal Zalewski reçue par email:
La réponse courte est que cela fonctionne dans MSIE, et seulement dans certains cas spécifiques. Il ne vous protégera pas contre les reniflements (encore moins zélés) dans la plupart des autres navigateurs; mais plus important encore, ne découragera pas les plugins de faire des choses telles que le risque crossdomain.xml décrit ci-dessus; et n'empêchera pas nécessairement les charges de sous-ressources avec des types MIME incompatibles (c'est-à-dire le chargement d'une image en tant qu'application/x-shockwave-flash via <embed>).
Quel sniffing attaque X-Content-Type-Options: nosniff n'empêche pas?
Renifler par des outils qui ne connaissent pas X-Content-Type-Options: certains navigateurs et plugins qui peuvent récupérer des ressources réseau. (Par exemple, historiquement Java GIFAR, Flash loadPolicyFile ...)
Quel type de contenu doit être renvoyé à l'utilisateur au lieu de texte/simple?
Il n'y a pas de bonne réponse à cela, donc si vous avez besoin d'héberger des fichiers texte non approuvés, vous devriez prendre les mesures d'atténuation habituelles de les héberger sur un nom d'hôte distinct (et idéalement une adresse IP).
Alternative: codage HTML, ajoutez un <pre> et servir de text/html.