Was sind CORS-Angriffe und wie können Sie sie verhindern?

Cross-Origin Resource Sharing (CORS)-Angriffe werden durch Fehlkonfigurationen von Webservern ermöglicht. In diesem Artikel schauen wir uns an, was CORS-Angriffe sind, wie sie funktionieren und was Sie tun können, um sie zu vermeiden. Bevor wir uns jedoch mit CORS selbst befassen, müssen wir ein wenig über eine andere wichtige Webserver-Sicherheitsrichtlinie verstehen: die Same-Origin-Richtlinie (SOP).

Same-Origin-Richtlinie

Die meisten Webserver sind mit einer Same-Origin-Richtlinie (SOP) konfiguriert. Die Aufgabe von SOP besteht darin, die Ursprünge einzuschränken, von denen aus Skripte auf andere Ursprünge zugreifen können. Wenn der letzte Satz für Sie keinen Sinn ergibt, machen Sie sich keine Sorgen – das wird er. Habt hier einfach Geduld mit mir.

Ein Ursprung besteht aus:

• von URI-Schemata
• eine Domäne
• eine Portnummer

Es sieht aus wie das:

|_+_|

Im obigen Beispiel ist das URI-Schema HTTP, die Domäne ist „regular-website.com“ und der Port ist implizit 80, da unser URI-Schema HTTP ist, das implizit Port 80 verwendet.

Ein Ursprung ist einfach ein bestimmter Ort auf einem Webserver, auf den über ein URI-Schema, eine Domäne und eine Portnummer zugegriffen werden kann. Sowohl der anfragende Webserver als auch der angeforderte Webserver haben Ursprünge.

Wenn eine ordnungsgemäße SOP vorhanden ist, lehnt der Webserver jeden Ursprung (d. h. das URI-Schema, die Domäne und die Portnummer eines anderen Webservers) ab, der mit einem anderen Zugriff auf http://regular-website.com/regular-stuff/stuff anfordert URI-Schema, Domäne oder Portnummer.

Die Same-Origin-Richtlinie ist von entscheidender Bedeutung, denn wenn ein Browser eine Anfrage von einem Ursprung an einen anderen stellt, könnten Sitzungscookies zusammen mit der Anfrage gesendet werden, um die Antwort innerhalb der Sitzung des Benutzers zu generieren und benutzerspezifische und potenziell sensible Daten bereitzustellen. Sitzungscookies werden verwendet, um Sie bei späteren Besuchen auf einer Website angemeldet zu halten, könnten aber auch von einem Angreifer verwendet werden, um den Anmeldevorgang der Website zu umgehen.

Wenn Sie sich ohne eine ordnungsgemäße SOP auf Ihrer Banking-Website anmelden, könnten alle anderen geöffneten Tabs in Ihrem Browser (sofern diese schädliche Ressourcen enthalten) auf Ihre Online-Banking-Sitzung zugreifen. Wenn Sie sich bei Ihrem E-Mail-Konto angemeldet haben, können sie Ihre E-Mails lesen. Wenn Sie einen privaten Chat in einer Messenger-Anwendung führten, könnten diese Ihre privaten Gespräche mitlesen.

Du bekommst das Bild.

Kurz gesagt, das ist SOP. Es klappt. Aber es kann etwas restriktiv sein. Schließlich gibt es heutzutage viele Websites/Online-Dienste, die miteinander interagieren und einen herkunftsübergreifenden Zugriff erfordern.

Hier kommt CORS ins Spiel.

Was ist CORS?

Cross-Origin Resource Sharing (CORS) kann als kontrollierte Lockerung der Same-Origin-Politik verstanden werden. CORS bietet eine kontrollierte Möglichkeit, ursprungsübergreifende Ressourcen gemeinsam zu nutzen.

Das CORS-Protokoll arbeitet mit spezifischen HTTP-Headern, die angeben, welche Web-Ursprünge vertrauenswürdig sind und welche Eigenschaften sie haben, beispielsweise ob authentifizierter Zugriff zulässig ist. Diese Parameter werden im HTTP-Header-Austausch zwischen einem Browser und der Cross-Origin-Website ausgedrückt, auf die er zuzugreifen versucht.

So sieht ein typischer Header mit dem angegebenen Ursprungsparameter (fett) aus:

