Frage:
Hilft CORS trotzdem gegen Cross-Site Forgery?
Dan Dinu
2015-08-26 16:30:40 UTC
view on stackexchange narkive permalink

Ich habe in den letzten Tagen über CORS gelesen und an vielen Stellen wird es erwähnt, da es sich um eine "Sicherheits" -Funktion handelt, die der Welt bei domänenübergreifenden Fälschungen hilft.

Ich sehe immer noch nicht den Nutzen und die Gründe für CORS. Ok, Browser führen eine Preflight-Anfrage durch / der Server überprüft den Ursprung. Ein Angreifer kann jedoch ganz einfach eine HttpRequest von oben nach unten mit beliebigen Headern (Ursprung) erstellen und erhält Zugriff auf die Ressource.

Wie hilft CORS und was bringt es?

Sechs antworten:
#1
+54
SilverlightFox
2015-08-27 22:00:16 UTC
view on stackexchange narkive permalink

Ich beginne meine Antwort damit, dass viele Leute die Same Origin Policy und das, was CORS auf den Tisch bringt, falsch verstehen.

Einige von ihnen Die bereits hier abgegebenen Antworten besagen, dass die Richtlinie für denselben Ursprung standortübergreifende Anfragen und damit CSRF verhindert. Das ist nicht der Fall. Die SOP verhindert lediglich, dass die Antwort von einer anderen Domäne (auch als Ursprung bezeichnet) gelesen wird. Dies spielt keine Rolle, ob ein CSRF-Angriff erfolgreich ist oder nicht.

Das einzige Mal, wenn die SOP mit CSRF ins Spiel kommt, besteht darin, zu verhindern, dass Token von einer anderen Domäne gelesen werden.

Alles, was CORS tut, ist die SOP zu entspannen, wenn sie aktiv ist. Es erhöht nicht die Sicherheit, sondern lässt lediglich einige Ausnahmen zu. Einige Browser mit teilweiser CORS-Unterstützung erlauben standortübergreifende XHR-Anforderungen (z. B. IE 10 und früher), erlauben jedoch nicht das Anhängen von benutzerdefinierten Headern. In von CORS unterstützten Browsern kann der Header Origin nicht festgelegt werden, sodass ein Angreifer dies nicht fälschen kann.

Ich erwähnte, dass Domains unterschiedlichen Ursprungs sind. Die Ursprünge können sich auch nach Port und Protokoll unterscheiden, wenn es um AJAX-Anforderungen geht (nicht so sehr um Cookies).

Schließlich hat all das nichts mit gefälschten Anforderungen zu tun, die direkt von einem Angreifer stammen, z. B. mit locken. Denken Sie daran, dass der Angreifer den Browser des Opfers für seinen Angriff verwenden muss. Sie benötigen den Browser, um seine Cookies automatisch zu senden. Dies kann nicht durch eine direkte Curl-Anforderung erreicht werden, da dies nur den Angreifer in dieser Art von Angriffsszenario authentifizieren würde (die Kategorie, die als "clientseitige Angriffe" bezeichnet wird).

Der Vorteil von CORS besteht darin, dass dies der Fall ist Ermöglicht Ihrer Domain, Lesevorgänge von einer anderen vertrauenswürdigen Domain zuzulassen. Wenn Sie also http://data.example.org haben, können Sie Antwortheader festlegen, damit http://site.example.com AJAX-Anforderungen stellen und Daten abrufen kann von Ihrer API.

