Ich habe gelernt, die Same-Origin Policy zu lieben

Ich habe einen guten Teil meiner Arbeitszeit in diesem Jahr damit verbracht, (in Zusammenarbeit mit dem erstaunlichen Noam Rosenthal) eine neue Webplattformfunktion zu standardisieren: eine Möglichkeit, die intrinsische Größe und Auflösung von Bildern zu ändern. Und siehe da! Wir haben es geschafft! Aber das war wirklich eine Lernerfahrung.

Dies war nicht mein erstes Standardisierungs-Rodeo, daher habe ich viele der Probleme, auf die wir gestoßen sind, mehr oder weniger antizipiert. Stark negatives Feedback von Browsern. Seltsame, unvorhergesehene Fallstricke mit den zugrunde liegenden Primärfunktionen. Ein vollständiges Umdenken oder zwei. Was ich jedoch nicht erwartet hatte, war, dass unser Vorschlag – der, wie gesagt, „nur“ die Änderung der Standardanzeigegröße von Bildern betraf – mit den grundlegenden Datenschutz- und Sicherheitsprinzipien des Webs kollidieren würde. Denn vor diesem Jahr habe ich diese Prinzipien nicht wirklich verstanden.

Lassen Sie mich die Bühne etwas bereiten. Was wollten wir tun?

Standardmäßig werden Bilder im Web genau so groß angezeigt, wie sie sind. Ein 800 × 600 Bild einbetten? Es sei denn, Sie dehnen oder schrumpfen dieses Bild mit CSS oder Markup, so groß wird es sein: 800 CSS-Pixel breit und 600 CSS-Pixel hoch. Das ist die intrinsische (auch „natürliche“) Größe des Bildes. Anders ausgedrückt: Standardmäßig haben alle Bilder im Web eine intrinsische Dichte von 1×.

Das ist alles gut und schön, bis Sie versuchen, hoch-, niedrig-- oder ✨variabel✨-dichte Bilder zu liefern, ohne Zugriff auf CSS oder HTML. Das ist eine Situation, in der sich Bild-Hosts wie mein Arbeitgeber, Cloudinary, ziemlich oft wiederfinden.

Also machten wir uns daran, uns selbst und dem Rest des Webs ein Werkzeug zur Verfügung zu stellen, um die intrinsische Größe und Auflösung von Bildern zu ändern. Nach ein paar Umdenkphasen war die Lösung, zu der wir gelangten, diese:

1. Browser sollten Metadaten lesen und anwenden, die in den Bildressourcen selbst enthalten sind, und ihnen erlauben, ihre eigene beabsichtigte Anzeigegröße und Auflösung anzugeben.
2. Nach den jüngsten Schritten von image-orientation würden Browser standardmäßig diese Metadaten respektieren und anwenden. Aber man könnte sie mit etwas CSS (image-resolution) oder Markup (srcset’s x deskriptoren) überschreiben oder deaktivieren.

Das fanden wir ziemlich gut. Es war flexibel, baute auf einem bestehenden Muster auf und schien alle Bedenken zu adressieren, die gegen unsere früheren Vorschläge erhoben worden waren. Leider sagte einer der Herausgeber der HTML-Spezifikation, Anne van Kesteren: Nein. Das würde nicht funktionieren. Und auch image-orientation brauchte dringend ein Umdenken. Denn dieses Muster, bei dem man die Auswirkungen von EXIF-Metadaten mit CSS und HTML ein- und ausschalten kann, würde die „Same-Origin Policy“ verletzen.

Äh… was?

Skalieren und drehen wir nicht nur Bilder??

Geständniszeit! Vor all dem hatte ich die Same-Origin Policy mehr oder weniger mit CORS-Fehlern und all der Frustration gleichgesetzt, die sie mir über die Jahre verursacht hat. Jetzt stand die Same-Origin Policy nicht nur zwischen mir und der Behandlung eines fetch, sondern sie blockierte eine wichtige Arbeitsinitiative. Und ich musste die Situation gegenüber Chefs erklären, die noch weniger über Sicherheit und Datenschutz im Web wussten als ich. Zeit zu lernen!

Hier ist, was ich gelernt habe