Im obigen Beispiel ist das URI-Schema HTTPS, die Domäne ist foo.example und die Portnummer ist 443 (wie von HTTPS impliziert).

Wenn dieser Header an die Website übertragen wird, muss die Website eine Anfrage stellen, ob die Cross-Origin-Anfrage zugelassen werden soll oder nicht. Ob der Anfrage stattgegeben wird oder nicht, hängt von der CORS-Konfiguration der empfangenden Website ab. Und es ist diese Konfiguration, die CORS-Angriffen Tür und Tor öffnet.

Wenn CORS auf dem Webserver falsch konfiguriert ist und „foo.example“ eine bösartige Website ist, akzeptiert sie die Anfrage und kann Opfer eines CORS-Angriffs werden. Aber das ist nur die halbe Wahrheit.

Arten von CORS-Fehlkonfigurationen

Das ist die halbe Wahrheit, denn es gibt zwei Haupttypen von CORS-Fehlkonfigurationen, die einen Webserver anfällig für CORS-Angriffe machen können – und Sie benötigen beide, um dies zu bewerkstelligen.

• Access-Control-Allow-Origin (ACAO) : Dies ermöglicht eine bidirektionale Kommunikation mit Websites Dritter. Eine Fehlkonfiguration des Access-Control-Allow-Origin (ACAO) kann ausgenutzt werden, um sensible Daten wie Benutzernamen und Passwörter zu ändern oder weiterzuleiten.
• Zugangskontroll-Zulassungs-Anmeldeinformationen (ACAC) : Dadurch können Websites Dritter privilegierte Aktionen ausführen, die nur der echte authentifizierte Benutzer ausführen können sollte. Beispiele hierfür wären die Änderung Ihres Passworts oder Ihrer Kontaktinformationen.

Beide Parameter arbeiten in der CORS-Konfiguration des Webservers zusammen.

Sie laufen auf zwei Fragen hinaus, die der Webserver beantworten muss:

• Akzeptiert der Webserver die Anfrage vom angegebenen Ursprung?
• Wenn ja, stellt es auch Anmeldeinformationen für die Ausführung privilegierter Aktionen bereit?

Die erste Frage entspricht der Richtlinie „Access-Control-Allow-Origin“ und die zweite Frage entspricht der Richtlinie „Access-Control-Allow-Credentials“.

Schauen wir uns die verschiedenen Möglichkeiten an, wie Webserver ihre Access-Control-Allow-Origin-Richtlinie konfigurieren können:

Access-Control-Allow-Origin-Richtlinie

Alle Ursprünge zulassen (*)

Dies ermöglicht den Zugriff von allen Ursprüngen. Sobald eine Cross-Origin-Anfrage eingeht, wird diese zugelassen. Der Antwortheader würde so aussehen:

|_+_|

Dies wird als Ursprungsreflexion bezeichnet, da der Webserver einfach den im Anforderungsheader gefundenen Ursprung in den Antwortheader „spiegelt“. Der Webserver verwendet einen Platzhalter (*), um alle Cross-Origin-Anfragen zu akzeptieren.

Beachten Sie, dass dies aus Sicherheitsgründen nicht unbedingt katastrophal ist. Diese Konfiguration wird von vielen öffentlichen Websites oder API-Endpunkten verwendet, die öffentlich zugänglich sein sollen.

Subdomains zulassen (*.website.com)

Wenn Sie die ACAO-Richtlinie so festlegen, dass Subdomains zulässig sind, werden Cross-Origin-Anfragen von allen Subdomains der definierten Domain zugelassen. Wenn eine gültige Anfrage eingeht, wird sie zugelassen. Der Antwortheader würde so aussehen:

|_+_|

Pre-/Post-Domain-Wildcard (*website.com / website.com.*)

Wenn Sie Ihre ACAO-Richtlinie so festlegen, dass Pre- oder Post-Wildcard-Anfragen von einer bestimmten Domain akzeptiert werden, werden Cross-Origin-Anfragen von evilwebsite.com oder website.com.evilsite.com akzeptiert. Die Antwortheader würden etwa so aussehen:

|_+_|

|_+_|

Null erlaubt (null)