Dies ist die richtigste Antwort. Außerdem scheint niemand zu erwähnen, dass Sie in den meisten modernen CORS-Bibliotheken eine Whitelist erstellen können, welche Origins Sie zulassen möchten. Alles, was ich lese, scheint davon auszugehen, dass Sie nur alle Ursprünge zulassen sollten, was für die meisten Menschen normalerweise nicht der Fall ist.
Alles, was die SOP tut, ist NICHT zu verhindern, dass die Antwort von einer anderen Domain gelesen wird!Es erlaubt Browsern nicht einmal, eine vorab geflogene Anfrage an eine andere Domain zu senden.
@Daniel Welche Arten von Anforderungen werden von der SOP blockiert?
Ich habe einige Gedanken zu POST-Anfragen ohne benutzerdefinierte Header und mit einem Standard-Header-Wert für "Content-Type" (z. B. "application / x-www-form-urlencoded"). Bei diesen Anforderungen sendet der Browser (zumindest Chrome), der der "CORS" -Richtlinie folgt, KEINE Preflight-OPTIONS-Anforderung und sendet die "POST" -Anforderung sofort. Dies bedeutet, dass CSRF erfolgreich ist, wenn ein Benutzer die Site eines Angreifers besucht und diese böswillige Site diese POST-Anfrage über AJAX mit den Optionen "withCredentials" auf "true" sendet (also Sitzungscookies sendet). Habe ich recht?
@ton Ja, Sie sind für alle (?) Modernen Browser korrekt.Siehe meinen Beitrag hier: https://markitzeroday.com/x-requested-with/cors/2017/06/29/csrf-mitigation-for-ajax-requests.html Es enthält einige Beispiele und zeigt die Schadensbegrenzung durch Überprüfen auf abenutzerdefinierter Header.
Ich weiß, dass diese Antwort jetzt einige Jahre alt ist, aber es gibt Browsererweiterungen, die den Ursprungsheader fälschen können.Ich habe es nie getestet, aber man könnte meinen, dass ein Angreifer die Browsererweiterung des Opfers nutzen kann.Möglicherweise hat der Benutzer den Origin-Header-Satz verlassen und vergessen, den Wert zu entfernen oder die Erweiterung zu deaktivieren.Oder der Angreifer kann möglicherweise direkt einen Wert für die Erweiterung eingeben.Ich denke hier nur laut nach.
#2
+13
BgrWorker
2015-08-26 18:26:18 UTC
view on stackexchange narkive permalink

Sie vermischen die Dinge. CORS soll Ihre Anwendung nicht vor gestalteten http-Anforderungen schützen. Es soll Sie vor einer bestimmten Art von Angriffen schützen, die die Cookies oder Zugriffstoken des Benutzers "stehlen", indem überprüft wird, welche Websites auf Ihre Ressource zugreifen können .

Es wird hauptsächlich verwendet, um Ihren Server / Ihre Anwendung vor der Fälschung von standortübergreifenden Anforderungen zu schützen, bei der eine böswillige Website im Auftrag des Benutzers eine Anforderung ausführt, möglicherweise mit böswilligen Absichten (Änderung der Anmeldeinformationen, Geldtransfer ...). ), wobei die Tatsache ausgenutzt wird, dass der Browser alle noch aktiven und für Ihre Site gültigen Anmelde- und Sitzungscookies sendet.

Wenn CORS korrekt konfiguriert ist, wird die Ajax-Anforderung der Site des Angreifers abgelehnt, da standardmäßig nur Anforderungen derselben Site akzeptiert werden.

Dies Bedeutet NICHT, dass Sie Ihre Eingaben nicht bereinigen sollten und schützt Sie nur vor einer bestimmten Art von CSFR-Angriffen. Sollte der Angreifer die Cookies / Zugriffstoken Ihres Benutzers erhalten, wird ihm trotzdem Zugriff gewährt. Aus diesem Grund sollten die meisten Authentifizierungsprozesse SSL als zusätzliche Schutzschicht verwenden.

PS: Dies Es wird davon ausgegangen, dass der von Ihrem Benutzer verwendete Browser auf dem neuesten Stand ist, keine Fehler aufweist und die gleiche Ursprungsrichtlinie korrekt befolgt.

BEARBEITEN: Bei Preflight-Anforderungen ist dies eine zusätzliche Maßnahme, um sicherzustellen, dass die Site gewährt wird Zugriff und werden nicht für alle Cross-Origin-Anforderungen durchgeführt

