Frage:
Wie verhindert CORS XSS?
Gigi
2015-12-23 19:24:30 UTC
view on stackexchange narkive permalink

Ich habe kürzlich von CORS erfahren und den Eindruck gewonnen, dass der Zweck darin besteht, XSS zu verhindern. Bei CORS blockiert der Browser Anforderungen an verschiedene Domänen, sofern keine bestimmten Header vorhanden sind.

Wenn jedoch eine Person mit böswilliger Absicht JavaScript in eine Seite einfügt, um die Cookies der Benutzer zu stehlen und senden Sie sie an eine von ihm kontrollierte URL. Er muss lediglich den folgenden Header auf der Serverseite hinzufügen, damit die Anforderung trotzdem funktioniert:

  Zugriffssteuerung-Zulassen-Ursprung: *  

Wie verhindert CORS XSS? Oder habe ich den Zweck von CORS falsch verstanden und es hat einfach nichts mit XSS an sich zu tun?

"Alles, was er tun muss, ist, den folgenden Header auf der Serverseite hinzuzufügen, damit die Anforderung trotzdem funktioniert." Wenn jemand Zugriff auf die HTTP-Header-Konfiguration auf dem Server hat, gibt es größere Probleme als domänenübergreifende Angriffe.
Er kann das tun, weil es sein Server ist (in dem von mir vorgeschlagenen Szenario): "eine URL, die er kontrolliert".
Sechs antworten:
#1
+42
marstato
2015-12-23 19:56:35 UTC
view on stackexchange narkive permalink

TL; DR: Wie verhindert CORS XSS? Das tut es nicht. Dies ist nicht beabsichtigt.

CORS soll es Ressourcenhosts (alle Dienste, die ihre Daten über HTTP verfügbar machen) ermöglichen, einzuschränken, welche Websites auf diese Daten zugreifen dürfen.

Beispiel: Sie hosten eine Website mit Verkehrsdaten und verwenden AJAX-Anforderungen auf Ihrer Website. Wenn SOP und CORS nicht vorhanden wären, könnte jede andere Website Ihre Verkehrsdaten anzeigen, indem Sie einfach AJAX an Ihre Endpunkte senden. Jeder kann leicht Ihre Daten und damit Ihre Benutzer und Ihr Geld "stehlen".

In einigen Fällen ist das Teilen von Daten ( C Ross O rigin R esource S haring) ist vorgesehen, z Wenn Sie Likes und Inhalte aus der Facebook-API auf Ihrer Webseite anzeigen. Das einfache Entfernen von SOP, um dies zu erreichen, ist aus den im obigen Absatz erläuterten Gründen eine schlechte Idee. Daher wurde CORS eingeführt.

CORS hat nichts mit XSS zu tun, da jeder Angreifer, der ein böses Stück JavaScript auf einer Website platzieren kann, auch einen Server einrichten kann, der korrekte CORS-Header sendet. CORS kann nicht verhindern, dass böswilliges JavaScript Sitzungs-IDs und Permlogin-Cookies an den Angreifer zurücksendet.

