CORS und wie richtet man Access-Control-Allow-Origin sicher ein?

Was ist CORS?

Cross-Origin Resource Sharing (CORS) ist ein Header-basierter Mechanismus, der festlegt, wie Webbrowser und Server interagieren und die Sicherheit von ursprungsübergreifenden HTTP-Anfragen und Datenübertragungen bestimmen können. Der Ursprung umfasst in diesem Fall sowohl den Port, den Hostnamen als auch das mit einer Anfrage verbundene Schema. Je nach Konfiguration erlaubt oder verbietet CORS den Zugriff auf Ressourcen, die sich außerhalb der Domäne befinden, aus der die Ressourcen ursprünglich bereitgestellt wurden.

CORS ist eine Möglichkeit zur Lockerung der Same-Origin-Policy (SOP), um den kontrollierten Zugriff auf eine Website-Domäne von einer anderen aus über HTTP-Anfragen zu ermöglichen. Dieser kontrollierte Zugriff wird über HTTP-Header und die darin enthaltenen Anweisungen erreicht. Als Teil der CORS-Antwort kann ein Server einem Client auch mitteilen, ob Cookies oder Authentifizierungsdaten mit einer Anfrage gesendet werden können.

Die CORS-Richtlinie dient nicht als Schutz gegen ursprungsübergreifende Angriffe, sondern kann diese unter bestimmten Bedingungen sogar ermöglichen. Eine mangelhafte Einrichtung der gemeinsamen Ressourcennutzung kann sogar Cross-Site-Request-Forgery- (CSRF) und Cross-Site-Scripting- (XSS) Angriffe erleichtern, weshalb sie gut verstanden und sorgfältig implementiert werden muss.

Einer der in CORS verwendeten Protokoll-Header ist der Access-Control-Allow-Origin-Header. Dieser Header wird von Servern zurückgegeben, wenn eine ursprungsübergreifende Anfrage erlaubt ist, zusammen mit den Bedingungen, unter denen sie erlaubt ist.

CORS-Preflight-Anfrage-Szenario

Die CORS-Spezifikation bietet Browsern die Möglichkeit, über die OPTIONS-Methode eine „Preflight-Anfrage“ an einen Server zu stellen. 

Diese wird verwendet, um festzustellen, ob sie eine bestimmte domänenübergreifende Anfrage durchführen dürfen, insbesondere eine, die nicht standardisierte HTTP-Methoden oder Header enthält, die Daten verändern können. Die Preflight-Anfrage ist eine Sicherheitsmaßnahme, um Server vor der größeren Flexibilität zu schützen, die CORS bietet.

In diesem Szenario sendet der Browser mit der OPTIONS-Methode Header an den Server, die die Methoden und Header angeben, die er in der eigentlichen Anfrage zu verwenden beabsichtigt. Die Client-Anfrage wird ausgeführt, wenn die Methoden und Header vom Server in der Antwort zugelassen werden.

HTTP-Anfrage- und Antwort-Header

Unter CORS werden viele zusätzliche Header sowohl in der ursprungsübergreifenden Anfrage als auch in der Antwort verwendet, um den Austausch zu steuern. Dazu gehören:

HTTP-Client-Anfrage-Header:

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

HTTP-Server-Antwort-Header:

• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• Access-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers

Weitere Informationen über die verschiedenen Arten von Headern, die als Teil von CORS verwendet werden, finden Sie in Mozillas ausführlichem Artikel über Cross-Origin Resource Sharing (CORS).

Was ist Access-Control-Allow-Origin?

Wenn der Access-Control-Allow-Origin-Antwort-Header implementiert ist, wird er in die Antwort eines Servers (Domäne) an einen anderen Server aufgenommen, der die ursprungsübergreifende Anfrage stellt. Außerdem gibt er an, welcher Ursprung der Anfrage erlaubt ist. 

Der Client (Browser) vergleicht dann den Ursprung der Website, die den Zugriff anfordert, mit der in der Header-Antwort der Domäne, die die Ressource bereitstellt, angegebenen Ursprung, um festzustellen, ob sie übereinstimmen. Ist dies der Fall, wird die Anfrage bearbeitet und der Code der anfragenden Website kann auf die Antwort zugreifen. Wenn der Ursprung nicht in der Kopfzeile enthalten ist, gibt der Browser die Serverantwort nicht frei.

