FixVibe
Covered by FixVibehigh

CORS Fehlkonfiguration: Risiken übermäßig freizügiger Richtlinien

Cross-Origin Resource Sharing (CORS) ist ein Browsermechanismus zur Lockerung der Same-Origin Policy (SOP). Auch wenn dies für moderne Web-Apps notwendig ist, kann eine unsachgemäße Implementierung – etwa das Echo des Origin-Headers des Anforderers oder die Whitelist des „Null“-Ursprungs – dazu führen, dass böswillige Websites private Benutzerdaten herausfiltern.

CWE-942

Auswirkungen

Ein Angreifer kann vertrauliche, authentifizierte Daten von Benutzern einer anfälligen Anwendung [S2] stehlen. Wenn ein Benutzer eine bösartige Website besucht, während er bei der anfälligen App angemeldet ist, kann die bösartige Website ursprungsübergreifende Anfragen an den API der App stellen und die Antworten [S1][S2] lesen. Dies kann zum Diebstahl privater Informationen führen, einschließlich Benutzerprofilen, CSRF-Tokens oder privaten Nachrichten [S2].

Grundursache

CORS ist ein HTTP-Header-basierter Mechanismus, der es Servern ermöglicht, anzugeben, welche Ursprünge (Domäne, Schema oder Port) Ressourcen laden dürfen [S1]. Schwachstellen entstehen typischerweise, wenn die CORS-Richtlinie eines Servers zu flexibel ist oder schlecht implementiert ist [S2]:

  • Reflektierter Ursprungsheader: Einige Server lesen den Origin-Header aus einer Clientanforderung und geben ihn im Access-Control-Allow-Origin (ACAO)-Antwortheader [S2] zurück. Dadurch kann jede Website effektiv auf die Ressource [S2] zugreifen.
  • Falsch konfigurierte Platzhalter: Während der Platzhalter * jedem Ursprung den Zugriff auf eine Ressource ermöglicht, kann er nicht für Anfragen verwendet werden, die Anmeldeinformationen erfordern (wie Cookies oder Autorisierungsheader). [S3]. Entwickler versuchen oft, dies zu umgehen, indem sie den ACAO-Header basierend auf der Anfrage [S2] dynamisch generieren.
  • Whitelisting 'null': Einige Anwendungen setzen den null-Ursprung auf die Whitelist, was durch umgeleitete Anfragen oder lokale Dateien ausgelöst werden kann, wodurch böswillige Websites sich als null-Ursprung ausgeben können, um Zugriff auf [S2][S3] zu erhalten.
  • Parsing-Fehler: Fehler beim Regex- oder String-Abgleich bei der Validierung des Origin-Headers können es Angreifern ermöglichen, Domänen wie trusted-domain.com.attacker.com [S2] zu verwenden.

Es ist wichtig zu beachten, dass CORS kein Schutz gegen Cross-Site Request Forgery (CSRF) [S2] ist.

Konkrete Korrekturen

  • Verwenden Sie eine statische Whitelist: Vermeiden Sie die dynamische Generierung des Access-Control-Allow-Origin-Headers aus dem Origin-Header [S2] der Anfrage. Vergleichen Sie stattdessen den Ursprung der Anfrage mit einer fest codierten Liste vertrauenswürdiger Domänen [S3].
  • Vermeiden Sie den „Null“-Ursprung: Nehmen Sie null niemals in Ihre Whitelist der zulässigen Ursprünge [S2] auf.
  • Anmeldeinformationen einschränken: Legen Sie Access-Control-Allow-Credentials: true nur fest, wenn dies für die spezifische ursprungsübergreifende Interaktion [S3] unbedingt erforderlich ist.
  • Verwenden Sie die richtige Validierung: Wenn Sie mehrere Ursprünge unterstützen müssen, stellen Sie sicher, dass die Validierungslogik für den Origin-Header robust ist und nicht von Subdomänen oder ähnlich aussehenden Domänen [S2] umgangen werden kann.

Wie FixVibe darauf testet

FixVibe beinhaltet dies jetzt als geschlossene aktive Prüfung. Nach der Domänenüberprüfung sendet active.cors API-Anfragen gleichen Ursprungs mit einem synthetischen Angreiferursprung und überprüft die CORS-Antwortheader. Es meldet reflektierte willkürliche Ursprünge, mit Wildcard-Anmeldeinformationen versehenes CORS und weit offenes CORS auf nicht öffentlichen API-Endpunkten und vermeidet gleichzeitig den Lärm öffentlicher Vermögenswerte.