Unabhängig davon, ob SOP und CORS vorhanden waren oder nicht, kann jede andere Website die Anforderungen ihrer Benutzer vertreten.
@tepples: In diesem Fall werden die Cookies für die ursprüngliche Site jedoch nicht mit der Anfrage gesendet und es ist daher nicht möglich, Daten zu lesen, die nur der angemeldete Benutzer sehen kann.
@SteffenUllrich Dies würde das Verhalten erklären, wenn die Richtlinie mit demselben Ursprung nur Cookies blockiert. Es blockiert jedoch den clientseitigen Skriptzugriff auch auf öffentliche Ressourcen, auf die der Benutzer ohne Cookies zugreifen kann.
Richtig. Aber so funktioniert CORS - wie alles andere hat es seine Schwächen.
Genau. CORS schränkt nichts ein oder verhindert es nicht. CORS soll eine kontrollierte Möglichkeit bieten, die durch die Richtlinie mit demselben Ursprung auferlegten Beschränkungen zu lockern. Ohne CORS wäre das Web immer noch genauso sicher (wenn auch nicht so funktionsfähig).
Können andere Websites nicht indirekt über die Serverseite auf Ihre öffentlichen Website-Daten zugreifen?Verhindert es nicht * nur *, dass willige Kunden beim Besuch einer anderen Website auf die Daten Ihrer Website zugreifen?Wenn mein Verständnis richtig ist, ist Ihre Antwort falsch und dies verhindert nur ausdrücklich, dass Websites den Browser eines nicht böswilligen Benutzers über clientseitige js auf die Daten Ihrer Website leiten.
Ja, dies ist möglich, es sei denn, die vertraulichen Daten sind mit einem Login geschützt.Eine ausländische Website hat keinen Zugriff auf die Sitzungscookies der Website "target" / "cors-protected".Daher kann ein böswilliger Server keine gültige Anfrage für die Daten senden - nur der Browser des Benutzers und der Ressourcenbesitzer können eine gültige Anfrage erstellen
Das Beispiel ist irreführend.Dies ist nicht der Zweck von CORS.Ihr Rivale kann eine ähnliche Website wie Ihre erstellen, die im Backend Ihren Server mit den richtigen Ursprungsheadern aufruft, und CORS wird sie nicht stoppen.
@GeorgiiOleinikov Ja, sie könnten.Aber in diesem Fall kann ich ihre IPs effektiv blockieren, ohne meine legitimen Benutzer zu beeinträchtigen.Dies ist der Zweck von CORS.Sie können Ihre eigene Antwort posten, wenn Sie der Meinung sind, dass CORS einen grundlegend anderen Zweck hat.
@marstato Können Sie den gesamten Adressraum der AWS-Flotte blockieren?Was ist, wenn einige Ihrer legitimen Benutzer Proxy unter AWS verwenden? Der Zweck von CORS ist meiner Meinung nach, die SOP zu lockern, und der Zweck von SOP ist es, sicherzustellen, dass CSRF-Angriffe nicht mit Javascript ausgeführt werden
@GeorgiiOleinikov Je nach Anwendungsfall ja.Legitime Endbenutzer haben keine AWS-IP.Im Allgemeinen ist das ein guter Punkt.Ich habe die W3C-Dokumente dazu nicht gelesen - sie werden klarstellen, was die Absicht hinter CORS ist.
@GeorgiiOleinikov Ich denke, der Punkt ist, dass Ihr Proxyserver nicht vorgeben konnte, jemand anderes zu sein.Das heißt, es können keine Proxy-Anfragen an www.example.com gesendet werden, die vorgeben, ein angemeldeter Benutzer wie Alice zu sein, da Ihr AWS-Server keinen Zugriff auf ihre Cookie-Informationen hat.Aus diesem Grund fügen die CORs eine Schutzschicht hinzu.
#2
+18
Steffen Ullrich
2015-12-23 19:48:17 UTC
view on stackexchange narkive permalink

Cross-Site-Scripting (XSS) ist die Ausführung von vom Angreifer definiertem Skriptcode im Kontext einer anderen Site. CORS verhindert XSS nicht, tatsächlich hat es nichts mit XSS zu tun.

Stattdessen bietet CORS eine Möglichkeit, bestehende Einschränkungen für Ajax-Anforderungen (d. H. XMLHTTPRequest) auf eine Weise zu schwächen, die hoffentlich keine weiteren Sicherheitsprobleme mit sich bringt. Traditionell war XMLHTTPRequest auf die Kommunikation innerhalb desselben Ursprungs beschränkt, dh es war nicht möglich, eine Anfrage an eine externe Site zu senden. Diese Einschränkung wurde vorgenommen, damit ein Angreifer keine standortübergreifende Anforderung ausführen und das Ergebnis der Anforderung nicht zurückerhalten kann, da dies einem Angreifer das Lesen von Daten von Websites ermöglichen würde, auf denen die Benutzer angemeldet waren (da jeweils Sitzungs- und andere Cookies gesendet werden Anfrage an eine Site).

Mit CORS wird diese Einschränkung teilweise aufgehoben. Es ist jetzt möglich, eine XMLHTTPRequest an eine andere Site zu senden, aber das Ergebnis kann nur in der Anwendung gelesen werden, wenn die Remote-Site explizit einige CORS-Header hinzugefügt hat, die den Zugriff ermöglichen. Dies führt jedoch wiederum kein Skript auf der Remote-Site aus und ist daher nicht mit XSS verbunden.

Um klar zu sein, war es bereits vor CORS möglich, eine Anfrage mithilfe eines Formulars an eine externe Site zu senden. Was CORS erlaubt, ist das * Zurücklesen * der Antwort von einer standortübergreifenden AJAX-Anfrage.
#3
+3
Keaser
2019-06-23 11:41:45 UTC
view on stackexchange narkive permalink

CORS schützt nichts, SOP (Same Origin Policy) schützt stattdessen etwas. SOP schützt die Zieldomäne und den Browser Benutzer.

Tatsächlich schwächt CORS die bestehenden Einschränkungen von SOP, um Website-Entwicklern die Verwendung gemeinsam genutzter Daten anderer Herkunft zu erleichtern.

