Was ist CORS?

In der Vergangenheit, als Internet-Technologien noch neu waren, traten Probleme mit Cross-Site Request Forgery (CSRF) auf. Durch diese Probleme wurden gefälschte Client-Anfragen vom Browser des Opfers an eine andere Anwendung gesendet.

Zum Beispiel hat sich das Opfer bei der Anwendung seiner Bank angemeldet. Dann wurden sie dazu verleitet, eine externe Website auf einem neuen Browser-Tab zu laden. Die externe Website verwendete dann die Cookie-Anmeldeinformationen des Opfers und leitete Daten an die Bankanwendung weiter, während sie vorgab, das Opfer zu sein. Unbefugte Benutzer hatten dann unbeabsichtigten Zugriff auf die Bankanwendung.

Um solche CSRF-Probleme zu vermeiden, implementieren jetzt alle Browser die Gleiche-Herkunft-Richtlinie.

Gleiche-Herkunft-Richtlinie

Heutzutage verlangen Browser, dass Clients nur Anfragen an eine Ressource senden können, die denselben Ursprung wie die URL des Clients hat. Das Protokoll, der Port und der Hostname der URL des Clients sollten alle mit dem Server übereinstimmen, den er anfordert.

Stellen Sie sich zum Beispiel den Ursprungsvergleich für die folgenden URLs mit der Client-URL http://store.aws.com/dir/page.html vor.

URL	Ergebnis	Grund
http://store.aws.com/dir2/new.html	Gleicher Ursprung	Nur der Weg unterscheidet sich
http://store.aws.com/dir/inner/other.html	Gleicher Ursprung	Nur der Weg unterscheidet sich
https://store.aws.com/page.html	Anderer Ursprung	Anderes Protokoll
http://store.aws.com:81/dir/page.html	Anderer Ursprung	Anderer Port (http:// ist standardmäßig Port 80)
http://news.aws.com/dir/page.html	Anderer Ursprung	Anderer Host

Die Gleiche-Herkunft-Richtlinie ist also hochsicher, aber für echte Anwendungsfälle unflexibel.

Cross-Origin Resource Sharing (CORS) ist eine Erweiterung der Gleiche-Herkunft-Richlinie. Sie benötigen es für die autorisierte gemeinsame Nutzung von Ressourcen mit externen Dritten. Beispielsweise benötigen Sie CORS, wenn Sie Daten von externen APIs abrufen möchten, die öffentlich oder autorisiert sind. Sie benötigen CORS auch, wenn Sie autorisierten Drittanbietern den Zugriff auf Ihre eigenen Serverressourcen gewähren möchten.

In HTTP sind Anfragemethoden die Datenoperationen, die der Client vom Server ausführen lassen möchte. Zu den gängigen HTTP-Methoden gehören GET, POST, PUT und DELETE.

Bei einer regulären Interaktion der ursprungsübergreifenden gemeinsamen Nutzung von Ressourcen (CORS) sendet der Browser die Anfrage und die Zugriffskontroll-Header gleichzeitig. In der Regel handelt es sich dabei um GET-Datenanfragen, die als risikoarm gelten.

Einige HTTP-Anfragen werden jedoch als komplex angesehen und erfordern eine Serverbestätigung, bevor die eigentliche Anfrage gesendet wird. Der Vorabgenehmigungsprozess wird als Preflight-Anfrage bezeichnet.

Komplexe ursprungsübergreifende Anfragen

Ursprungsübergreifende Anfragen sind komplex, wenn sie eines der folgenden Elemente verwenden:

• Andere Methoden als GET, POST oder HEAD
• Andere Header als Accept-Language, Accept oder Content-Language
• Content-Type-Header außer multipart/form-data, application/x-www-form-urlencoded oder text/plain

So werden beispielsweise Anfragen zum Löschen oder Ändern vorhandener Daten als komplex angesehen.

So funktionieren Preflight-Anfragen

Browser erstellen Preflight-Anfragen, falls sie benötigt werden. Es ist eine OPTIONS-Anfrage wie die folgende.

OPTIONS /data HTTP/1.1 Herkunft: https://example.com Access-Control-Request-Method: DELETE

Der Browser sendet die Preflight-Anfrage vor der eigentlichen Anforderungsnachricht. Der Server muss auf die Preflight-Anfrage mit Informationen über die ursprungsübergreifenden Anfragen antworten, die der Server von der Client-URL annehmen möchte. Die Server-Antwort-Header müssen Folgendes enthalten:

• Methoden zur Zugriffskontrolle und zum Erlauben
• Access-Control-Allow-Header
• Access-Control-Allow-Origin

Ein Beispiel für eine Serverantwort finden Sie unten.

HTTP/1.1 200 OK Access-Control-Allow-Header: Inhaltstyp Access-Control-Allow-Origin: https://news.example.com Methoden zur Zugriffskontrolle und Erlauben: GET, DELETE, HEAD, OPTIONS

Die Preflight-Antwort enthält manchmal einen zusätzlichen Access-Control-Max-Age-Header. Diese Metrik gibt die Dauer (in Sekunden) an, die der Browser benötigt, um Preflight-Ergebnisse im Browser zwischenzuspeichern. Caching ermöglicht es dem Browser, mehrere komplexe Anforderungen zwischen Preflight-Anfragen zu senden. Es muss keine weitere Preflight-Anfrage gesendet werden, bis die durch das maximale Alter angegebene Zeit abgelaufen ist.

 

Folgendes sollten Sie beachten, wenn Sie ursprungsübergreifende gemeinsame Nutzung von Ressourcen (CORS) auf Ihrem Server konfigurieren.

Definieren Sie entsprechende Zugriffslisten

Es ist immer am besten, Zugriff auf einzelne Domänen mithilfe von kommagetrennten Listen zu gewähren. Vermeiden Sie die Verwendung von Platzhaltern, es sei denn, Sie möchten die API öffentlich machen. Andernfalls kann die Verwendung von Platzhaltern und regulären Ausdrücken zu Sicherheitslücken führen.

Angenommen, Sie schreiben einen regulären Ausdruck, der Zugriff auf alle Websites mit dem Suffix permitted-website.com gewährt. Mit einem Ausdruck gewähren Sie Zugriff auf api.permitted-website.com und news.permitted-website.com. Sie gewähren aber auch versehentlich Zugriff auf nicht autorisierte Websites, die möglicherweise Domänen wie maliciouspermitted-website.com verwenden.

Vermeiden Sie die Verwendung von Null-Ursprung in Ihrer Liste

Einige Browser senden den Wert Null im Anfrage-Header für bestimmte Szenarien wie Dateianfragen oder Anfragen vom lokalen Host.

Sie sollten den Nullwert jedoch nicht in Ihre Zugriffsliste aufnehmen. Es birgt auch Sicherheitsrisiken, da unbefugte Anfragen, die Null-Header enthalten, Zugriff erhalten können.