Haben CORS und XSS irgendeine Verbindung?

Question

Cross-Site-Scripting (XSS) wird auf der Wikipedia-Seite für CORS erwähnt. Aber ich sehe nicht, wie sie miteinander verwandt sind. Was ist die Verbindung zwischen CORS und XSS?

Answer 1

Zum Beispiel: Sie können Ihren Js-Code, mit dem Sie Benutzer Cookies stehlen können, in einige Seiten (XSS) injizieren. Sie können dies dank CORS tun.

Hoffe, dass ich nicht falsch bin. Vielleicht gibt dir jemand eine bessere Antwort.

Answer 2

XSS ist in der Wikipedia-Artikel in Bezug auf JSONP, nicht CORS erwähnt.

In JSONP verweisen Sie auf eine Seite Daten enthält Client-Seite auf Ihrer Seite wie so enthalten sein sollen:

<script src="https://example.com/jsonp.aspx?callback=foo"></script> 

Sie dann eine JavaScript-Funktion auf Ihrer Seite foo genannt, die durch die externe Seite aufgerufen wird (example.com in diesem Fall), um die Daten zu übergeben, die Ihre Client-Seite erfordert.

Wenn jedoch example.com kompromittiert wird und Sie als Quelle von Skripten example.com vertrauen, kann ein Angreifer Ihre Site mitnehmen und den clientseitigen Code besitzen. Zum Beispiel könnten sie Besucher auf ihre eigene Website umleiten, indem sie sich die Cookies Ihrer Besucher senden oder Javascript-Keylogger einsetzen, anstatt Ihre foo-Funktion aufzurufen. obwohl

Mit CORS, wenn example.com die richtigen Header setzt Ihre Website zu ermöglichen, um AJAX es nennt, und die Daten retreive, dann, wie Sie sollten Behandlung der Daten als untrused eingegeben werden, statt HTML, ist es weniger wahrscheinlich, dass Ihre Site kompromittiert ist. Es hängt davon ab, was die Daten sind - wenn es sich tatsächlich um vorformatiertes HTML handelt und Sie es so ausgeben wie es dann ist, dann könnte eine kompromittierte externe Seite Ihre über XSS noch beeinflussen - allerdings ist dies bei JSONP definitiv der Fall.

Ein weiterer Punkt ist, dass, wenn es XSS-Fehler auf Ihrer Website gibt, würde es alle CORS-Einschränkungen irrelevant machen. Die angreifende Website wäre in der Lage, den XSS-Fehler zu verwenden, um die Same Origin Policy auf DOM-Ebene statt über XHR "zu umgehen". Wenn sie Informationen brauchten, die nur durch eine AJAX-Anfrage von Ihrem Ursprung abgerufen werden können, verwenden sie einfach den XSS-Angriff, um das erforderliche Skript zu injizieren und es an ihre eigene Domäne zurückzusenden.

Answer 3

https://www.e-systems.tech/documents/20143/30947/main.pdf

Ja, sie sind extrem verbunden. Ich habe die Angelegenheit recherchiert, als ich auf diesen unbeantworteten Thread stieß. Grundsätzlich sollte es kein Problem für kleine, einfache und öffentliche Inhalte sein.

Da jedoch die Integration durch CORS in interaktiven und komplexen Anwendungen zunimmt, kann XSS auf einem anfälligen System verwendet werden, um unser System anzugreifen. Zum Beispiel kann sich ein Wurm, der sich selbst über XSS verbreitet, das verwundbare System nur als Liefermechanismus verwenden, sein Ziel kann jedoch unser System sein.

Bei meinen Recherchen habe ich festgestellt, dass CORS zu Problemen mit den häufigsten Schwachstellen führen wird, insbesondere bei hybriden und mehrstufigen Angriffen; Paare wie XSS-CSRF.

Ohne weiter alle meine Ergebnisse zu diskutieren (es war ein großes Papier), wenn Sie wirklich Systeme durch CORS integrieren wollen, sollten Schwachstelleneinschätzungen bei allen beteiligten Partnern für die gemeinsame Nutzung von Ressourcen gemacht werden.Abhängig von der Anwendungsdomäne werden, wenn sensible Daten betroffen sind, rechtliche Bedenken auftreten (z. B. wer ist verantwortlich, wenn eine Verletzung auftritt). (Die Komplexität ist selten vertretbar).

Um CORS korrekt auf komplexen Systemen zu verwenden, sollte ein Sicherheitsexperte beteiligt sein. Und wenn das System mit mehreren Partnern und Richtlinien für verschiedene Ressourcen wachsen soll, sollte Sicherheit in die Architektur eingebettet werden, um Einschränkungen dynamisch zu validieren.

Es scheint klar zu sein, dass CORS für den täglichen Gebrauch in begrenzten Anwendungen ohne sensible Daten oder nur mit wirklich öffentlichen Ressourcen verwendet werden sollte, es sei denn, Sie vertrauen der Sicherheit Ihrer Partner wirklich - und implementieren die gesamte Konfiguration korrekt. Dies gilt, wenn Sie serverseitige Architekturen erstellen, aber auch umgekehrt, da Sie dem Inhalt vertrauen müssen, der auf der Clientseite hinzugefügt werden soll.