Zum Inhalt springen
EUID Prüfservice & Prüfsiegel, Startseite
Website prüfen lassen

Prüfpunkt software.cors.spiegelungKopfzeilen und Einbettung

Welche fremden Websites dürfen Antworten Ihres Servers lesen?

Ein Browser lässt eine Seite normalerweise nur Antworten ihrer eigenen Website lesen. Mit CORS, Cross-Origin Resource Sharing, kann ein Server anderen Websites erlauben, seine Antworten zu lesen, etwa der eigenen App unter einer anderen Domain. Die Prüfung schickt eine Anfrage mit einer erfundenen fremden Herkunft und meldet, wenn der Server genau diese Herkunft freigibt und dabei die Anmeldung des Besuchers mitschicken lässt.

CORS lockert eine Sperre des Browsers

Skripte im Browser dürfen normalerweise nur Antworten der Herkunft lesen, von der die Seite stammt. Diese Regel heißt Same-Origin-Policy. Sie verhindert, dass eine fremde Seite mitliest, was Ihr Kunde in seinem Konto sieht. CORS ist die Ausnahme davon: Der Server nennt, wer trotzdem lesen darf. Jede Freigabe öffnet also ein Stück dieser Sperre. Das Sicherheitsunternehmen PortSwigger betont: CORS regelt das Verhalten von Browsern und ersetzt nie Anmeldung und Sitzungsverwaltung am Server.

Die Kopfzeile nennt nur eine Herkunft, daraus entsteht der Fehler

Access-Control-Allow-Origin nimmt genau eine Herkunft an und kennt keinen Platzhalter für Subdomains. Wer mehrere eigene Domains bedient, lässt den Server die Zeile deshalb je Anfrage erzeugen. Fehlt dabei der Abgleich mit einer Liste, ist jede Herkunft frei. James Kettle von PortSwigger nannte das 2016 die häufigste CORS-Schwachstelle; eine Bitcoin-Börse schloss sie nach seiner Meldung binnen 20 Minuten. Liest eine fremde Seite auf diesem Weg Kundendaten aus, verlangt Artikel 33 der DSGVO bei einem Risiko für die Betroffenen die Meldung an die Aufsichtsbehörde, möglichst binnen 72 Stunden.

Eine Liste hilft nur, wenn sie genau vergleicht

Prüft der Code nur, ob eine Herkunft auf ihre-domain.at endet, passt auch eine fremde Domain wie andere-ihre-domain.at. Die Herkunft null gehört nie auf die Liste, denn Anfragen lassen sich so erzeugen, dass sie null melden. Jede Freigabe ist außerdem Vertrauen: Läuft auf einer freigegebenen Subdomain ein eingeschleustes Skript, liest es mit denselben Rechten wie Ihre App.

Gespiegelte Herkunft mit Anmeldung öffnet das Konto

Antwortet ein Server auf jede Herkunft mit Access-Control-Allow-Origin: genau diese Herkunft und dazu Access-Control-Allow-Credentials: true, darf jede beliebige Website im Browser Ihres Besuchers Anfragen an Ihren Server schicken und die Antworten lesen, mit seinen Cookies. Besucht ein angemeldeter Kunde eine fremde Seite, kann diese im Hintergrund seine Daten bei Ihnen abrufen: Kontoangaben, Bestellungen, alles, was die Schnittstelle liefert. Das passiert meist, wenn eine Einstellung die Herkunft der Anfrage einfach zurückschreibt, weil das bequemer ist als eine Liste.

Gemessen werden Startseite und bis zu zwei Schnittstellen

Die Prüfung ruft Ihre Startseite und bis zu zwei Adressen unter /api/ ab, die im Quelltext der Startseite stehen. Jede Anfrage enthält die Kopfzeile Origin mit der erfundenen Herkunft https://attacker.invalid. Antwortet der Server mit Access-Control-Allow-Origin: https://attacker.invalid und Access-Control-Allow-Credentials: true, nennt der Bericht die Adresse. Einen zweiten, leichten Befund gibt es für den Stern zusammen mit Anmeldung: Access-Control-Allow-Origin: * und Access-Control-Allow-Credentials: true in der Antwort einer gemessenen Seite oder einer dort verlinkten JSON-Datei. Die Prüfung schickt keine echten Anmeldedaten mit.

Eine feste Liste erlaubter Herkünfte

Ihre Agentur ersetzt das Zurückschreiben durch eine feste Liste: nur die eigenen Domains und Apps, die tatsächlich Antworten lesen müssen, bekommen die Freigabe, jede andere Herkunft bekommt keine. Access-Control-Allow-Credentials: true steht nur, wo eine solche Anwendung mit Anmeldung arbeitet. Öffentliche Daten ohne Anmeldung brauchen die Anmeldung nicht und können mit Stern freigegeben werden. Zur Antwort gehört Vary: Origin, damit Zwischenspeicher die Freigabe nicht an die falsche Herkunft geben.

Beispiele

Antwort auf eine Anfrage von fremder Herkunft

Nicht erfüllt
Access-Control-Allow-Origin: https://attacker.invalid
Access-Control-Allow-Credentials: true
Erfüllt
Access-Control-Allow-Origin: https://app.ihre-domain.at
Access-Control-Allow-Credentials: true
Vary: Origin

Die Freigabe nennt nur Herkünfte aus der eigenen Liste. Eine Anfrage von anderswo bekommt keine Access-Control-Allow-Origin-Zeile.

So gehen Sie es an

  1. Lassen Sie Ihre Agentur die Adresse aus dem Bericht ansehen: welche Einstellung schreibt die Herkunft zurück?
  2. Sie legt eine feste Liste der Herkünfte an, die Antworten lesen dürfen, und gibt nur diesen die Freigabe.
  3. Access-Control-Allow-Credentials: true bleibt nur, wo eine eigene Anwendung mit Anmeldung es braucht.
  4. Prüfen Sie danach eigene Apps und eingebundene Anwendungen einmal von Hand.
  5. Lassen Sie die Website neu messen. Der Bericht zeigt, ob der Server eine fremde Herkunft noch freigibt.

Tipps aus der Praxis

  • Streichen Sie Test- und Vorschau-Domains von der Liste, sobald ein Projekt abgeschlossen ist. Ein vergessenes Testsystem behält sonst dasselbe Leserecht wie Ihre App.
  • Setzen Sie das Sitzungscookie auf SameSite=Lax oder Strict. Dann schicken Browser es bei Anfragen fremder Seiten in der Regel nicht mit.
  • Lassen Sie alle Schnittstellen mit Kontodaten durchgehen, auch solche, die der Bericht nicht nennt. Die Einstellung kann an einer Stelle stehen und für alle gelten.

Mehr zu diesem Thema

Weiter in der Cybersicherheit

Dieser Prüfpunkt gehört zur Cybersicherheit, Unterthema Kopfzeilen und Einbettung. Gemessen wird er im Prüfbereich Aktualität. Was die Prüfung insgesamt leistet, zeigt die Leistungsseite; wie ein Ergebnis zustande kommt, erklärt das Prüfverfahren.

  • Siegel Digitale Barrierefreiheit
  • Siegel Daten & Recht
  • Siegel Technische Qualität
  • Siegel Digital Excellence
  • Siegel Cyberversicherung

Geprüft. Für eine bessere digitale Zukunft.euid.com