HTTP CORS

Heute ist es selbstverständlich, dass beim Aufruf einer Webseite alle darin enthaltenen Ressourcen wie Bilder oder Videos unmittelbar angezeigt werden. Oftmals ist es jedoch so, dass diese Ressourcen von einer anderen Quelle stammen. Viele Bild- und vor allem auch Videodaten stammen meist von fremden Anbietern oder aus sogenannten CDN’s (Content Delivery Netwoks). Prominenteste Beispiele hierfür sind sicherlich Bildlieferdienste wie Adobe Stock oder YouTube für Videoquellen oder Serviceanbieter wie Google oder Amazon, die Fonts oder Skripte liefern. Moderne Browser beispielsweise halten sich bezüglich fremder Ressourcen jedoch an eine übergreifende Vorschrift bzw. Beschränkung mit dem Bezeichner SOP (Same Origin Policy = Freigabe nur aus eigener Quelle).

Dies bedeutet, dass ein Browser in Webseiten enthaltene Ressourcen nur von dem gleichen Ursprung wie die Webseite selbst nachladen darf. Diesen Effekt sieht man häufig, wenn in einer aufgerufenen Webseite anstelle von Bild- oder Videoressourcen vorerst nur Platzhalter erscheinen. Mit HTTP-CORS (Cross Origin Ressource Sharing = Ressourcen aus plattformübergreifenden Quellen) kann diese Beschränkung jedoch selektiv aufgehoben werden. Durch eine gezielte Definition von CORS kann einem Client mitgeteilt werden, für welche Ressourcen-Fremdzugriffe erlaubt werden sollen.

Alle Ressourceneinschränkungen, die durch eine grundlegende SOP auferlegt sind, können das Nachladen von beispielsweise Bildern, Videos, Schriftarten und Skripte verhindern. SOP definiert hier nur den Einsatz von Ressourcen aus der eigenen Quelle der aufgerufenen Domain. Die Zusammenhänge werden im folgenden fiktiven Beispiel etwas genauer dargestellt:

Sie rufen in einem Browser eine Webseite wie folgt auf:

Nun versucht diese Webseite, weitere Ressourcen wie das Favorit-Icon und Formatanweisungen aus den folgenden beispielhaften Quellen nachzuladen:

Ihr Browser wird das Nachladen dieser beiden Ressourcen zulassen, da es den SOP-Bestimmungen folgt und die Ressourcen aus der eigenen Quelle stammen.

Nun versucht die Webseite beispielsweise, aus einem CDN-Netzwerk mehrere Abbildungen wie folgt nachzuladen:

Ihr Browser wird ohne weitere Bestimmungen das Laden der Bilder verhindern, da diese aus einer anderen Quell-Adresse als Ihre Webseite stammen.

Das essentielle Sicherheitskonzept von SOP verhindert somit aktiv, dass eine Webseite schadhafte Ressourcen oder schädigende Skripts von sich aus nachlädt bzw. in den Browser einschleust. Ohne SOP könnte ein Schadcode beispielsweise unbegrenzt auf alle Sitzungsdaten in einem Browser zugreifen. Mit HTTP CORS kann diese Sicherung gezielt gesteuert und für erlaubte Ressourcen geöffnet werden.

In dem vorhergehenden Beispiel konnte die Webseite das Nachladen von Bilddateien aufgrund der existierenden SOP nicht durchführen. Mit einer entsprechenden Anweisung kann dem Browser das Nachladen jedoch explizit ermöglicht werden. Hierfür muss CORS für ein oder auch mehrere Ziele definiert werden, von deren die Ressourcen nachgeladen werden sollen. Dazu fragt der Browser das Ziel, ob eine Cross-Origin-Request erlaubt werden soll. Dies wird in der Regel entweder über einen speziell parametrisierten HTTP-Header oder über einen separaten Request gesteuert.

Im Folgenden stellen wir Ihnen einen exemplarischen Request-/Response-Header für eine sogenannte einfache Ressourcenanfrage vor:

In dieser Serveranfrage wird mit dem wichtigsten Parameter „Origin“ festgelegt, von welcher Quelle (Domäne) der Aufruf stattfindet. Der Server kann hierauf nun entsprechend antworten und eine SOP-Freigabe ermöglichen. Dieser Response-Header führt dann eine entsprechende Anweisung wie folgt mit sich:

In der Response legt der hierbei wichtigste Parameter „access-control-allow-origin“ die erteilten Freigaben fest. Der Stern * bedeutet in diesem Fall eine generelle und standortübergreifende Freigabe auf die Ressource für alle Domains. Gerade mit diesem Parameter sollte man also vorsichtig umgehen. Idealerweise setzt man hier gezielt die erforderlichen Domains ein.

Neben der einfachen Ressourcenanfrage erlaubt CORS aber noch sogenannte „Preflight-Request“ für komplexere Anfragen. Ein solcher Preflight-Request wird mit einem CORS-Header vorab an das Ziel gesendet. Mit diesem zusätzlichen Request wird identifiziert, ob ein geplanter CORS erlaubt werden darf oder nicht. Der entsprechend ausgelegte CORS-Header wird hierbei über die http-Methode Options gesendet. Detailliertere Informationen zu den umfangreichen Möglichkeiten der Preflight-Requests finden Sie unter: https://developer.mozilla.org/de/docs/Web/HTTP/CORS

Das Thema Sicherheit im Netzwerk steht nach wie vor an erster Stelle. Neben den menschlichen Faktoren stehen im Bereich der Netzwerktechnik ebenso wichtige Aspekte und Verfahren zur Verfügung, um eine sichere Übertragung von Inhalten und Daten zwischen Server und Clients sicherstellen zu können. Mit der SOP-Direktive ist bereits ein erster Schritt unternommen worden. Um Ressourcen in einer gesicherten Browserumgebung plattformübergreifend anbieten und verwenden zu können, sollte auf HTTP-CORS zurückgegriffen werden. Hiermit kann man sehr detailliert die Zugriffe auf fremde Ressourcen und Domains einstellen und zulassen.

Ein wichtiger Aspekt zu CORS ist jedoch der richtige Umgang mit den Freigabemöglichkeiten. Allzu schnell wird eine zu wenig restriktive Vorgabe erteilt und öffnet damit Schadprogrammen und Datendiebstahl Tür und Tor. Gezielte Freigaben, strikte Prüfung von beispielsweise REST-API‘s und vor allem auch weitreichende PEN-Tests sollten vor der Freigabe sorgfältig überprüft werden. Eine grundsätzliche Empfehlung wäre auch CORS nur dann zu implementieren, wenn auf fremde Ressourcen und Quellen aus verschiedenen Gründen zugegriffen werden muss. Dann allerdings steht eine strikte Sorgfalt bei der Implementierung an erster Stelle.