Wie der Angriff funktioniert

Browser senden bei Cross-Origin-Zugriffen einen Origin-Header mit. Der Server entscheidet über die Antwort-Header Access-Control-Allow-Origin (ACAO) und Access-Control-Allow-Credentials (ACAC), welche fremde Herkunft die Antwort lesen darf und ob dabei Cookies/Anmeldedaten mitgeschickt werden dürfen.

Standardmäßig senden Browser bei Cross-Origin-Anfragen keine Credentials (MDN). Fehlkonfigurationen entstehen, wenn der Server eine der folgenden Schwächen aufweist:

  • Ungeprüftes Zurückspiegeln: Der Server spiegelt die vom Client gelieferte Origin ungeprüft in ACAO zurück.
  • Fehlerhafte Whitelist-Prüfung: Whitelist-Prüfungen werden fehlerhaft per Präfix/Suffix/Regex umgesetzt (z. B. erlaubt "endet auf normal-website.com" auch die vom Angreifer registrierte Domain hackersnormal-website.com, "beginnt mit normal-website.com" auch normal-website.com.evil-user.net).
  • Whitelisting von null: Der Server whitelistet den Sonderwert null, den ein Angreifer über eine sandboxed iframe erzeugen kann.

Setzt der Server zusätzlich ACAC: true, kann die Angreifer-Seite via fetch/XMLHttpRequest mit withCredentials=true authentifizierte Anfragen stellen und die Antwort des Opfers auslesen.

Wichtig laut MDN: Bei Anfragen mit Credentials muss der Server eine konkrete Origin statt des Wildcards * angeben. Zudem kann der Origin-Header von Nicht-Browser-Clients wie curl frei gefälscht werden, weshalb er laut OWASP nicht zur Authentifizierung dienen darf.

1. AusgangslageAPI spiegelt Origin oder erlaubt Credentials zu weit
→
2. AngriffFremde Website sendet Anfrage mit Cookies
→
3. ErgebnisAuthentifizierte Antwort wird gestohlen

Zu großzügiges CORS lässt fremde Seiten authentifizierte Daten lesen.

Beispiel

Anfrage
GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...
Antwort
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...

Auswirkung

Eine fremde, vom Angreifer kontrollierte Website kann im Namen eines eingeloggten Opfers authentifizierte Antworten der API auslesen und so sensible Daten stehlen, etwa API-Keys, CSRF-Tokens oder personenbezogene Daten.

Laut PortSwigger lässt sich dies weiter eskalieren:

  • Vertrauensbeziehungen: über Vertrauensbeziehungen zu einer XSS-anfälligen Subdomain.
  • Aufbrechen von TLS: über das Aufbrechen von TLS, wenn eine HTTP-Subdomain als vertrauenswürdig gilt.
  • Zugriff auf Intranet: bei ACAO: * ohne Credentials als Zugriff auf interne Intranet-Ressourcen, indem der Browser des Opfers als Proxy missbraucht wird.

So schützt man sich

  • Origins niemals ungeprüft aus dem Origin-Header zurückspiegeln; in Access-Control-Allow-Origin nur tatsächlich vertrauenswürdige Origins eintragen (PortSwigger).
  • Whitelist-Prüfung exakt auf den vollständigen Origin-String durchführen, nicht über Präfix/Suffix-Matching oder fehleranfällige Regex, um Bypass-Domains wie hackersnormal-website.com oder normal-website.com.evil-user.net auszuschließen (PortSwigger).
  • Den Wert null nicht whitelisten; Access-Control-Allow-Origin: null vermeiden, da sandboxed/serialisierte Anfragen ihn erzeugen können (PortSwigger).
  • Wildcard * nicht zusammen mit Anmeldedaten verwenden - laut MDN muss der Server bei Anfragen mit Credentials eine konkrete Origin angeben; im Internet keine Wildcards für sensible/interne Ressourcen einsetzen (MDN, PortSwigger).
  • Den Origin-Header nicht zur Authentifizierung nutzen, da er von Nicht-Browser-Clients (curl/Wget/Burp) frei gefälscht werden kann (OWASP).
  • CORS ist kein Ersatz für serverseitige Sicherheit: Authentifizierung auf den zugegriffenen Ressourcen erzwingen und Session-Management sowie Schutz sensibler Daten serverseitig durchsetzen (PortSwigger, OWASP).

Quellen

Weiterlesen
ÜbersichtOWASP API Security Top 10 AngriffWebhook-Sicherheit