CSRF-Schutz mit CORS Origin-Header vs. CSRF-Token

103

Bei dieser Frage geht es nur um den Schutz vor Cross Site Request Forgery-Angriffen.

Es geht speziell um: Ist der Schutz über den Origin-Header (CORS) so gut wie der Schutz über ein CSRF-Token?

Beispiel:

Alice ist mit ihrem Browser unter Verwendung eines Cookies unter " https://example.com " angemeldet . Ich gehe davon aus, dass sie einen modernen Browser benutzt.
Alice besucht " https://evil.com " und der clientseitige Code von evil.com führt eine Art Anfrage an " https://example.com " aus (klassisches CSRF-Szenario).

So:

Wenn wir den Origin-Header (serverseitig) und kein CSRF-Token nicht überprüfen, haben wir eine CSRF-Sicherheitslücke.
Wenn wir ein CSRF-Token überprüfen, sind wir sicher (aber es ist ein bisschen langweilig).
Wenn wir den Origin-Header überprüfen, sollte die Anforderung vom clientseitigen Code von evil.com genauso blockiert werden wie bei Verwendung eines CSRF-Tokens - außer wenn es irgendwie möglich ist, dass der Code von evil.com den Origin-Header setzt.

Ich weiß, dass dies mit XHR nicht möglich sein sollte (siehe z. B. Sicherheit für die gemeinsame Nutzung von Ressourcen zwischen verschiedenen Ursprüngen ), zumindest nicht, wenn wir darauf vertrauen, dass die W3C-Spezifikation in allen modernen Browsern korrekt implementiert wird (können wir?)

Aber was ist mit anderen Arten von Anfragen - z. B. Formular senden? Laden eines script / img / ... -Tags? Oder eine andere Möglichkeit, mit der eine Seite (legal) eine Anfrage erstellen kann? Oder vielleicht ein bekannter JS-Hack?

Hinweis: Ich spreche nicht über

native Anwendungen,
manipulierte Browser,
Cross-Site-Scripting-Fehler auf der Seite von example.com,
...

— Chris Lercher
quelle

Ich glaube, dass viele Proxys den Ursprungsheader entfernen.

— thefourtheye

Und für Formularübermittlungs- und img / script-Tags sollten wir uns auf CSPs verlassen, die sich bei den alten Browsern jedoch nicht sicher sind.

— thefourtheye

@thefourtheye: Da die Verbindung über TLS hergestellt wird, hat der Benutzer ein weitaus dringlicheres Problem als CSRF, wenn ein Proxy ihn in der Mitte man / sie managen kann.

— Perseiden

@thefourtheye, warum sollten sie sich ausziehen Origin? Das würde den CORS-Schutz negieren.

— Paul Draper

Ich mag diese Frage und ihre Antworten, weil es um etwas Bestimmtes geht, aber sie erinnern mich auch an den Unterschied zwischen CSRF und CORS. (Ich gebe zu, das sind nicht leicht zu verwirrende Konzepte ... Aber ich schaffe es immer noch, sie zu verwirren.)

— Die rote Erbse

Antworten:

wissen, dass dies mit XHR nicht möglich sein sollte (siehe z. B. Sicherheit für die gemeinsame Nutzung von Ressourcen zwischen verschiedenen Ursprüngen), zumindest nicht, wenn wir darauf vertrauen, dass die W3C-Spezifikation in allen modernen Browsern korrekt implementiert wird (können wir?)

Am Ende des Tages müssen Sie dem Client-Browser "vertrauen", um die Benutzerdaten sicher zu speichern und die Client-Seite der Sitzung zu schützen. Wenn Sie dem Client-Browser nicht vertrauen, sollten Sie das Web überhaupt nicht mehr für statische Inhalte verwenden. Selbst wenn Sie CSRF-Token verwenden, vertrauen Sie darauf, dass der Client-Browser die Same Origin-Richtlinie korrekt befolgt .

Zwar gab es bereits frühere Browser-Schwachstellen wie in IE 5.5 / 6.0, bei denen es Angreifern möglich war, die Richtlinie für denselben Ursprung zu umgehen und Angriffe auszuführen. Sie können jedoch davon ausgehen, dass diese sofort nach ihrer Entdeckung gepatcht werden und die meisten Browser automatisch aktualisiert werden wird dieses Risiko größtenteils gemindert.

Aber was ist mit anderen Arten von Anfragen - z. B. Formular senden? Laden eines script / img / ... -Tags? Oder eine andere Möglichkeit, mit der eine Seite (legal) eine Anfrage erstellen kann? Oder vielleicht ein bekannter JS-Hack?