• Die Same-Origin Policy ist keine einzige, einfache Regel. Und sie ist sicherlich nicht == CORS-Fehler.
• Sie ist vielmehr eine Philosophie, die sich im Laufe der Zeit entwickelt hat und inkonsistent über die Webplattform hinweg implementiert wurde.
• Im Allgemeinen besagt sie: Die grundlegende Sicherheits- und Datenschranke des Webs sind Ursprünge. Teilen Sie einen Ursprung mit etwas anderem im Web? Sie können damit interagieren, wie Sie möchten. Wenn nicht, müssen Sie aber möglicherweise einige Hürden überwinden.
• Warum „vielleicht“? Nun, viele Cross-Origin-Interaktionen sind standardmäßig erlaubt! Im Allgemeinen können Sie beim Erstellen einer Website über Ursprünge hinweg schreiben (indem Sie POST-Anfragen über Formulare an beliebige Adressen senden). Und Sie können sogar Cross-Origin-Ressourcen einbetten (Iframes, Bilder, Schriftarten usw.), die die Besucher Ihrer Website sehen, direkt auf Ihrer Website. Was Sie jedoch nicht tun können, ist, diese Cross-Origin-Ressourcen selbst anzusehen. Sie sollten nicht in der Lage sein, etwas über eine Cross-Origin-Ressource in Ihrem JavaScript zu lesen, ohne speziell erteilte Erlaubnis (über unseren alten Freund CORS).
• Das hat mich am meisten umgehauen, als ich es endlich verstanden habe: Cross-Origin-Lesevorgänge sind standardmäßig verboten, weil wir als Endnutzer alle unterschiedliche weltweite Netze sehen, und eine Website sollte nicht in der Lage sein, den Rest des Webs durch die Augen ihrer Besucher zu sehen. Die unterschiedlichen lokalen Browsing-Kontexte der einzelnen Benutzer – einschließlich, aber nicht beschränkt auf Cookies – bedeuten, dass ich, wenn ich zum Beispiel gmail.com aufrufe, etwas anderes sehe als Sie, wenn Sie dieselbe URL in Ihre Adressleiste eingeben und auf „Enter“ klicken. Wenn andere Websites von meinem Browser aus mit meinen Cookies Anfragen an Gmail senden und die Ergebnisse lesen könnten, nun – das wäre sehr, sehr schlimm!

Also standardmäßig: Sie können viele Dinge mit Cross-Origin-Ressourcen tun. Aber das Verhindern von Cross-Origin-Lesevorgängen ist quasi das A und O. Diese Standardeinstellungen sind mehr oder weniger das, worüber Leute sprechen, wenn sie über die „Same-Origin Policy“ reden.

Wie hängt das alles mit der intrinsischen Größe und Auflösung von Bildern zusammen?

Nehmen wir an, es gibt eine Bild-URL – https://coolbank.com/hero.jpg, die zufällig eine andere Ressource zurückgibt, je nachdem, ob ein Benutzer bei coolbank.com angemeldet ist oder nicht. Und nehmen wir an, die Version, die angezeigt wird, wenn Sie angemeldet sind, enthält EXIF-Auflösungsinformationen, aber die Version, die angezeigt wird, wenn Sie nicht angemeldet sind, nicht. Zuletzt tun wir so, als wäre ich ein böser Phisher, der herausfinden will, zu welcher Bank Sie gehören, damit ich ihre Homepage fälschen und Sie dazu verleiten kann, Ihre Bank-Login-Daten in mein böses Formular einzugeben.

Also! Ich bette https://coolbank.com/hero.jpg auf einer bösen Seite ein. Ich überprüfe ihre intrinsische Größe. Ich deaktiviere die EXIF-Größenanpassung mit image-resolution: none und prüfe dann erneut ihre Größe. Auch wenn CORS-Beschränkungen mich daran hindern, Bilddaten anzusehen, weiß ich, ob sie EXIF-Auflösungsinformationen enthält oder nicht – ich konnte ein winziges Stück dieses Bildes über Ursprünge hinweg lesen. Und jetzt weiß ich, ob Sie bei coolbank.com angemeldet sind und ein Konto dort haben.

Weit hergeholt? Vielleicht! Aber das Web ist ein unvorstellbar großer Ort. Und, wie Jen Simmons einmal sagte,

Das ist eines der besten & wichtigsten Dinge am WEB. Gehen Sie zu einer Website, sie ist sicher vor Malware. Laden Sie eine App herunter, Sie sind in Gefahr. Sie können keine zufälligen Apps von zufälligen Orten herunterladen. Sie können zufällige Websites besuchen und erwarten, sicher zu sein. Wir müssen kämpfen, damit das Web so bleibt. https://#/xKQ5vVNCaU

