wake-up-neo.net

Wann sollte ich den HTTP-Header "X-Content-Type-Options: nosniff" verwenden?

Ich habe einige Penetrationstests mit OWASP ZAP ausgeführt, und es wird die folgende Warnung für alle Anforderungen ausgelöst: X-Content-Type-Options Header Missing .

Ich verstehe die Kopfzeile und warum es empfohlen wird. Es wird sehr gut in dieser StackOverflow-Frage erklärt.

Ich habe jedoch verschiedene Verweise gefunden, die darauf hindeuten, dass es nur für .js- und .css-Dateien verwendet wird, und dass es tatsächlich eine bad -Datei sein kann, um den Header für andere MIME-Typen festzulegen:

  • Hinweis: nosniff gilt nur für die Typen "Skript" und "Stil". Auch die Anwendung von Nosniff auf Bilder erwies sich als mit bestehenden Websites nicht kompatibel.[1]
  • Firefox hat Probleme mit der Unterstützung von Nosniff für Bilder (Chrome unterstützt es dort nicht).[2]
  • Hinweis: Moderne Browser respektieren nur die Kopfzeile für Skripts und Stylesheets. Wenn Sie die Kopfzeile für andere Ressourcen (z. B. Bilder) senden, wenn sie mit dem falschen Medientyp geliefert werden, kann dies zu Problemen bei älteren Browsern führen.[3]

Die obigen Verweise (und andere) zeigen an, dass es nicht einfach ist, diesen Header für alle Antworten festzulegen. Trotz der Verfolgung relevanter Links und der Suche bei Google konnte ich keinen Grund für dieses Argument finden.

Welche Risiken/Probleme sind mit der Einstellung von X-Content-Type-Options: nosniff verbunden, und warum sollte dies für andere MIME-Typen als text/css und text/javascript vermieden werden?

Oder, wenn es keine Risiken/Probleme gibt, warum deuten Mozilla (und andere) darauf hin?

12
HappyDog

Die Antwort von Sean Thorburn war sehr hilfreich und wies mich auf gutes Material hin, weshalb ich die Prämie vergeben habe. Ich habe jetzt jedoch noch etwas weiter gegraben und denke, ich habe die Antwort, die ich brauche, was sich als das Gegenteil von Sean herausstellt.

Ich werde daher meine eigenen Fragen beantworten:

Die obigen Verweise (und andere) zeigen an, dass es nicht einfach ist, diesen Header für alle Antworten festzulegen. Trotz der Verfolgung relevanter Links und der Suche bei Google konnte ich keinen Grund für dieses Argument finden.

Es gibt hier eine Fehlinterpretation - das ist nicht das, was sie andeuten.

Die Ressourcen, die ich während meiner Recherche gefunden habe, bezogen sich auf die Kopfzeile, die nur für "Skript- und Stiltypen" geachtet wurde, was ich als Dateien interpretierte, die als text/javascript oder text/css dienen.

Sie beziehen sich jedoch tatsächlich auf den Kontext, in den die Datei geladen wird, nicht auf den MIME-Typ, unter dem sie bereitgestellt wird. Zum Beispiel <script>- oder <link rel="stylesheet">-Tags.

Bei dieser Interpretation macht alles viel mehr Sinn und die Antwort wird klar:

Sie müssen all -Dateien mit einem nosniff-Header bereitstellen, um das Risiko von Injektionsangriffen durch Benutzerinhalte zu reduzieren.

Die Verwendung von CSS/JS-Dateien mit diesem Header ist sinnlos, da diese Dateitypen in diesem Zusammenhang akzeptabel sind und kein zusätzliches Schnüffeln erfordern.

Bei anderen Dateitypen stellen wir jedoch durch das Verbot des Sniffing sicher, dass nur Dateien, deren MIME-Typ mit dem erwarteten Typ übereinstimmt, in jedem Kontext zulässig sind. Dadurch wird das Risiko gemindert, dass ein bösartiges Skript (z. B.) in einer Bilddatei so versteckt wird, dass Upload-Prüfungen umgangen werden und Drittanbieter-Skripts von Ihrer Domäne gehostet und in Ihre Website eingebettet werden können.

Welche Risiken/Probleme sind mit dem Setzen von X-Content-Type-Optionen verbunden: nosniff und warum sollte dies für andere MIME-Typen als Text/CSS und Text/Javascript vermieden werden?

Oder, wenn es keine Risiken/Probleme gibt, warum deuten Mozilla (und andere) darauf hin?

Da sind keine Probleme.

Bei den beschriebenen Problemen handelt es sich um Probleme hinsichtlich der Gefahr, dass die Kompatibilität mit vorhandenen Websites unterbrochen wird. Mozillas Recherche ergab, dass das Erzwingen einer nosniff-Option für <img>-Tags aufgrund von Fehlkonfigurationen von Servern eine Vielzahl von Websites beschädigen würde. Daher wird der Header in Bildkontexten ignoriert.

Andere Kontexte (z. B. HTML-Seiten, Downloads, Schriftarten usw.) verwenden entweder kein Sniffing, sind nicht mit einem Risiko verbunden oder haben Kompatibilitätsprobleme, die das Deaktivieren von Sniffing verhindern.

Daher schlagen sie nicht vor, dass Sie die Verwendung dieses Headers überhaupt vermeiden sollten.

Die Themen, über die sie sprechen, führen jedoch zu einer wichtigen Fußnote zu dieser Diskussion:

Wenn Sie einen nosniff-Header verwenden, stellen Sie sicher, dass Sie auch den korrekten Content-Type-Header bereitstellen!


Einige Hinweise, die mir geholfen haben, dies etwas umfassender zu verstehen:

  1. Der WhatWG-Abrufstandard, der diesen Header definiert.
  2. Ein Diskussions und Code-Commit , der sich auf diesen Header bezieht, für das webhint.io Site-Überprüfungswerkzeug.
0
HappyDog

Ich würde mich an js, css, text/html, json und xml halten.

Google empfiehlt die Verwendung nicht erlernbarer CSRF-Token, die von den geschützten Ressourcen für andere Inhaltstypen bereitgestellt werden. Erzeugen Sie das Token mit einer js-Ressource, die durch den Nosniff-Header geschützt wird.

Sie können es zu allem hinzufügen, aber das wäre nur langweilig und wie Sie oben erwähnt haben, könnten Sie auf Kompatibilitäts- und Benutzerprobleme stoßen.

https://www.chromium.org/Home/chromium-security/corb-for-entwickler

0
Sean Thorburn