Der OriginHeader wird normalerweise nur für domänenübergreifende XHR-Anforderungen gesendet. Bildanforderungen enthalten nicht den Header.

Hinweis: Ich spreche nicht über

native Anwendungen,

manipulierte Browser,

Cross-Site-Scripting-Fehler auf der Seite von example.com,

Ich bin nicht sicher, ob dies unter manipulierte Browser fällt oder nicht, aber in alten Flash-Versionen konnten beliebige Header festgelegt werden, mit denen ein Angreifer eine Anfrage mit einem gefälschten refererHeader vom Computer des Opfers senden konnte , um einen Angriff auszuführen.

— SilverlightFox
quelle

Das Flash-Beispiel ist gut - und möglicherweise weisen andere Plugins eine ähnliche Sicherheitsanfälligkeit auf. Ich kann Alice (leider) nur vor CSRF schützen, wenn sie einen modernen Browser usw. verwendet, das ist klar. Es ist jedoch nicht unangemessen, dass sie selbst als sicherheitsbewusste Benutzer Plugins von Drittanbietern installiert hat - insbesondere, wenn diese von großen (vertrauenswürdigen) Unternehmen stammen. Auch wenn sie sichere Plugins schreiben, bin ich nicht 100% überzeugt, wenn sie auch an CSRF denken! Wenn Browser-Sandboxen die Plugins nicht daran hindern, die SOP zu verletzen (oder?), Würde ich eher empfehlen, beim CSRF-Token zu bleiben.

— Chris Lercher

@ ChrisLercher: Ja, moderne Plugins scheinen etwas robuster zu sein. Es kann jedoch jederzeit eine neue Version veröffentlicht werden, mit der ein Angreifer sie so nutzen kann, dass der Browserschutz umgangen wird. Die beste Vorgehensweise (z. B. Token / Header) hängt von der Vertraulichkeit Ihrer Daten ab und davon, ob ein solches Risiko akzeptabel ist. Flash gehorcht zwar einer SOP, aber der Ursprung eines Flash-Plugins ist die Site, von der es geladen wurde (und nicht die aufrufende Site wie JavaScript). Es gibt eine crossdomain.xml, die die domänenübergreifende Kommunikation ermöglichen kann.

— SilverlightFox

Webinhalte können den Origin-Header nicht manipulieren. Darüber hinaus kann ein Ursprung unter derselben Ursprungsrichtlinie nicht einmal benutzerdefinierte Header an andere Ursprünge senden. [1]

Das Überprüfen des Origin-Headers ist daher genauso gut zum Blockieren von Angriffen wie das Verwenden eines CSRF-Tokens.

Das Hauptanliegen, sich darauf zu verlassen, ist, ob alle legitimen Anforderungen funktionieren. Der Fragesteller kennt dieses Problem und hat die Frage eingerichtet, um die Hauptfälle auszuschließen (keine alten Browser, nur HTTPS).

Browser-Anbieter befolgen diese Regeln, aber was ist mit Plugins? Sie mögen es nicht, aber die Frage ignoriert "manipulierte Browser". Was ist mit Fehlern im Browser, mit denen ein Angreifer den Origin-Header fälschen kann? Es kann Fehler geben, die es dem CSRF-Token ermöglichen, auch über die Ursprünge hinweg zu lecken. Daher wäre mehr Arbeit erforderlich, um zu argumentieren, dass einer besser ist als der andere.

— Gast
quelle

Ich habe gerade Firefox 47 getestet und es wird kein Ursprungsheader für einen originübergreifenden Formularbeitrag gesendet (eine übliche Methode, um REST-Services anzugreifen, die CORS für XHR nicht aktivieren), daher glaube ich nicht, dass eine Ursprungsheaderprüfung durchgeführt wird wäre effektiv, wenn der Benutzer Firefox verwendet.

— Andy

Als Referenz wird das Problem, dass Firefox keinen "Origin" -Header sendet, unter Bugzilla verfolgt: bugzilla.mozilla.org/show_bug.cgi?id=446344 Sie könnten in diesem Fall auf die Überprüfung des "Referer" -Headers zurückgreifen, aber meiner Erfahrung nach einige Firefox-Benutzer blockieren den "Referer" -Header aus Datenschutzgründen (obwohl es meiner Meinung nach ausreichen würde, den Pfad und die Abfrage zu entfernen).

— Steffen