Grob gesagt, würde dies folgendermaßen aussehen:

1. Ursprung A (http://siteA.com) fordert den Zugriff auf Ressourcen von Ursprung B (http://siteB.com) an, z. B. durch einen Anfrage-Header und eine GET-Methode.
2. Der Server von Ursprung B antwortet und fügt in die Kopfzeile Access-Control-Allow-Origin: http://siteA.com ein.
3. Der Browser vergleicht die erlaubte Ursprung in der Kopfzeile mit der anfragenden Ursprung A, und wenn diese übereinstimmen, wird die Antwort geteilt.

Übergabe von Anmeldeinformationen bei ursprungsübergreifenden Ressourcenanfragen

Normalerweise werden Access-Control-Allow-Origin-Antworten an den anfragenden Ursprung ohne Anmeldeinformationen wie Cookies oder Autorisierungs-Header weitergeleitet, selbst wenn diese mit der Anfrage gesendet werden.

Die Verwendung von „Access-Control-Allow-Credentials: true“ zusammen mit Access-Control-Allow-Origin ermöglicht es jedoch, die eigentliche Anfrage zu stellen und die Antwort zu lesen. 

Access-Control-Allow-Origin Antwort-Header-Werte

Access-Control-Allow-Origin kann mehrere Werte haben. Dies sind der wildecard value (*), der Nullwert und specific origin values, die Sie zulassen möchten (d. h. Ursprünge, die auf der Whitelist stehen). 

Erlaubte Ursprünge müssen in einer Liste enthalten sein, anhand derer der Server Ursprungsanfragen prüft. Die Anfrage wird zugelassen, wenn die Domäne in der Liste enthalten ist. 

Der Wildcard-Wert bedeutet, dass Anfragen von jeder Domäne zulässig sind. Dieser Wert wird in der Regel verwendet und als sicher angesehen, wenn der Inhalt einer Domain als öffentlich und frei zugänglich angesehen wird. Mit anderen Worten, es ist der geeignete Wert für Anfragen ohne Anmeldeinformationen.

Dieser Wert lässt keine Anfragen mit Anmeldeinformationen zu – d. h. HTTP-Authentifizierung, Cookies und clientseitige Zertifikate – und kann nicht zusammen mit einem anderen Wert verwendet werden. Das Zulassen von „Access-Control-Allow-Credentials: true“ zusammen mit dem Platzhalter über einen Workaround kann sehr gefährlich sein, da dadurch Authentifizierungsinformationen an nicht vertrauenswürdige Parteien weitergegeben werden können.

Der Wert Null für den Ursprung (Access-Control-Allow-Origin: „null“) sollte von Servern nicht verwendet werden, da er eine Sicherheitslücke schaffen kann. Das Setzen des Ursprungs auf „null“ öffnet Angreifern Tür und Tor, um Anfragen zu generieren, die einen Nullwert im Ursprungs-Header enthalten. 

Wenn der Wert „null“ auf der Whitelist steht, ist die Aufnahme in den Header durch einen Angreifer erlaubt. Auf der Seite des Angreifers kann „null“ mit einer feindlichen Datei verbunden sein, die ihm Zugang zu den Ressourcen des Servers verschafft.

Unterstützt Access-Control-Allow-Origin mehrere Ursprünge?

Der Header unterstützt zwar mehrere Ursprünge, aber die Browser tun dies normalerweise nicht. 

Es muss eine Whitelist zulässiger Domänen erstellt werden, um die Unterstützung mehrerer Ursprünge zu ermöglichen. Dies muss jedoch mit Bedacht geschehen, da eine pauschale Zugriffsberechtigung für eine Domäne und alle ihre Unterdomänen leicht die Tür für unerwünschte Besucher und Anfragen öffnen kann.

So aktivieren Sie die Access-Control-Allow-Origin-Header

Um die Verwendung dieser Header zu aktivieren, müssen Sie zunächst die CORS-Unterstützung zu Ihrem Server hinzufügen. Auf der Website Enable CORS (CORS aktivieren) finden Sie eine ausführliche Beschreibung, wie Sie CORS für eine bestimmte Plattform implementieren. 

In dieser Ressource finden Sie alle Informationen, die Sie benötigen, um CORS und Access-Control-Allow-Origin-Header zu implementieren:

• Apache
• App Engine
• ASP.NET
• AWS API Gateway
• BFE
• Caddy
• CGI Scripts
• ColdFusion
• ExpressJS
• Flask
• IIS6
• IIS7
• Spring Boot Applications in Kotlin
• Meteor
• nginx
• Perl
• PHP
• Tomcat
• Virtuoso
• WCF

Weitere Informationen zu CORS und dessen Implementierung auf der Ebene des HTTP-Servers oder der Webanwendung finden Sie in der offiziellen W3C-Ressource CORS Enabled.

Präventionsguide

Ultimativer Präventionsguide – Gängiste Cyber Threats

Dieses große, ständig wachsende E-Book zeigt Best Practices und Präventionstechniken, um Schwachstellen zu vermeiden und Ihre Webanwendungen zu sichern.

Download

Sicherer Zugriff von Drittanbietern auf eine REST-API

Heutzutage ist es relativ einfach, Sicherheitsrichtlinien für Webanwendungen durchzusetzen, indem die richtigen Header in HTTP-Antworten verwendet werden. Nehmen Sie das folgende Beispiel einer Anwendung:

• https://example.org stellt seinen Nutzern das Frontend der großen Beispielanwendungen zur Verfügung. Dies ist die Domäne, die ein Benutzer kennt.
• https://api.example.org verwaltet alle Informationen. Wenn sich der Benutzer anmeldet, sendet das Frontend eine Anfrage an diese Domäne und ändert sich entsprechend der Antwort.

In diesem Fall sollte es niemand anderem als dem Frontend möglich sein, auf die API zuzugreifen. Mittlerweile versuchen die Browser, den Benutzer zu schützen und bösartige Anfragen zu blockieren. Eine solche Anfrage wäre zum Beispiel der Besuch von https://malicious.example.org, und die dortige Webanwendung würde versuchen, auf https://api.example.org zuzugreifen. Um dies zu verhindern, kann der Webserver, der die API bereitstellt, den Access-Control-Allow-Origin-Header wie folgt senden:

Access-Control-Allow-Origin: https://example.org

Auf diese Weise hat die bösartige Website keinen Zugang mehr zu unserer API, wenn der Benutzer einen aktuellen Browser verwendet.

Auf diese Weise kann die bösartige Website nicht mehr auf unsere API zugreifen, wenn der Benutzer einen neueren Browser verwendet.

Keine Sicherheits-Header gesetzt? Verwenden Sie sie besser bei der Entwicklung einer Webanwendung.

Wenn das Anwendungssetup komplexer wird, wird die Konfiguration viel komplizierter. Nehmen wir an, dass es mehrere Systeme gibt:

• https://staging.example.org, das die Staging-Umgebung des Frontends enthält.
• https://payment.example.org, der externe Zahlungsanbieter, der auf die API zugreifen muss, um Zahlungen zu bestätigen
• https://localhost:8080 ist der lokale Server, den der Entwickler verwendet, um Änderungen lokal auszuprobieren.

Der Access-Control-Allow-Origin-Header kann nicht mehrere Domänen enthalten, wie z. B. die Trennung verschiedener Domänen durch Leerzeichen oder Kommas. Neben der Angabe einer einzelnen Domäne ist nur „*“ eine weitere gültige Option, die den Zugriff von überall her erlauben würde. Und das ist in diesem Fall keine sichere Option.

Daher muss die API den Ursprung der Anfrage prüfen und das Header-Feld entsprechend anpassen. So kann sie beispielsweise die Kopfzeile „Origin“ der Anfrage verwenden, um zu prüfen, wer auf die Ressource zugreift. Wenn es sich um eine der zulässigen Domänen handelt, wird der Access-Control-Allow-Origin entsprechend eingestellt. Andernfalls wird er einfach auf https://example.org gesetzt, so dass der Browser die Anfrage blockiert. Das folgende Beispiel erklärt, wie ein Laravel-Projekt Middleware nutzen kann, um diesen Header korrekt zu setzen:

<?php

class CORSMiddleware
{
   [...]
   /**
    * Add Access Control headers.
    *
    * @param \Illuminate\Http\Request  $request
    * @param \Illuminate\Http\Response $response
    *
    * @return \Illuminate\Http\Response
    */
   protected function addAccessControlHeaders($request, $response)
   {
      $possibleOrigins = [
         'https://example.com',
         'https://api.example.com',
         'https://staging.example.com',
         'https://payment.example.org',
      ];

      if (env('APP_ENV') == 'development') {
         $possibleOrigins[] = 'https://localhost:8080';
      }

      if (in_array($request->header('origin'), $possibleOrigins)) {
         $origin = $request->header('origin');
      } else {
         $origin = 'https://example.com';
      }

      $headers = [
         'Access-Control-Allow-Origin'      => $origin,
         'Vary'                             => 'Origin',
      ];
      
      foreach ($headers as $header => $value) {
         $response->header($header, $value);
      }

      return $response;
   }
}

In diesem Fall sollte es für niemanden außer dem Frontend möglich sein, auf die API zuzugreifen. Mittlerweile versuchen die Browser, den Benutzer zu schützen und bösartige Anfragen zu blockieren. Eine solche Anfrage wäre zum Beispiel der Besuch von https://malicious.example.org, und die dortige Webanwendung würde versuchen, auf https://api.example.org zuzugreifen. Um dies zu verhindern, kann der Webserver, der die API bereitstellt, den Access-Control-Allow-Origin-Header wie folgt senden:

Zusätzlich zum Access-Control-Allow-Origin-Header wird der Vary-Header gesetzt, damit der Browser weiß, dass die Antwort dieser API je nach Ursprung variieren kann. Daher wird er keine zwischengespeicherte Antwort verwenden, wenn die API von einer anderen Frontend-Site im selben Browser aufgerufen wird.

Häufig gestellte Fragen

Was ist Access-Control-Allow-Origin?

Access-Control-Allow-Origin ist einer der HTTP-Header, die von CORS (Cross-Origin Resource Sharing) verwendet werden, um Anfragen zwischen Ursprüngen (Domänen) zu verwalten, z. B. clientseitige JavaScript-Anfragen.

Wann sollte Access-Control-Allow-Origin verwendet werden?

Ein Ursprung verwendet diesen Header in Fällen, in denen es sinnvoll ist, die Bereitstellung von Ressourcen für einen anderen Ursprung zu ermöglichen. Dazu können Domänen gehören, die ausschließlich öffentliche Informationen bereitstellen (z. B. Web-Schriftarten) und diese für andere Domänen zugänglich machen wollen, aber auch für Webanwendungen, die Daten austauschen (z. B. Zahlungsdienste).

Wie behandelt CORS nicht-einfache Anfragen?

Anfragen, die nicht einfache Verben (z. B. PUT oder DELETE) oder Anfrage-Header (z. B. benutzerdefinierte Header oder Cookies) enthalten, müssen zunächst eine Preflight-Anfrage unter COST durchlaufen. Dies liegt daran, dass der Browser zunächst eine OPTIONS-Anfrage an den Server sendet, und wenn der Server mit Headern antwortet, die nicht einfache Header oder Methoden erlauben, fährt der Browser mit der eigentlichen Anfrage fort.

Schützt CORS vor ursprungsübergreifenden Angriffen?

Nein, CORS befasst sich nicht mit Schwachstellen im Zusammenhang mit ursprungsübergreifenden Angriffen, wie CSRF und XSS. CORS befasst sich mit dem sicheren Umgang mit ursprungsübergreifenden Anfragen, und sein Zweck ist es, eine größere Freiheit und Funktionalität zu ermöglichen, als dies durch eine strenge Sicherheitsrichtlinie mit demselben Ursprung möglich ist. Eine schlechte CORS-Einrichtung kann jedoch Cross-Origin-Angriffe erleichtern.

Quellen:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Access-Control-Allow-Origin