Summary

  • Die Fassung vom 27. Oktober eines CDNI-Arbeitsgruppenentwurfs beschreibt ein Cache-Problem: Eine erlaubte Herkunft bekommt Access-Control-Allow-Origin: *, und ohne passende Vary-Unterscheidung kann die Antwort bei einer ausgeschlossenen Herkunft landen.
  • Der Entwurf ordnet CORS als Entscheidung des konformen Browsers über die Offenlegung einer Antwort an Skripte ein; das nachgelagerte CDN liefert die öffentliche Ressource weiterhin aus.

Am Eingang funktioniert alles. Der Türsteher prüft die Gästeliste und gibt dem richtigen Gast ein Armband. Erst die Garderobe macht Kopien und reicht eine an jemanden weiter, der nie auf der Liste stand. Revision -13 des IETF-Entwurfs zu CDNI-Edge-Metadaten behandelt die technische Variante: Eine erlaubte Web-Herkunft erhält eine CORS-Antwort, danach verwischt ein gemeinsam genutzter Cache, für wen sie ausgestellt wurde.

Ein vorgelagertes CDN kann MI.CrossoriginPolicy über die Metadatenschnittstelle aus RFC 8006 an das nachgelagerte CDN geben. Dort wird der Origin-Header mit einer Zulassungsliste verglichen. Stimmt die Herkunft und ist wildcard-return eingeschaltet, darf die Antwort Access-Control-Allow-Origin: * enthalten. Für eine nicht passende Herkunft werden die entsprechenden CORS-Header weggelassen. Der Stern selbst verrät allerdings nicht, welche Herkunft zuvor zugelassen wurde.

Das neue Betriebskapitel beschreibt die gefährliche Wiederverwendung: Ein Cache könnte die Antwort mit Stern an eine ausgeschlossene Herkunft ausliefern, wenn er nicht anhand der maßgeblichen Anfrage-Header variiert. Der Entwurf verlangt deshalb, dass das nachgelagerte CDN CORS-Header für jede Antwort neu erzeugt und nicht als festen Teil der zwischengespeicherten Repräsentation ablegt. Die Header, von denen das Ergebnis abhängt, gehören in Vary. So bleibt der Unterschied zwischen gespeicherter Ressource und einer für eine bestimmte Anfrage getroffenen Entscheidung erhalten.

Die frühere Fassung -12 beschrieb bereits die Metadatenobjekte. -13 erklärt deutlicher, was sie überhaupt steuern. Ein konformer Browser nutzt CORS-Header, um über den Zugriff eines Skripts einer anderen Herkunft auf die Antwort zu entscheiden. Auch ohne solche Header liefert das nachgelagerte CDN die öffentlich zugängliche Ressource aus. Anforderungen mit dem Browser-Credential-Modus include liegen außerhalb dieser Objekte, weil Authentifizierung und Autorisierung mehr verlangen als die hier beschriebene Konfiguration.

Die Regel muss zudem erst ankommen. Gibt das vorgelagerte CDN eine Ressource frei, bevor MI.CrossoriginPolicy am Rand wirksam ist, wird sie dort zunächst ohne CORS-Header ausgeliefert; der Browser lässt die herkunftsübergreifende Nutzung dann scheitern. Nach dem neuen Betriebsteil können Betreiber über die bestehende RFC-8006-Schnittstelle nachsehen, welche Konfiguration am Rand tatsächlich gilt, und sie mit beobachteten Antworten vergleichen. Ein zusätzliches Fehlermeldesystem definiert der Entwurf dafür nicht.

Im IETF-Datatracker steht Revision -13 als CDNI-Arbeitsgruppenentwurf in der IESG-Prüfung. Für Betreiber lautet die Frage: Wer prüft nach dem Türsteher noch die Garderobe?