Origins en cross-site verzoeken
Versturen is geen lezen
Een pagina kan een afbeelding tonen die op elke andere site staat. Ze kan naar elke andere site linken, en ze kan een formulier bevatten dat naar elke andere site post. Zo is het web gebouwd. Elk daarvan is een verzoek dat de pagina van de ene site begint en dat de server van een andere site beantwoordt.
Je model kan al zeggen welke
Drie vragen
Voor elk verzoek dat een pagina begint, beantwoordt een browser drie vragen, en hij beantwoordt ze los van elkaar.
a page a server
|
| 1. Is the request sent? Almost always.
| 2. Does the cookie go along? Host, path, Secure, SameSite.
|
| ------------------ the request -------------------> |
| | the server
| | acts
| <----------------- the response ------------------- |
|
| 3. May the page read the response?
| Only when it comes from the page's own origin.
De eerste vraag is of het verzoek überhaupt wordt verstuurd. Het antwoord is bijna altijd ja. De
De tweede is of een cookie meegaat. Dat is les 3: de host, het pad, Secure en SameSite, dat sites vergelijkt.
De derde komt nadat de server heeft gehandeld en geantwoord: mag de pagina die het verzoek begon het antwoord lezen? Deze vergelijkt
Het beleid gaat over lezen
De regel achter de derde vraag is de
Lees die zin nog eens en zoek naar het woord “versturen”. Het staat er niet. Het beleid zegt wat een pagina mag lezen. Niets erin houdt het verzoek tegen, en niets erin noemt cookies. Hoofdstuk 9 laat zien hoe een server een andere origin toestemming kan geven om te lezen.
Het volledige beleid omvat meer dan antwoorden. Het heeft ook regels voor frames, voor gegevens die een pagina in de browser opslaat, en voor scripts die van een andere origin worden geladen. Deze les blijft bij antwoorden.
De tabel met gevallen
Hier zijn zes verzoeken aan https://reading.example. In elk geval bevat de jar de sessiecookie van Ana, die SameSite=Lax is.
| De pagina staat op | Ze begint | Verstuurd? | Cookie? | Mag de pagina het antwoord lezen? |
|---|---|---|---|---|
other.example | een afbeelding | ja | nee | nee |
other.example | een formulier-POST | ja | nee | nee |
other.example | een gevolgde link | ja | ja | nee |
notes.reading.example | een afbeelding | ja | ja | nee |
notes.reading.example | een formulier-POST | ja | ja | nee |
reading.example | een fetch van een script | ja | ja | ja |
In de derde rij komt de lezer op de leeslijst terecht en ziet hij de pagina ervan. De pagina met de link ziet die niet: haar script leest niets.
Het volgende blok drukt dezelfde tabel af. Elk verzoek wordt verstuurd, dus er is daar geen kolom voor. De cookiekolom wordt berekend door een korte kopie van de Lax-regel die je schreef, en de laatste kolom door origins te vergelijken. Voer het uit. Verander daarna een rij, bijvoorbeeld de "GET", en voer het opnieuw uit.
Een pagina op https://other.example bevat een afbeelding met het adres https://reading.example/me. Wat gebeurt er?
Dezelfde afbeelding staat op een pagina van https://notes.reading.example. Wat verandert er?
Wat daaruit volgt
Kijk nog eens naar de vijfde rij. Een pagina op notes.reading.example post een formulier naar de leeslijst. Het verzoek wordt verstuurd. De cookie van Ana gaat mee, omdat de buur op dezelfde site staat. De server ziet een POST met een geldige
Die pagina heeft het antwoord niet nodig. Als het formulier “verwijder boek 1” zei, was het boek al weg voordat er een antwoord bestond.
Een pagina kan het antwoord niet lezen op een formulier dat ze naar een andere origin postte. Waarom kan de POST toch schade doen?
De same-origin policy beschermt dus wat je server zegt, en ze beschermt niet wat je server doet. Een verzoek dat op iemands cookie meelift om een wijziging te doen waar die persoon nooit om vroeg, heet