Viele Entwicklungssprachen stellen nicht vorhandene Header mit dem Wert „Null“ dar. Wenn Sie Ihre ACAO-Richtlinie auf Null setzen, bedeutet dies, dass der Webserver ursprungsübergreifende Anfragen vom „Null“-Ursprung akzeptiert. Dies wird häufig in internen Webentwicklungsumgebungen (Intranet) eingesetzt. Der Antwortheader würde so aussehen:

|_+_|

Werfen wir nun einen Blick auf die Access-Control-Allow-Credentials-Richtlinie.

Access-Control-Allow-Credentials-Richtlinie

Die Richtlinie „Access-Control-Allow-Credentials“ wird auf den Wert „true“ oder „false“ festgelegt. Und es ist tatsächlich diese Einstellung, die, wenn sie auf „true“ gesetzt ist, die meisten CORS-Angriffe ermöglicht. Der Antwortheader würde so aussehen:

|_+_|

Ohne diesen Header sendet der Browser des Opfers keine Cookies, sodass der Angreifer nur auf nicht authentifizierte Inhalte zugreifen kann, auf die er genauso leicht zugreifen könnte, indem er einfach die Zielwebsite durchsucht.

Die Schwere der durch die Access-Control-Allow-Credentials-Richtlinie verursachten Sicherheitsverletzung hängt von der Access-Control-Allow-Origin-Richtlinie ab. Eine ACAO-Richtlinie, die auf * (Alle Ursprünge zulassen) und eine ACAC-Richtlinie, die auf „true“ eingestellt ist, eingestellt ist, führt zu einem größeren Verstoß als eine ACAO-Richtlinie, die auf „Subdomains zulassen“ eingestellt ist und eine ACAC-Richtlinie, die auf „true“ eingestellt ist.

Beispiel für einen CORS-Angriff

So könnte ein CORS-Angriff aussehen:

1. Das Opfer besucht evilwebsite.com, während es bei goodwebsite.com authentifiziert wird.
2. evilwebsite.com speichert ein bösartiges Skript, das für die Interaktion mit goodwebsite.com entwickelt wurde, auf dem Computer des Opfers.
3. Das Opfer führt unabsichtlich das bösartige Skript aus und das Skript sendet eine Cross-Origin-Anfrage an goodwebsite.com. Nehmen wir in diesem Beispiel an, dass die Anfrage so gestaltet ist, dass sie die Anmeldeinformationen erhält, die zum Ausführen einer privilegierten Aktion erforderlich sind, beispielsweise zum Offenlegen des Kennworts des Benutzers.
4. goodwebsite.com erhält die Cross-Origin-Anfrage des Opfers und den CORS-Header.
5. Der Webserver überprüft den CORS-Header, um zu bestimmen, ob die Daten an goodwebsite.com gesendet werden sollen oder nicht. In diesem Beispiel gehen wir davon aus, dass CORS mit Authentifizierung zugelassen ist (Access-Control-Allow-Credentials: true).
6. Die Anfrage wird validiert und die Daten werden vom Browser des Opfers an evilwebsite.com gesendet.

Dies ist ein Worst-Case-Szenario, bei dem alles offen ist. Aber es veranschaulicht immer noch, wie ein CORS-Angriff aussieht. Und dieses Worst-Case-Szenario kommt tatsächlich recht häufig vor. Tatsächlich wurde im Jahr 2016 festgestellt, dass Facebook dies tat anfällig für einen solchen CORS-Angriff .

Der Zustand des Webs

Ein inoffizielle Studie Eine im Juni 2020 durchgeführte Studie ergab, dass von den 1 Million Alexa-Websites nur 3 % (29.514) CORS auf ihrer Hauptseite unterstützten.

Wie oben erwähnt, muss die Access-Control-Allow-Credentials-Richtlinie auf „true“ gesetzt sein, um einen CORS-Angriff durchführen zu können. Bei der Betrachtung von Websites, die sowohl ACAO als auch ACAC unterstützen, stellte dieselbe Studie fest, dass fast die Hälfte von ihnen CORS-Fehlkonfigurationen aufwies, die ein böswilliger Akteur ausnutzen konnte.

So verhindern Sie CORS-basierte Angriffe

Es sind vor allem Fehlkonfigurationen von Webservern, die CORS-Schwachstellen ermöglichen. Die Lösung besteht darin, die Entstehung der Schwachstellen durch die richtige Konfiguration der CORS-Richtlinien Ihres Webservers zu verhindern. Hier sind ein paar einfache Tipps zur Verhinderung von CORS-Angriffen.

