Frage CSRF-Schutz mit CORS Origin-Header im Vergleich zum CSRF-Token


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

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

Beispiel:

  • Alice ist eingeloggt (mit einem Cookie) mit ihrem Browser zu "https://example.com"Ich nehme an, dass sie einen modernen Browser verwendet.
  • Alice besucht "https://evil.com", und der clientseitige Code von evil.com führt irgendeine Art von Anfrage an"https://example.com"(klassisches CSRF-Szenario).

Damit:

  • Wenn wir den Origin-Header (serverseitig) und kein CSRF-Token ü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 Anfrage aus dem clientseitigen Code von evil.com genauso gut 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 Ressourcennutzung), zumindest nicht, wenn wir der W3C-Spezifikation vertrauen, dass sie in allen modernen Browsern korrekt implementiert wird (können wir?)

Aber was ist mit anderen Arten von Anfragen - z.B. Formular einreichen? Lade ein Skript / img / ... tag? Oder eine andere Art, wie eine Seite eine Anfrage (legal) erstellen kann? Oder vielleicht ein bekannter JS-Hack?

Hinweis: Ich spreche nicht von

  • native Anwendungen,
  • manipulierte Browser,
  • Cross Site Scripting Bugs auf der Seite von example.com,
  • ...

76
2017-07-10 15:17


Ursprung


Antworten:


wissen, dass dies mit XHR nicht möglich sein sollte (siehe z. B. Sicherheit für Cross-Origin-Ressourcenfreigabe), zumindest nicht, wenn wir der W3C-Spezifikation vertrauen, dass sie in allen modernen Browsern korrekt implementiert wird (können wir?)

Am Ende des Tages müssen Sie dem Client-Browser "vertrauen", um 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 den Gleiche Ursprungsrichtlinie.

Bisher gab es bereits Browser - Schwachstellen wie in IE 5.5 / 6.0 Dort, wo Angreifer die Same-Origin-Richtlinie umgehen und Angriffe ausführen können, können Sie normalerweise erwarten, dass diese Patches sofort entdeckt werden. Da die meisten Browser automatisch aktualisiert werden, wird dieses Risiko größtenteils gemildert.

Aber was ist mit anderen Arten von Anfragen - z.B. Formular einreichen? Lade ein Skript / img / ... tag? Oder eine andere Art, wie eine Seite eine Anfrage (legal) erstellen kann? Oder vielleicht ein bekannter JS-Hack?

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

Hinweis: Ich spreche nicht von

  • native Anwendungen,

  • manipulierte Browser,

  • Cross Site Scripting Bugs auf der Seite von example.com,

Ich bin mir nicht sicher ob das unter manipulierte Browser fällt oder nicht, aber alte Versionen von Flash erlaubt, dass beliebige Header gesetzt werden, die es einem Angreifer ermöglichen würden, eine Anfrage mit einem Spoofed zu senden refererHeader von der Maschine des Opfers, um einen Angriff auszuführen.


31
2017-07-11 07:40



Webinhalte können den Origin-Header nicht manipulieren. Außerdem kann ein Ursprung unter der gleichen Ursprungsrichtlinie nicht einmal benutzerdefinierte Header an andere Ursprünge senden. [1]

Daher ist das Überprüfen des Origin-Headers genauso gut blockierende Angriffe wie mit einem CSRF-Token.

Die Hauptsorge, auf die man sich verlassen muss, ist, ob es alle legitimen Anfragen funktionieren lässt. Der Fragesteller weiß von diesem Problem und hat die Frage gestellt, die großen Fälle auszuschließen (keine alten Browser, nur HTTPS).

Browser-Anbieter folgen diesen Regeln, aber was ist mit Plugins? Sie mögen es nicht, aber die Frage ignoriert "manipulierte Browser". Was ist mit Bugs im Browser, die einen Angreifer den Origin-Header fälschen lassen? Es kann Fehler geben, die es dem CSRF-Token ermöglichen, auch über die Herkunft hinweg zu laufen. Daher würde es mehr Arbeit erfordern zu argumentieren, dass eines besser ist als das andere.


24
2017-07-11 00:38