Diese Antwort hat die Dinge für mich wirklich geklärt. Jetzt verstehe ich, dass es die Anfrage-Ressource eines Drittanbieters ist, die die Anfrage zulassen muss, nicht der Server, der die Anfrage-Seite generiert hat.
@Sebastiano, CORS soll Sie nicht vor CSRF schützen. (CSRF wäre unabhängig von CORS immer noch über " CORS dient nicht dem Schutz, sondern der gemeinsamen Nutzung von Ressourcen.Bis zu einem gewissen Grad ist es genau das Gegenteil von CRSF.Ersteres ermöglicht Ursprungsübergreifende Anfragen, Letzteres verbietet (oder verhindert böswillige) Ursprungsübergreifende Anfragen.Auch die CORS-Anforderung wird im Allgemeinen nicht vom Server abgelehnt, sondern die Antwort vom Server wird vom Client, d. H. Dem Browser, "abgelehnt".Daher verhindert SOP nicht unbedingt CRSF, wie in der Antwort von @SilverlightFox's klargestellt.
#3
+3
Grub
2019-08-08 11:38:36 UTC
view on stackexchange narkive permalink

Ist es sinnvoll, all dies wie folgt zusammenzufassen:

  • SOP (Single Origin Policy) stellt sicher, dass CSRF-Angriffe nicht von in einem modernen, aktuellen Browser, da der Angreifer von einer anderen Domain aus POSTEN müsste.

  • CSRF ( Cross-Site Request Forgery) Token stellen sicher, dass gefährliche POST-Anforderungen nicht außerhalb des Browsers gestellt werden können (wo SOP nicht gilt, z. B. mithilfe von curl ), weil sie außerhalb einer gemeinsam genutzten Browser-Erfahrung keinen Zugriff auf Authentifizierungsdaten in Benutzer-Cookies haben.

  • CORS (Cross-Origin Resource Sharing) können werden verwendet, um die Einschränkungen der SOP für Browser zu lockern, jedoch nur, wenn der Ressourcenserver dies über CORS-Header zulässt. Daher kann es bei falscher Verwendung die Sicherheit tatsächlich schwächen.

#4
+1
user45139
2015-08-26 17:44:46 UTC
view on stackexchange narkive permalink

Ich habe in den letzten Tagen über CORS gelesen und an vielen Stellen wurde es erwähnt, da es eine "Sicherheits" -Funktion ist, die der Welt bei domänenübergreifenden Fälschungen hilft.

Sie haben entweder die Vorteile von CORS falsch verstanden oder möglicherweise in einigen Amateur -Blogs von Entwicklern gelesen, die sich mehr Gedanken darüber machen, wie es funktioniert als wie man es sicher macht (wenn Sie verstehen, was ich meine), weil CORS Ihre Webanwendung eher für solche Angriffe anfällig macht ( CSRF), wenn Sie originenübergreifende Anfragen öffnen vom Ursprung des Angreifers durch Verwendung von CORS mit dem folgenden Header: Access-Control-Allow-Origin: *

Wie hilft CORS und was ist der Vorteil davon?

CORS wurde entwickelt, um die Einschränkungen der SOP für vertrauenswürdige Anfragen nur zu vereinfachen. Aber die Probleme beginnen genau mit diesem Vertrauen . Ein Angreifer kann durch die Ursprünge Schaden anrichten, indem er beispielsweise böswillige Anforderungen über GET- und POST-Methoden fälscht, und Sie können sogar DNS-Neubindung

aussetzen
Welche Bedeutung hat die DNS-Neubindung im Kontext von CORS? Wenn ein DNS-Rebinding-Angriff erfolgreich ausgeführt wird, werden bereits Informationen verloren (unabhängig von den CORS-Headern). Wenn CORS falsch eingerichtet ist, kann bereits ohne DNS-Neubindung auf Informationen zugegriffen werden. In beiden Fällen verstehe ich nicht, warum die DNS-Neubindung in Ihrer Antwort erwähnt werden sollte. Habe ich etwas übersehen?
@RobW Wenn Sie CORS * so wie es ist * implementieren, meine ich, ohne die Notwendigkeit zu überprüfen, den Ursprung zu überprüfen, und Host-Header denselben Hostnamen haben, sind Sie anfällig für DNS-Neubindung.
Wenn Sie immer mit "Access-Control-Allow-Origin: *" antworten, ist die Ressource bereits öffentlich, sodass die DNS-Neubindung keinen Wert hinzufügt. Können Sie ein Beispiel (Anfragen und Antworten) nennen, bei dem DNS-Neubindung und CORS zusammen zu einem Sicherheitsproblem führen, für das beide Komponenten des Angriffs erforderlich sind?
@RobW Was überprüft ein Ressourcenautor bei der Implementierung von CORS? Instinktiv ist er wahrscheinlich (und wir sprechen von Entwicklern) nur der Ursprungsheader. Die Ursprungsheader werden angezeigt, woher die Ursprungsübergreifungsanforderung stammt. Ein Entwickler vergisst, den Hostheader zu überprüfen. Es liegt das Problem vor. Wenn Sie einen Proof of Concept wünschen, können Sie dies in einem anderen Beitrag erfragen (um meine Antwort nicht vom Thema abzulenken: Ich erwähnte, dass er als zusätzliche Information zum OP nur nach CSRF fragte).
Übrigens klingt die DNS-Neubindung nach einer schwerwiegenden Sicherheitslücke, die für CORS von hoher Relevanz und für CSRF in gewisser Weise relevant ist. Um einen Angriff auszuführen, der Ursprungs-Whitelists missbraucht, muss der Angreifer einen dieser Ursprünge kontrollieren. DNS-Neubindung wird dort nicht helfen. Wenn der Angreifer den Ursprung kontrolliert, kann DNS-Rebinding nur verwendet werden, um Cookies zu stehlen, die nach einer CORS-fähigen Anforderung mit Anmeldeinformationen über einen vom Angreifer kontrollierten Hostnamen gesetzt wurden. Dieser Angriff klingt etwas weit hergeholt. Hattest du noch etwas im Sinn?
#5
  0
racec0ndition
2015-08-26 17:42:17 UTC
view on stackexchange narkive permalink

In diesem Teil führen

Browser eine Preflight-Anfrage durch / der Server überprüft den Ursprung. Ein Angreifer kann jedoch problemlos eine HttpRequest von oben nach unten mit den gewünschten Headern (Ursprung) erstellen und erhält Zugriff auf die Ressource.

Von https: //developer.mozilla .org / de-US / docs / Web / HTTP / Access_control_CORS

Zusätzlich für HTTP-Anforderungsmethoden, die Nebenwirkungen auf Benutzerdaten verursachen können (insbesondere für HTTP-Methoden) anders als GET oder für die POST-Verwendung mit bestimmten MIME-Typen) schreibt die Spezifikation vor, dass Browser die Anforderung "vorab prüfen", unterstützte Methoden vom Server mit einer HTTP-OPTIONS-Anforderungsmethode anfordern und dann nach "Genehmigung" vom Server senden die tatsächliche Anforderung mit der tatsächlichen HTTP-Anforderungsmethode. Server können Clients auch benachrichtigen, ob "Anmeldeinformationen" (einschließlich Cookies und HTTP-Authentifizierungsdaten) mit Anforderungen gesendet werden sollen.

