HTTP Headers: Cross-Origin Resource Policy (CORP)
HTTP Headers: Cross-Origin Resource Policy (CORP)
Das Cross-Origin Resource Sharing erklärt
Cross-Origin Resource Policy (CORP) ist ein Sicherheitsfeature, das Websites ermöglicht, das Laden bestimmter Ressourcen von anderen Ursprüngen (Origins) zu verhindern.
Dieser Schutz ergänzt CORB, da er eine opt-in-Abwehr darstellt, während CORB standardmäßig einige Lesevorgänge über Ursprünge hinweg blockiert. CORP ist darauf ausgelegt, sowohl gegen spekulative Ausführungsangriffe als auch XS-Leaks zu schützen, indem es Entwicklern ermöglicht sicherzustellen, dass sensible Ressourcen nicht in Prozessen landen, die von Angreifern kontrolliert werden.
Im Gegensatz zu CORB wird dieser Schutz im Browser nur dann durchgesetzt, wenn eine Anwendung sich für den Schutz entscheidet. Anwendungen können definieren, welche Gruppen von Ursprüngen (’same-site‘, ’same-origin‘, ‚cross-site‘) berechtigt sind, ihre Ressourcen zu lesen.
Praktische Anwendung:
Webanwendungen setzen eine Cross-Origin-Ressourcenrichtlinie über den HTTP-Antwort-Header „Cross-Origin-Resource-Policy“ fest, der eine von drei Werten akzeptiert:
same-site
Nur Anfragen von derselben Website können die Ressource lesen.
same-origin
Nur Anfragen von derselben Herkunft (d.h. Schema + Host + Port) können die Ressource lesen.
cross-origin
Anfragen von jeder Herkunft (sowohl von derselben Website als auch von anderen Websites) können die Ressource lesen.
header('Cross-Origin-Resource-Policy: same-origin');
Starker und dringend empfohlener Schutz
Wenn eine Anwendung für eine bestimmte Ressource den CORP-Header als ’same-site‘ oder ’same-origin‘ setzt, ist es einem Angreifer nicht möglich, diese Ressource zu lesen. Dies ist ein sehr starker und dringend empfohlener Schutz.
Beim Einsatz von CORP sollten folgende Fakten beachtet werden:
CORP schützt nicht vor Navigationsanfragen. Das bedeutet, dass in Browsern, die keine Out-of-Process-iFrames unterstützen, eine durch CORP geschützte Ressource dennoch im Prozess einer anderen Herkunft landen kann, wenn keine Framing-Schutzmaßnahmen verwendet werden. Dies ist möglich, indem der X-Frame-Options-Header oder die CSP frame-ancestors-Richtlinie verwendet werden.
Eine weitere Situation, in der Webseiten trotz Same-Origin-Policy eingeschränkt miteinander interagieren können, sind Popups. Öffnet eine Seite ein Popup einer anderen Webseite, kann die öffnende Webseite auf das Seitenobjekt zugreifen. Damit kann beispielsweise das Popup nach einiger Zeit auf eine andere Webseite weitergeleitet werden.
Ähnliches funktioniert in die andere Richtung. Eine in einem Popup geöffnete Webseite kann mittels Javascript auf das Objekt window.opener zugreifen und den öffnenden Browsertab auf eine andere Webseite weiterleiten. Über diese Zugriffe auf das Fenster-Objekt sind Seitenkanalangriffe möglich, die als XSLeaks bekannt sind.
Solche Interaktionen zwischen öffnenden und geöffneten Fenstern hinweg werden nur selten benötigt. Mit dem Cross-Origin-Opener-Policy Wert same-origin
lässt sich dies unterbinden.
Rundum–Absicherung
Inhaltsicherheitsrichtlinie (CSP)
XSS-Absicherung
100% Geld-zurück-Garantie
Keine monatlichen Kosten
Wir schützen, was Ihnen wichtig ist.
Schlüsselfertige Absicherung:
Unsere Experten erledigen diese Aufgabe komplett für Sie.
Statt 289,- € jetzt zum Vorzugspreis von nur 149,- €