Beveilig pop-upinteracties met restrictie-eigenschappen

Krijg cross-origin-isolatie en cross-site-lekbescherming tijdens interactie met pop-ups.

Arthur Hemery
GitHub
Maud Nalpas
Maud Nalpas
X GitHub

Er is een nieuwe waarde voor Cross-Origin Opener Policy (COOP) beschikbaar: restrict-properties . Het levert beveiligingsvoordelen op en maakt het gemakkelijker om cross-origin-isolatie toe te passen, terwijl uw site kan communiceren met pop-ups van derden voor betalingen, authenticatie of andere gebruiksscenario's.

Als u wilt gaan experimenteren met restrict-properties kunt u deelnemen aan de origin-proefversie die begint in Chrome 116 .

Waarom restrict-properties gebruiken

restrict-properties heeft twee belangrijke gebruiksscenario's:

Voorkom lekkages tussen locaties zonder breuk

Standaard kan elke website uw applicatie in een pop-up openen en ernaar verwijzen.

Een kwaadwillende website kan dit in zijn voordeel gebruiken om aanvallen uit te voeren, zoals cross-site-lekken . Om dit risico te beperken, kunt u de Cross-Origin-Opener-Policy (COOP) header gebruiken.

Tot nu toe waren uw mogelijkheden voor Cross-Origin-Opener-Policy beperkt. Je kunt:

  • Stel same-origin, waardoor alle cross-origin-interacties met pop-ups worden geblokkeerd.
  • Stel same-origin-allow-popups , waarmee alle cross-origin-interacties worden geblokkeerd die uw site in een pop-up openen.
  • Stel unsafe-none in, waardoor alle cross-origin-interacties met pop-ups mogelijk zijn.

Dit maakte het onmogelijk voor websites die in een pop-up moeten worden geopend en met hun opener moeten communiceren om COOP af te dwingen. Hierdoor bleven belangrijke gebruiksscenario’s zoals eenmalige aanmelding en betalingen onbeschermd tegen lekken tussen sites.

Cross-Origin-Opener-Policy: restrict-properties lost dit op.

Met restrict-properties zijn eigenschappen die kunnen worden gebruikt voor het tellen van frames en andere cross-site-lekaanvallen niet beschikbaar, maar basiscommunicatie tussen vensters via postMessage en closed is toegestaan.

Dit verbetert de beveiliging van een site terwijl de belangrijkste gebruiksscenario's behouden blijven. Bijvoorbeeld:

  • Als u een dienst in een pop-up aanbiedt, beschermt het instellen van Cross-Origin-Opener-Policy: restrict-properties u tegen een reeks cross-site-lekaanvallen. U kunt nog steeds alle pagina's openen die u voorheen kon openen.
  • Als u toegang nodig heeft tot een cross-origin pop-up, kunt u door het instellen van Cross-Origin-Opener-Policy: restrict-properties uw site op dezelfde manier beschermen tegen het tellen van iframes. U kunt dezelfde reeks pop-ups openen die u vandaag kunt openen.
  • Als zowel de opener als de geopende de koptekst instellen, en de pagina's cross-origineel zijn, gedraagt ​​deze zich op dezelfde manier als een van hen die de koptekst heeft ingesteld. Als ze van dezelfde oorsprong zijn, wordt volledige toegang verleend.

Zorg ervoor dat uw site cross-origineel geïsoleerd is

Waarom we isolatie over de oorsprong heen nodig hebben

Sommige web-API's vergroten het risico op zijkanaalaanvallen zoals Spectre . Om dat risico te beperken, bieden browsers een op opt-in gebaseerde geïsoleerde omgeving, genaamd cross-origin isolation . Met een cross-origin geïsoleerde status kan de webpagina geprivilegieerde functies gebruiken, waaronder SharedArrayBuffer , performance.measureUserAgentSpecificMemory() en zeer nauwkeurige timers met een betere resolutie, terwijl de oorsprong van anderen wordt geïsoleerd, tenzij ze zijn aangemeld.

Tot nu toe moest je om deze API's te gebruiken Cross-Origin-Opener-Policy: same-origin instellen. Dit zou echter elke cross-origin pop-upstroom die u mogelijk nodig heeft, zoals eenmalige aanmelding en betalingen, verbreken.

Cross-Origin-Opener-Policy: restrict-properties kunnen nu worden gebruikt in plaats van Cross-Origin-Opener-Policy: same-origin om cross-origin-isolatie mogelijk te maken. In plaats van de openerrelatie te verbreken, wordt deze alleen beperkt tot de minimale communicatiesubset van window.postMessage() en window.closed .

U kunt cross-origin-isolatie inschakelen met de volgende twee headers:

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp

of

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless

Lees meer over credentialless op Cross-origin-bronnen laden zonder CORP-headers met behulp van COEP: credentialless .

Demo

Probeer verschillende headeropties in deze cross-origin isolatiedemo .

Experimenteer met de oorsprongproef

Als u wilt experimenteren met Cross-Origin-Opener-Policy: restrict-properties , meldt u zich aan voor de origin-proefversie .

Browser-ondersteuning

Cross-Origin-Opener-Policy: restrict-properties wordt momenteel alleen ondersteund in Chrome. Andere browsers zijn actief betrokken bij de discussie over standaardisatie .

FAQ

Mijn website moet communiceren met pop-ups van dezelfde oorsprong. Moet ik COOP: restrict-properties gebruiken om cross-origin isolatie mogelijk te maken?

Het instellen van COOP: restrict-properties op zowel de pop-up als uw hoofdpagina zal geen beperkingen veroorzaken. Als u dit alleen in de pop-up of alleen op de hoofdpagina instelt, wordt elke toegang tot andere eigenschappen dan postMessage voorkomen en wordt deze via de opener closed , zelfs als deze van dezelfde oorsprong zijn.

Staat de reeks toegestane eigenschappen vast?

Op basis van de feedback tot nu toe wordt vermoed dat window.postMessage en window.closed voldoende zijn voor de meeste workflows, maar we overwegen nog steeds om het voor andere eigenschappen open te stellen. Als u een gebruiksscenario heeft dat niet kan worden opgelost met alleen postMessage en closed , laat dan uw feedback achter in de Intent to Experiment-thread .

Bronnen