#4
+2
akostadinov
2017-12-17 20:59:38 UTC
view on stackexchange narkive permalink

Andere Antworten sind richtig, dass XSS und CORS nicht direkt miteinander verbunden sind (obwohl CORS dazu beitragen kann, die Auswirkungen von XSS auf die anfällige Site zu begrenzen).

Grundsätzlich ermöglicht CORS dem Frontend-Code Ihrer Website den Zugriff auf Ihr Website-Backend mit den Cookies und Anmeldeinformationen, die in Ihrem Browser eingegeben wurden, während Ihr Backend vor den js einer anderen Site geschützt bleibt, und den Client-Browser auffordert, darauf zuzugreifen (mit Anmeldeinformationen, die der Benutzer erhalten hat).

Dies ist, wenn Control-Allow -Credentials: true ist gesetzt (wodurch der Browser Cookies und grundlegende / gssapi / napi-Authentifizierung senden kann). Ich bin mir immer noch nicht sicher, wie CORS ohne diese Option hilft. Siehe meine Frage " muss ich den Ursprung in einer API-App einschränken?"

#5
+2
Daniel
2020-01-15 03:32:01 UTC
view on stackexchange narkive permalink

CORS und XSS sind verwandt, aber nicht direkt. Der beste Weg, dies zu erklären, ist ein Beispiel: Wir betrachten 3 Server (your_bank.com, api.your_bank.com, badguy.com *) und 1 Client (Ihren Browser).

  1. Sie sind bei your_bank.com angemeldet (Ihr Browser enthält Authentifizierungscookies).
  2. Your_bank.com führt Transaktionen durch, indem AJAX-Anfragen mit noch mehr Cookies (im Browser gespeichert) an api.your_bank.com gesendet werden. Normalerweise blockiert die SOP Ihres Browsers diese Anforderung, aber stattdessen erlaubt CORS (gewährt von api.your_bank.com) dies.
  3. Sie sehen auf badguy.com etwas Glänzendes und besuchen diese Seite.
  4. Badguy.com versucht Transaktionen, indem es AJAX-Anfragen an api.your_bank.com sendet und dabei die Cookies für diese Domain verwendet, die in Ihrem Browser gespeichert sind.
  5. ol>

    In Schritt 4 wird Ihr Browser (der nicht gefährdet ist) verwendet ) besitzt den an api.your_bank.com gesendeten "Origin" -Header. Wenn CORS korrekt konfiguriert ist, wird dieser Schritt blockiert. Ihr Browser, der Eigentümer der Cookies und Anforderungsheader ist, überwacht den Zugriff auf andere Websites.

    * Die Website badguy.com ist möglicherweise legitim, leidet jedoch unter einem XSS-Problem.

_ "Dieser Schritt wird blockiert" _ Ich bin damit einverstanden, dass das _read_ blockiert wird (dh der böswillige Ursprung kann keine vertraulichen Informationen von Ihrem Bankkonto abrufen), aber _writes_ werden derzeit nicht vom Browser blockiert (daher kann CSRF hier im Spiel sein)
Dies ist eine ausgezeichnete Antwort, die ich im Klartext verstehen kann.
#6
  0
Micah B.
2020-08-21 02:08:33 UTC
view on stackexchange narkive permalink

Der Browser verwendet CORS, um den Benutzer zu schützen. Er schützt die Dienste nicht.

Standardmäßig blockieren Browser JS-Anforderungen von a.com to b.com .

b.com kann CORS-Header veröffentlichen, um Browser über a.com zu informieren ist vertrauenswürdig (z. B. facebook.com kann veröffentlichen, dass ihre messenger.com Domain vertrauenswürdig ist)

Gute Browser blockieren Cross-Origin-Skripte, um Benutzer zu schützen. Wenn b.com CORS mit bestimmten vertrauenswürdigen Domänen veröffentlicht, ermöglicht der Browser diesen Domänen den Zugriff auf Dienste unter b.com . Wenn der Browser diese für den Benutzer nicht blockiert, kann ein Benutzer auf unschuldig aussehende- bösartige-Site.com zugreifen, die im Namen des Benutzers auf facebook.com -Dienste zugreifen kann und Zugriff auf sichere Cookies und andere Informationen erhalten.

Lose Beziehung zu XSS

Wenn eine legitime Site durch einen XSS-Angriff kompromittiert wurde, kann die CORS / Browser-Kombination den Benutzer schützen, wenn Der Domänenname der legitimen Site wird nicht im CORS-Header veröffentlicht.

CORS kann eine Site nicht vor einer Gefährdung durch XSS schützen, kann dem Benutzer jedoch helfen, wenn er auf eine XSS-gefährdete Site zugreift .

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



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...