zurück zum Artikel

HTTP: Cross-Site-Zugriffe mit CORS gezielt steuern

|

Browser blockieren HTTP-Zugriffe von JavaScript-Code auf fremde Domains. Manchmal will man genau das aber zulassen. Mit CORS-Headern löst man diesen Konflikt.

Um zu verstehen, warum es nötig ist, Ressourcen auf Webservern per Cross-Origin-Resource-Sharing (CORS) freizugeben, muss man zunächst einen Blick auf den Umgang von Browsern mit Cookies und sogenannten CSRF-Angriffen werfen. Ursache der beschriebenen Probleme ist die Natur von HTTP – ein Protokoll, das ursprünglich dafür konzipiert war, statische Seiten in einem Wissenschaftsnetzwerk auszuliefern. Auf modernden Webseiten ist es aber üblich, dass man nicht nur Inhalte liest, sondern selbst Inhalte schreibt oder Aktionen in der realen Welt über den Browser auslöst.

Für solche Anwendungen ist es entscheidend, dass sich der Benutzer zunächst anmeldet, klassisch mit Benutzername und Kennwort. HTTP ist statuslos, die Verbindung wird also nach jeder Übertragung eines Datensatzes, HTML-Dokuments oder Bildes geschlossen. Folgende Aufrufe kann der Server keinen vorangegangenen zuordnen. Damit der Nutzer nicht bei jedem Aufruf einer Ressource sein Kennwort wieder eintippen muss, braucht man ein Verfahren, um angemeldete Nutzer wiederzuerkennen. Viele Webseiten arbeiten mit einer Technik, die alle Browser schon seit Jahrzehnten unterstützen: Bei der erfolgreichen Anmeldung schickt der Server per HTTP-Header eine Zeichenkette an den Browser, das sogenannte Cookie. Der Header enthält zusätzlich die Information, für welche Domain dieses Cookie bestimmt ist und wie lange es gültig sein soll.

Der Browser verwahrt das Cookie bis zum Ablauf der angegebenen Zeit in seinem Speicher und sendet es vollautomatisch immer dann im Header mit, wenn er einen HTTP-Aufruf an die dazugehörige Domain machen soll. Anhand der Zeichenkette des Cookies kann der Server erkennen, dass es sich um die angemeldete Sitzung eines Nutzers handelt.


URL dieses Artikels:
https://www.heise.de/-4789769