Verwendung von Azure CDN mit CORS

Was ist CORS?

CORS (Cross Origin Resource Sharing; Ressourcenfreigabe zwischen verschiedenen Ursprüngen) ist eine HTTP-Funktion, die einer Webanwendung, die in einer Domäne ausgeführt wird, den Zugriff auf Ressourcen in einer anderen Domäne ermöglicht. Alle modernen Webbrowser eine Sicherheitseinschränkung, die als Same Origin Policybekannt ist, um die Möglichkeiten für Cross-Site Scripting-Angriffe zu verringern. Diese Einschränkung hindert eine Website daran, APIs in einer anderen Domäne aufzurufen. CORS bietet eine sichere Methode, um einem Ursprung (der Ursprungsdomäne) das Aufrufen von APIs in einem anderen Ursprung zu ermöglichen.

Funktionsweise

Es gibt zwei Arten von CORS-Anforderungen: einfache Anforderungen und komplexe Anforderungen.

Für einfache Anforderungen gilt Folgendes:

1. Der Browser sendet die CORS-Anforderung mit einem zusätzlichen HTTP-Anforderungsheader vom Typ Ursprung. Der Wert dieses Anforderungsheaders ist der Ursprung, der die übergeordneten Seite bereitgestellt hat. Dabei handelt es sich um eine Kombination aus Protokoll, Domäne und Port. Wenn eine Seite aus HTTPS://www.contoso.com versucht, auf die Benutzerdaten im Ursprung fabrikam.com zuzugreifen, wird der folgende Anforderungsheader an fabrikam.com gesendet:

   Origin: https://www.contoso.com

2. Der Server reagiert kann mit einem der folgenden Header reagieren:

   • Mit einem Access-Control-Allow-Origin-Header in der Antwort, der die zulässige Ursprungswebsites angibt. Beispiele:

     Access-Control-Allow-Origin: https://www.contoso.com

   • Mit einem HTTP-Fehlercode (z. B. 403), falls der Server die ursprungsübergreifende Anforderung nach der Überprüfung des Origin-Headers nicht zulässt.

   • Mit einem Access-Control-Allow-Origin-Header mit einem Platzhalter, der alle Ursprünge zulässt:

     Access-Control-Allow-Origin: *

Für komplexe Anforderungen gilt Folgendes:

Eine komplexe-Anforderung ist eine CORS-Anforderung, bei der der Browser vor dem Senden der eigentlichen CORS-Anforderung eine Preflight-Anforderung (also einen Vorabtest) senden muss. Die Preflight-Anforderung ist eine OPTIONS-Anforderung an die gleiche URL und fordert vom Server eine Berechtigung zum Ausführen der ursprünglichen CORS-Anforderung an.

Platzhalter oder Szenarien mit nur einem Ursprung

CORS für Azure CDN funktioniert automatisch ohne zusätzliche Konfiguration, wenn der Header Access-Control-Allow-Origin auf Platzhalter (*) oder einen einzelnen Ursprung festgelegt ist. Das CDN speichert die erste Antwort zwischen, und nachfolgende Anforderungen verwenden den gleichen Header.

Wenn Anforderungen schon an CDN gesendet wurden, bevor CORS auf den Ursprung konfiguriert wurde, müssen Sie den Inhalt im Inhalt Ihres Endgeräts entfernen, um den Inhalt mit dem Header Access-Control-Allow-Origin erneut zu laden.

Szenarien mit mehreren Ursprüngen

Wenn Sie eine bestimmte Liste von Ursprüngen für CORS zulassen müssen, wird es etwas komplizierter. Das Problem tritt auf, wenn CDN den Access-Control-Allow-Origin -Header für den ersten CORS-Ursprung zwischenspeichert. Bei einer Folgeanforderung durch einen anderen CORS-Ursprung stellt das CDN den zwischengespeicherten Access-Control-Allow-Origin-Header bereit, dieser stimmt jedoch nicht überein. Es gibt mehrere Möglichkeiten, dieses Problem zu korrigieren.

Azure CDN Standard-Profile

Unter Azure CDN Standard von Microsoft können Sie eine Regel in der Standardregel-Engine erstellen, um den Origin-Header (Ursprung) in der Anforderung zu überprüfen. Wenn es sich hierbei um einen gültigen Ursprung handelt, legt Ihre Regel den Access-Control-Allow-Origin-Header auf den gewünschten Wert fest. In diesem Fall wird der Access-Control-Allow-Origin-Header des Ursprungsservers der Datei ignoriert und die CDN-Regel-Engine verwaltet vollständig die zulässigen CORS-Ursprünge.

Azure CDN Premium von Edgio

Unter Verwendung der Edgio Premium-Regel-Engine müssen Sie eine Regel erstellen, um den Ursprungsheader in der Anforderung zu überprüfen. Wenn es sich hierbei um einen gültigen Ursprung handelt, legt Ihre Regel den Access-Control-Allow-Origin-Header mit dem in der Anforderung bereitgestellten Ursprung fest. Wenn der im Ursprungsheader angegebene Ursprung nicht zulässig ist, sollte Ihre Regel den Access-Control-Allow-Origin-Header auslassen, der den Browser dazu bringt, die Anforderung abzulehnen.

Es gibt zwei Möglichkeiten, dieses Problem mit der Premium-Regel-Engine zu lösen. In beiden Fällen wird der Access-Control-Allow-Origin-Header des Ursprungsservers der Datei ignoriert und die CDN-Regel-Engine verwaltet vollständig die zulässigen CORS-Ursprünge.

Ein regulärer Ausdruck mit allen gültigen Ursprüngen

In diesem Fall erstellen Sie einen regulären Ausdruck, der alle Ursprünge enthält, die Sie zulassen möchten:

https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$

Wenn der reguläre Ausdruck übereinstimmt, ersetzt Ihre Regel den Access-Control-Allow-Origin-Header (sofern vorhanden) des Ursprungs mit dem des Ursprungs, der die Anforderung gesendet hat. Sie können zusätzliche CORS-Header hinzufügen, wie z. B. Access-Control-Allow-Methods.

Anforderungsheader-Regel für jeden Ursprung

Statt reguläre Ausdrücke können Sie stattdessen eine separate Regel für jeden Ursprung erstellen, den sie zulassen möchten. Verwenden Sie dazu die Übereinstimmungsbedingung des Request Header-Platzhalters. Wie bei der Methode des regulären Ausdrucks legt die Regel-Engine allein die CORS-Header fest.