Video und Untertitel · Direct Media Downloader
Eine kurze Geschichte der Same-Origin-Richtlinie und CORS in Webbrowsern
· Hintergrund
kors Webprotokoll Sicherheit
Die Regel, die ein Browser-Tool daran hindert, die Dateien einer anderen Site ungehindert zu lesen, stammt aus den frühesten Skriptbrowsern. In diesem Beitrag werden die Same-Origin-Richtlinie XMLHttpRequest und der CORS-Standard nachgezeichnet, die schließlich den kontrollierten standortübergreifenden Abruf ermöglichten.
Warum ein Browser sich weigert, Ihrem eigenen Tab die gerade empfangenen Bytes zu übergeben – der alltägliche Effekt einer jahrzehntealten Regel
Ein Browser kann eine Remote-Datei anzeigen, sich jedoch weigern, diesen Antworttext an das Seiten-JavaScript zu übergeben. Der scheinbare Widerspruch ist eine Sicherheitstrennung zwischen Navigation und programmatischem Cross-Origin-Lesen.
Direct Media Downloader trifft auf die Regel, weil er Blöcke in einen Blob lesen muss. Der native Link „Speichern unter“ kann dort funktionieren, wo der Abruf fehlschlägt, da er einem anderen Browserpfad folgt. Durch die Weigerung werden Cookies und Intranetressourcen an anderer Stelle im Browser geschützt, auch wenn dieser spezielle Downloader bei seinen eigenen Aufrufen bewusst Anmeldeinformationen weglässt. Die Grenze schützt nicht verwandte Cookies und Intranetseiten im selben Browser, auch wenn bei dieser speziellen Anfrage Anmeldeinformationen weggelassen werden.
Netscape, JavaScript und die erste Ursprungsregel – das Sicherheitsproblem, das zur Same-Origin-Richtlinie geführt hat
Frühe Webskripte machten es erforderlich, eine Website daran zu hindern, die sensiblen Seiten einer anderen Website über den Umgebungszugriff eines Besuchers zu lesen. Browser organisierten diese Grenze nach den Ursprüngen.
Historische Details variieren je nach Implementierung, daher ist die praktische Vererbung am wichtigsten: Schema, Host und Port definieren ein Vertrauensfach für skriptlesbare Ressourcen. Die Behandlung eines Ursprungs als eine Einheit war eine technische Grenze, die konsistent über Dokumente, Skripte und Netzwerk-APIs hinweg durchgesetzt werden konnte. Die Ursprungsgruppierung stellte eine durchsetzbare Einheit bereit, die Browser-Engines auf Dokumente, Skripte, Speicher und Netzwerkantworten anwenden konnten. Das Modell ist unvollkommen, bietet Entwicklern jedoch einen vorhersehbaren Standardwert und keine uneingeschränkte Umgebungsautorität.
XMLHttpRequest und das abgeschottete Web – wie skriptgesteuerte Anfragen die Regel erbten und warum Mashups Schwierigkeiten hatten
XMLHttpRequest aktivierte Hintergrund-HTTP-Arbeit, behielt jedoch die Ursprungseinschränkungen bei. Dies machte Anwendungen auf derselben Site nützlich, während Mashups über mehrere Sites hinweg eine Zusammenarbeit oder Server-Vermittler erforderten.
Eine universelle Client-Überschreibung hätte den Schutz zerstört. Der Server, dem das Ziel gehört, benötigte eine Möglichkeit auszudrücken, welche externen Ursprünge ausgewählte Antworten lesen konnten. Server-Relays wurden zu gängigen Problemumgehungen, verlagerten jedoch das Risiko von Vertrauen, Bandbreite und Anforderungsfälschung auf die Infrastruktur außerhalb der Browser-Sandbox. Relay-Problemumgehungen verlagerten Bandbreite, Vertrauen und serverseitiges Anforderungsfälschungsrisiko über die Client-Sandbox hinaus, anstatt die Richtlinie zu beseitigen. Diese Vermittler benötigen ihre eigenen Sicherheits-, Datenschutz- und Missbrauchskontrollen, wenn sie absichtlich eingesetzt werden.
Der CORS-Standard – wie Access-Control-Header es einem Server ermöglichen, sich für das Cross-Origin-Lesen zu entscheiden, ohne den Standard zu lockern
CORS stellt diese Zusammenarbeit über HTTP-Antwortheader bereit, die von Browsern interpretiert werden. `Access-Control-Allow-Origin` kann eine anfragende Herkunft oder, in geeigneten Fällen ohne Anmeldeinformationen, eine breitere Zielgruppe autorisieren.
Der Mechanismus deaktiviert die Same-Origin-Richtlinie nicht global. Es gewährt bereichsbezogenen Lesezugriff auf Antworten, deren Host sie unter dem Protokoll verfügbar macht. Preflight-Ergebnisse können vom Browser gemäß Protokollregeln zwischengespeichert werden, sodass eine Prüfung nicht aus einem Warm-Trace schließen sollte, dass „es nie eine Richtlinienprüfung stattgefunden hat“. Dadurch bleibt die Standardisolation erhalten, während Ressourceneigentümer gleichzeitig eine absichtliche Ausnahme für ausgewählte Aufrufer und Methoden veröffentlichen können.
Preflights, einfache Anfragen und undurchsichtige Antworten – das Vokabular, das die meisten Download-Fehler erklärt
Einige Cross-Origin-Anfragen sind so einfach, dass kein Preflight erforderlich ist. andere senden zunächst OPTIONS, um zu fragen, ob Methode und Header zulässig sind. Beim Preflight handelt es sich um eine Verhandlung, nicht um den eigentlichen Medientransfer.
Undurchsichtige Antworten ergeben sich aus dem No-Cors-Modus und verbergen Status, Header und Textkörper vor dem Skript. ToolAcre wählt diesen Modus nicht aus, da ein unlesbarer Körper nicht zum beabsichtigten speicherbaren Blob werden kann. Ein CORS-Fehler kann gleichzeitig mit einer erfolgreichen serverseitigen Anfrage auftreten, was unterstreicht, warum ein Anwendungsfehler nicht bedeutet, dass der Ursprung nichts erhalten hat. Zwischengespeicherte Preflight-Entscheidungen können das, was in einem warmen Trace angezeigt wird, verändern, daher ist das historische Fehlen von OPTIONS kein Beweis dafür, dass es nie eine Verhandlung gegeben hat.
Was CORS für einen reinen Browser-Downloader bedeutet – der Host entscheidet, das Tool kann nichts außer Kraft setzen, und Ehrlichkeit ist die richtige Antwort
Für diesen Downloader entscheidet der Host, ob HEAD- und GET-Antworten lesbar sind. ToolAcre kann im Namen des Hosts keinen Antwortheader mit zulässigem Ursprung anhängen und leitet den Text nicht über seinen eigenen Ursprung weiter.
Der Fehler kombiniert CORS- und Netzwerkmöglichkeiten, da Fetch bei einigen Fehlern absichtlich feinkörnige Informationen zurückhält. DevTools verrät dem Besucher möglicherweise mehr, als der Anwendungscode erhält. Host-Betreiber sollten nur beabsichtigte Ursprünge, Methoden und Header autorisieren und dann ihre genauen Produktionsreaktionen überprüfen, anstatt sich auf die lokale Konfigurationsabsicht zu verlassen. Ein blockierter Lesevorgang kann mit einem Server koexistieren, der die Anfrage empfangen hat, weshalb die Schnittstelle einen Anwendungsfehler niemals mit keinem Kontakt gleichsetzt.
Fazit: Eine Regel, die Sie schützt, auch wenn sie Sie nervt – wie der Direct Media Downloader darin und nicht um sie herum funktioniert
Die Regel schützt Benutzer auch dann, wenn sie eine legitime Dateiübertragung verhindert. Ein Host, der möchte, dass Browseranwendungen öffentliche Medien lesen, kann entsprechende CORS-Antworten konfigurieren; eine, auf die nicht über diesen Skriptpfad zugegriffen werden kann.
Direct Media Downloader funktioniert innerhalb dieses Modells: lokal validieren, offen anfordern, Ablehnung erklären und gegebenenfalls natives Speichern vorschlagen. Es verwandelt eine Browser-Sicherheitsgrenze nicht in ein Umgehungsproblem. Wenn man diesen Verlauf versteht, wird der Fehler von einer willkürlichen Browser-Angriffsreaktion zu einer sichtbaren Konsequenz eines standortübergreifenden Lesemodells, bei dem die Standardeinstellung verweigert wird. Origin-Besitzer sollten genaue Produktionsheader für die vorgesehenen Methoden testen, anstatt sich ausschließlich auf eine Dashboard-Konfiguration zu verlassen.