it-swarm.com.de

Hilft CORS trotzdem gegen Cross-Site Forgery?

Ich habe in den letzten Tagen über CORS gelesen und an vielen Stellen wird es erwähnt, da es eine "Sicherheits" -Funktion ist, 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/Server validiert den Ursprung. Ein Angreifer kann jedoch problemlos eine HttpRequest von oben nach unten mit den von ihm gewünschten Headern (Ursprung) erstellen und erhält Zugriff auf die Ressource.

Wie hilft CORS und was ist der Nutzen davon?

37
Dan Dinu

Ich beginne meine Antwort damit, dass viele Leute die Same Origin Policy und was CORS falsch verstehen, falsch verstehen.

Einige der bereits hier abgestimmten Antworten besagen, dass die Same Origin-Richtlinie standortübergreifende Anforderungen verhindert und daher CSRF verhindert. Das ist nicht der Fall. Alles, was SOP] tut, ist zu verhindern, dass die Antwort von einer anderen Domain (auch bekannt als Origin) gelesen wird. Dies ist irrelevant, ob ein CSRF-Angriff erfolgreich ist oder nicht.

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

Alles, was CORS tut, ist das Entspannen von SOP, wenn es aktiv ist. Es erhöht nicht die Sicherheit, es erlaubt einfach einige Ausnahmen. Einige Browser mit teilweiser CORS-Unterstützung erlauben Cross-Site-XHR-Anforderungen (z. B. IE 10 und früher), benutzerdefinierte Header können jedoch nicht angehängt werden. In CORS-unterstützten Browsern kann der Origin-Header nicht festgelegt werden, wodurch ein Angreifer davon abhalten, dies zu fälschen.

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

Schließlich hat all das nichts mit gefälschten Anfragen zu tun, die direkt von einem Angreifer stammen, beispielsweise mit Curl. 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 Ihre Domain Lesevorgänge von einer anderen vertrauenswürdigen Domain zulassen kann. Wenn Sie also http://data.example.org Haben, können Sie Antwortheader festlegen, damit http://site.example.com AJAX Anfragen stellen und Daten von Ihrer API abrufen kann).

50
SilverlightFox

Sie vermischen die Dinge. CORS soll Ihre Anwendung nicht vor gestalteten http-Anfragen 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 die Der Browser sendet alle noch aktiven und für Ihre Site gültigen Anmelde- und Sitzungscookies.

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, und aus diesem Grund die meisten Authentifizierungsprozesse sollten SSL verwenden als zusätzliche Schutzschicht.

PS: Dies setzt voraus, dass der von Ihrem Benutzer verwendete Browser auf dem neuesten Stand ist, keine Fehler aufweist und die gleiche Origin-Richtlinie korrekt befolgt.

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

12
BgrWorker

Ist es sinnvoll, dies alles wie folgt zusammenzufassen:

  • SOP (Single Origin Policy) stellt sicher, dass CSRF-Angriffe nicht von innerhalb einem modernen, aktuellen Browser ausgeführt werden können, da der Angreifer dies tun müsste POST von einer anderen Domain.

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

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

2
Grub

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

Entweder haben Sie die Vorteile von CORS falsch verstanden, oder Sie haben das in einigen Amateur -Blogs gelesen, die von Entwicklern erstellt wurden, die sich mehr Sorgen machen über 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 Öffnen Sie originübergreifende Anforderungen aus dem Origin des Angreifers, indem Sie CORS mit dem folgenden Header verwenden: Access-Control-Allow-Origin: *

Wie hilft CORS und was ist der Nutzen davon?

CORS wurde geboren, um die Einschränkungen der SOP für vertrauenswürdige Anfragen zu erleichtern - nur. Aber die Probleme beginnen genau damit Vertrauen. Ein Angreifer kann durch rsprünge Schaden anrichten, indem er böswillige Anforderungen über die Methoden GET und POST) fälscht und Sie sogar DNS-Neubindung aussetzt

1
user45139

Was diesen Teil betrifft,

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

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

Für HTTP-Anforderungsmethoden, die Nebenwirkungen auf Benutzerdaten verursachen können (insbesondere für andere HTTP-Methoden als GET oder für POST Verwendung mit bestimmten MIME-Typen), schreibt die Spezifikation vor, dass Browser "Preflight" der Anforderung, Anfordern unterstützter Methoden vom Server mit einer HTTP OPTIONS-Anforderungsmethode und anschließendes Senden der tatsächlichen Anforderung mit der tatsächlichen HTTP-Anforderungsmethode nach "Genehmigung" durch den Server. Server können Clients auch benachrichtigen, ob "Anmeldeinformationen" (einschließlich Cookies und HTTP-Authentifizierungsdaten) sollten mit Anfragen gesendet werden.

Soweit mir bekannt ist, wird immer HTTP-Methoden wie 'PUT' anstelle von 'POST' verwendet, und weil eine domänenübergreifende Anfrage mit 'PUT' als angegebener Methode immer vorangestellt wird Durch eine Anforderung vor dem Flug, um zu überprüfen, ob der Ursprung zulässig ist, können Angriffe in bestimmten Situationen verhindert werden. Dies liegt daran, dass der Origin vom Angreifer nicht gefälscht werden kann, da moderne Browser nicht zulassen clientseitige Skriptsprachen wie Javascript auf setzen Sie den 'Origin' oder benutzerdefinierte Header domänenübergreifend schlägt der Angriff fehl.

Hoffe das hat geholfen.

0
racec0ndition

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 gefaltet, daher ist es nur für Javascript nützlich (dazu später mehr). Standardmäßig kann fetch() aufgrund der Single Origin-Richtlinie (SOP) nicht erfassen, was sich nicht im selben Ursprung befindet ). CORS lockert das auf, indem es sagt, welche andere Ursprünge auf eine Ressource zugreifen dürfen. Auch XMLHttpRequest verhält sich genauso.

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

Aber das ist nur für Javascript. Browser verwenden CORS nicht für Simple Requests .

Das bedeutet, dass einfache GET Anfragen (wie gefälschte Bilder) nicht von CORS gestoppt werden. Außerdem lösen POST Anforderungen, die nicht in Javascript ausgeführt wurden (dh Formulare), kein CORS aus. Sie brauchen noch Schutz davor. Sicherheit ist nur so stark wie Ihr schwächstes Glied, und sobald Sie anfangen, CSRF auf Serverebene von zu verhindern, ist dies einfach Bei Anfragen werden Sie feststellen, dass Ihr CORS nur eine zusätzliche Ebene ist, die nicht wirklich notwendig ist, aber dennoch schön zu haben ist.

0
ShortFuse