it-swarm-eu.dev

Verhindert X-Content-Type-Options wirklich Content-Sniffing-Angriffe?

In Tangled Web sagt Michal Zalewski:

Verwenden Sie nicht Content-Type: application/octet-stream und verwenden Sie stattdessen application/binary, insbesondere für unbekannte Dokumenttypen. Geben Sie keinen Inhaltstyp zurück: text/plain.

Beispielsweise muss jede Code-Hosting-Plattform bei der Rückgabe von ausführbaren Dateien oder Quellarchiven als Anwendungs-/Oktett-Stream Vorsicht walten lassen, da das Risiko besteht, dass sie als HTML falsch interpretiert und inline angezeigt werden.

Die später in Internet Explorer und Safari implementierte Text-/Klartextlogik, um HTML in einem solchen Fall zu erkennen, ist eine wirklich schlechte Nachricht: Sie raubt Webentwicklern die Möglichkeit, diesen MIME-Typ sicher zum Generieren benutzerspezifischer Klartextdokumente zu verwenden, und bietet keine Alternativen . Dies hat zu einer erheblichen Anzahl von Sicherheitslücken in Webanwendungen geführt, aber bis heute scheinen Internet Explorer-Entwickler kein Bedauern zu haben und haben das Standardverhalten ihres Codes nicht geändert.

Site verwendet X-Content-Type-Options:nosniff. Der Autor sagt Folgendes zu diesem Header:

Die Verwendung dieses Headers [X-Content-Type-Options] wird dringend empfohlen. Leider hat die Unterstützung dafür [...] in anderen Browsern nur eine begrenzte Unterstützung. Mit anderen Worten, es kann nicht als alleinige Verteidigung gegen das Schnüffeln von Inhalten herangezogen werden.

Welche Content-Sniffing-Angriffe X-Content-Type-Options:nosniff Verhindern nicht? Was Content-Type Sollte anstelle von text/plain An den Benutzer zurückgegeben werden?

19
Andrei Botalov

Hintergrund. X-Content-Type-Options: ist ein Header, der entwickelt wurde, um zu verteidigen gegen MIME-Content-Sniffing-Angriffe . MIME-Content-Sniffing-Angriffe sind ein Risiko, wenn Sie Benutzern erlauben, Inhalte (z. B. Bilder, Dokumente, andere Dateien) auf Ihre Website hochzuladen, wo sie von anderen Benutzern heruntergeladen werden können.

Wie @Rook sagt, hat dies nichts mit dem Abhören/Erfassen des Netzwerkverkehrs zu tun.

Welche Angriffe verhindert es nicht? Weil X-Content-Type-Options: wird nur in einigen Browsern unterstützt und schützt keine Angriffe gegen Benutzer, die andere Browser verwenden. Insbesondere wird es auf IE, Chrome und Firefox 5 angenommen. Siehe auch Was sind die Sicherheitsrisiken, wenn Benutzer Inhalte auf meine Website hochladen? für einige andere Angriffe, die nicht verhindert werden, z. B. das Hochladen von Malware oder unappetitlichen Inhalten, das Hochladen von Inhalten, die eine Sicherheitsanfälligkeit ausnutzen im Browser des Benutzers usw.

Welcher Inhaltstyp sollte zurückgegeben werden? Sie sollten den entsprechenden Inhaltstyp für diese Datei zurückgeben. Sie sollten Benutzern nicht erlauben, nicht vertrauenswürdige Inhalte mit gefährlichen Inhaltstypen hochzuladen. Weitere Informationen finden Sie in den Antworten auf die folgenden Fragen:

  1. Ist es sicher, von Benutzern hochgeladene Dateien nur unter MIME-Inhaltstypen mit weißer Liste bereitzustellen?

  2. Ist es sicher, vom Benutzer bereitgestellte MIME-Typen zu speichern und wiederzugeben?

  3. MIME-Schnüffelschutz

  4. Warum sollte ich den Inhaltstyp von Dateien, die auf meine Site hochgeladen werden sollen, einschränken?

  5. Was sind die Sicherheitsrisiken, wenn die Benutzer Inhalte auf meine Website hochladen?

  6. Wie kann ich vor Bildschwachstellen geschützt werden?

  7. Verwenden der Kombination aus Dateierweiterung und MIME-Typ (wie von der Datei -i -b ausgegeben), um unsichere Dateien zu ermitteln?

Dieses Thema wurde an anderer Stelle auf dieser Website ausführlich diskutiert und dokumentiert, daher werde ich nicht versuchen, alle dort enthaltenen nützlichen Ratschläge zu wiederholen.


Update: Ich habe gerade gelernt, dass das Setzen von Content-Type und X-Content-Type-Options Header sind aus Sicherheitsgründen nicht ausreichend. Anscheinend Flash ignoriert den Content-Type-Header , wodurch möglicherweise eine schädliche SWF geladen wird, die dann alles kann, was Sie mit einem XSS tun würden. (Seufz, dummes Flash.) Leider kann keine Whitelist von Dateiinhaltstypen diesen Angriff stoppen. Folglich scheint die einzig sichere Lösung darin zu bestehen, den vom Benutzer hochgeladenen Inhalt in einer separaten Domäne zu hosten.

23
D.W.

Hier ist eine Antwort von Michal Zalewski per E-Mail erhalten:

Die kurze Antwort lautet, dass es in MSIE funktioniert und nur in bestimmten Fällen. Es schützt Sie nicht vor (viel weniger eifrigem) Schnüffeln in den meisten anderen Browsern. Noch wichtiger ist jedoch, dass Plugins nicht davon abgehalten werden, Dinge wie das oben beschriebene Risiko crossdomain.xml auszuführen. und verhindert nicht unbedingt das Laden von Unterressourcen mit nicht übereinstimmenden MIME-Typen (d. h. Laden eines Bildes als Anwendung/x-Schockwellenblitz über <embed>).

6
Andrei Botalov

Welche Sniffing-Angriffe X-Content-Type-Options: Nosniff verhindert nicht?

Sniffing mit Tools, die nichts über X-Content-Type-Options Wissen: Einige Browser und Plugins, die Netzwerkressourcen abrufen können. (Zum Beispiel historisch Java GIFAR, Flash loadPolicyFile ...)

Welcher Inhaltstyp sollte anstelle von Text/Nur an den Benutzer zurückgegeben werden?

Darauf gibt es keine gute Antwort. Wenn Sie also nicht vertrauenswürdige Textdateien hosten müssen, sollten Sie die übliche Abschwächung anwenden, indem Sie sie auf einem separaten Hostnamen (und idealerweise einer IP-Adresse) hosten.

Alternative: HTML-Codierung, fügen Sie einen <pre> Hinzu und dienen Sie als text/html.

3
bobince