1. Geben Sie die zulässigen Ursprünge an

Wenn eine Webressource vertrauliche Informationen enthält, sollten die zulässigen Ursprünge vollständig im Access-Control-Allow-Origin-Header angegeben werden (d. h. ohne Platzhalter).

2. Lassen Sie nur vertrauenswürdige Sites zu

Auch wenn dies offensichtlich erscheint, insbesondere angesichts des vorherigen Tippes, sollten die im Access-Control-Allow-Origin-Header angegebenen Ursprünge ausschließlich vertrauenswürdige Sites sein. Damit möchte ich zum Ausdruck bringen, dass Sie die dynamische Widerspiegelung von Ursprüngen aus domänenübergreifenden Anforderungsheadern ohne Validierung vermeiden sollten, es sei denn, es handelt sich bei der Website um eine öffentliche Website, die für den Zugriff keinerlei Authentifizierung erfordert, z. B. einen API-Endpunkt.

3. Nicht „null“ auf die Whitelist setzen

Sie sollten die Verwendung des Headers Access-Control-Allow-Origin: null vermeiden. Während domänenübergreifende Ressourcenaufrufe aus internen Dokumenten und Sandbox-Anfragen den „Null“-Ursprung angeben können, sollten Sie interne ursprungsübergreifende Anfragen genauso behandeln wie externe ursprungsübergreifende Anfragen. Sie sollten Ihre CORS-Header richtig definieren.

4. Implementieren Sie ordnungsgemäße serverseitige Sicherheitsrichtlinien

Denken Sie nicht, dass die richtige Konfiguration Ihrer CORS-Header ausreicht, um Ihren Webserver zu sichern. Es ist eines der Stücke, aber es ist nicht vollständig. CORS definiert das Browserverhalten und ist niemals ein Ersatz für den serverseitigen Schutz sensibler Daten. Sie sollten zusätzlich zu ordnungsgemäß konfiguriertem CORS weiterhin vertrauliche Daten wie Authentifizierung und Sitzungsverwaltung schützen.

Grundsätzlich möchten Sie als Benutzer Phishing-Betrügereien sowie bösartigen Websites und Downloads immer einen Schritt voraus sein, um das Risiko, Opfer eines CORS-Angriffs zu werden, zu minimieren. Die folgenden vernünftigen Tipps können helfen.

Diese Schritte sind bei vielen Online-Angriffen ähnlich, beispielsweise bei der Vermeidung gefälschter Antivirenprogramme, sodass es sich im Allgemeinen um bewährte Vorgehensweisen handelt.

• Verwenden Sie eine Firewall – Alle gängigen Betriebssysteme verfügen über eine integrierte eingehende Firewall und alle kommerziellen Router auf dem Markt verfügen über eine integrierte NAT-Firewall. Stellen Sie sicher, dass Sie diese aktivieren, da sie Sie möglicherweise schützen, falls Sie auf einen schädlichen Link klicken.
• Kaufen Sie nur gut bewertete und echte Antivirensoftware von legitimen Anbietern und konfigurieren Sie es so, dass in regelmäßigen Abständen häufige Scans ausgeführt werden.
• Klicken Sie niemals auf Pop-ups . Man weiß nie, wohin man als nächstes gebracht wird.
• Wenn dein Der Browser zeigt eine Warnung an Informationen zu einer Website, auf die Sie zugreifen möchten, sollten Sie Passt auf und erhalten Sie die Informationen, die Sie benötigen, an anderer Stelle.
• Öffnen Sie keine Anhänge in E-Mails es sei denn, Sie wissen genau, wer den Anhang gesendet hat und um welchen Inhalt es sich handelt.
• Klicken Sie in E-Mails nicht auf Links (URLs). es sei denn, Sie wissen genau, wer die URL gesendet hat und wohin sie führt. Und selbst dann sollten Sie den Link sorgfältig prüfen. Handelt es sich um einen HTTP- oder einen HTTPS-Link? Die meisten legitimen Websites verwenden heute HTTPS. Enthält der Link Rechtschreibfehler (Facebook statt Facebook)? Wenn Sie das Ziel erreichen können, ohne den Link zu verwenden, tun Sie dies stattdessen.

Bleib sicher.