Soweit mir bekannt ist, verwenden Sie HTTP-Methoden wie 'PUT' anstelle von 'POST'. Da bei einer domänenübergreifenden Anforderung mit 'PUT' als angegebener Methode immer eine Anforderung vor dem Flug geprüft wird, um festzustellen, ob der Ursprung zulässig ist, kann dies verhindert werden Angriffe in bestimmten Situationen. Dies liegt daran, dass der Ursprung vom Angreifer nicht gefälscht werden kann, da moderne Browser nicht zulassen, dass clientseitige Skriptsprachen wie Javascript den 'Ursprung' oder benutzerdefinierte Header strong festlegen > Domänenübergreifend schlägt der Angriff fehl .

Hoffe, das hat geholfen.

Es scheint, dass CORS zum Schutz vor CSRF beiträgt, indem nur Dienste mit falsch konfiguriertem CORS mit Diensten mit ordnungsgemäß konfiguriertem CORS verglichen werden.Bei Diensten, die den Origin-Anforderungsheader nicht interpretieren, nicht auf OPTIONEN antworten und keine CORS-Header enthalten, verhindern sowohl alte als auch moderne Browser, dass böswillige Skripte PUT-Anforderungen an folgende senden: https://w3c.github.io/webappsec-cors-for-developer / # cors
* "Nicht-Standard-HTTP-Methoden wie 'PUT'" * was?[PUT ist sicherlich Standard.] (Https://www.w3.org/Protocols/HTTP/1.0/spec.html#PUT)
#6
  0
ShortFuse
2019-09-14 19:51:49 UTC
view on stackexchange narkive permalink

Ja, es hilft, aber nicht wirklich beabsichtigt.

CORS steht für Cross-Origin Resource-Sharing . Es ist nicht wirklich für die Sicherheit gedacht. CORS ist in die Fetch API integriert, daher ist es nur für Javascript nützlich (dazu später mehr). Standardmäßig kann fetch () aufgrund der Single Origin Policy ( SOP ) nicht erfassen, was sich nicht im selben Ursprung befindet. CORS lockert das, indem es sagt, welche anderen Ursprünge auf eine Ressource zugreifen dürfen. Außerdem verhält sich XMLHttpRequest genauso.

Ja, es kann also helfen, Cross-Site-Scripting ( XSS ) zu blockieren, da die Ressource versucht, von einem anderen Ursprung aus darauf zuzugreifen. Und technisch gesehen blockiert Ihr Server die Anforderung nicht. Es ist ein Browser, der die Anforderung nicht durchläuft, indem er den Header Access-Control-Allow-Origin berücksichtigt.

Dies gilt jedoch nur für Javascript. Browser verwenden CORS nicht für einfache Anfragen.

Das bedeutet, dass einfache GET -Anfragen (wie gefälschte Bilder) nicht von CORS gestoppt werden. Außerdem lösen POST -Anfragen, die nicht in Javascript ausgeführt wurden (dh Formulare), kein CORS aus. Sie brauchen noch Schutz davor. Die Sicherheit ist nur so stark wie Ihr schwächstes Glied. Sobald Sie CSRF auf Serverebene von einfachen Anforderungen abhalten, werden Sie feststellen, dass Ihr CORS nur ein Extra ist Schicht, die nicht wirklich notwendig ist, aber trotzdem schön zu haben.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...