— Jen Simmons (@jensimmons) 11. März 2020

Das Surfen im Web bedeutet im Grunde, den ganzen Tag lang den unverlässlichen und potenziell bösartigen Code anderer Leute wissentlich und willentlich auszuführen. Die Prinzipien, die der Websicherheit und dem Datenschutz zugrunde liegen – einschließlich der Same-Origin Policy – ermöglichen diese Sicherheit und müssen unbedingt verteidigt werden. Das Loch, das wir unbeabsichtigt in die Same-Origin Policy zu schlagen versuchten, erschien zunächst so klein. Ein paar buchstäbliche Bits scheinbar harmloser Informationen. Aber ein Cross-Origin-Lesevorgang, egal wie klein, ist ein Cross-Origin-Lesevorgang, und Cross-Origin-Lesevorgänge sind nicht erlaubt.

Wie haben wir unsere Spezifikation korrigiert? Wir haben EXIF-Auflösungs- und Orientierungsinformationen über Ursprünge hinweg unlesbar gemacht, indem wir sie nicht deaktivierbar gemacht haben: In Cross-Origin-Kontexten werden EXIF-Änderungen immer angewendet. Ein 800 × 600 Bild, dessen EXIF besagt, dass es als 400 × 300 behandelt werden soll, wird sich unabhängig davon genau wie ein 400 × 300 Bild verhalten. Eine eigentlich einfache Lösung – sobald wir das Problem verstanden hatten.

Als Bonus hat sich, sobald ich die Same-Origin Policy und die Gründe für die Standard-Sicherheitsrichtlinien des Webs wirklich verstanden hatte, eine Reihe anderer Web-Sicherheitskomponenten für mich ergeben.

Cross-Site Request Forgery (CSRF)-Angriffe nutzen die Tatsache aus, dass Cross-Origin-Schreibvorgänge standardmäßig erlaubt sind. Wenn ein API-Endpunkt nicht vorsichtig mit der Beantwortung von POST-Anfragen umgeht, können schlimme Dinge passieren. Ebenso erlaubt Content Security Policy (CSP) eine granulare Kontrolle darüber, welche Arten von Einbettungen erlaubt sind, denn auch diese sind standardmäßig alle erlaubt, und das öffnet bekanntermaßen die Tür für Cross-Site Scripting (XSS)-Angriffe. Und die neue Buchstabensuppe an Web-Sicherheitsfunktionen – COOP, COEP, CORP und CORB – dienen alle dazu, Cross-Origin-Interaktionen vollständig zu unterbinden, einige der inkonsistenten Implementierungen der Same-Origin Policy im Laufe der Jahre zu korrigieren und jegliche/alle möglichen Cross-Origin-Interaktionen zu schließen, um einen schwer erreichbaren Zustand zu erreichen, der als „Cross-Origin Isolation“ bekannt ist. In einer Welt, in der Spectre und Co. bedeuten, dass Cross-Origin-Laden ausgenutzt werden kann, um Cross-Origin-Lesevorgänge durchzuführen, ist vollständige Cross-Origin-Isolation erforderlich, um Sicherheit bei der Durchführung verschiedener, neuer, leistungsfähiger Dinge zu gewährleisten.

Kurz gesagt

• Sicherheit und Datenschutz im Web sind eigentlich ziemlich erstaunlich, wenn man darüber nachdenkt.
• Sie sind ein Produkt der Standardrichtlinien der Plattform, die sich alle um die Einschränkung von Interaktionen über Ursprünge hinweg drehen.
• Standardmäßig sollte niemand in der Lage sein, Daten über Ursprünge hinweg zu lesen (ohne spezielle Erlaubnis).
• Der Grund, warum Lesevorgänge verboten sind, ist, dass wir alle unterschiedliche Netze sehen und Angreifer das Netz nicht durch die Augen potenzieller Opfer sehen können sollten.
• Keine Wenns, Abers oder Aber! Jedes Loch in der Same-Origin Policy, egal wie klein, ist Angriffsfläche für Missbrauch.
• Im Jahr 2020 versuchte ich, ein winziges Loch in die Same-Origin Policy zu bohren (ups), und durfte dann all das oben Gelernte erfahren.

Auf ein sichereres und geschützteres 2021, in jeder erdenklichen Hinsicht.