Beveilig pop-upinteracties met restrictie-eigenschappen

Profiteer van cross-origin isolatie en bescherming tegen datalekken tussen verschillende sites tijdens interactie met pop-ups.

Arthur Hemery
GitHub
Maud Nalpas

Er is een nieuwe waarde beschikbaar voor Cross-Origin Opener Policy (COOP) : restrict-properties . Deze waarde biedt beveiligingsvoordelen en maakt het eenvoudiger om cross-origin-isolatie toe te passen, terwijl uw site toch kan blijven samenwerken met pop-ups van derden voor betalingen, authenticatie of andere toepassingen.

Om te experimenteren met restrict-properties neem deel aan de origin-proef die start 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-upvenster openen en ernaar verwijzen.

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

Tot nu toe waren uw opties voor Cross-Origin-Opener-Policy beperkt. U kon kiezen uit:

  • Stel de optie same-origin, waardoor alle interacties met pop-ups van een andere oorsprong worden geblokkeerd.
  • Stel same-origin-allow-popups om alle cross-origin interacties te blokkeren die uw site in een pop-upvenster openen.
  • Stel unsafe-none in, waardoor alle interacties met pop-ups van andere oorsprong zijn toegestaan.

Hierdoor werd het voor websites die in een pop-upvenster moeten worden geopend en die interactie met dat venster vereisen, onmogelijk om COOP af te dwingen. Dit liet belangrijke toepassingen zoals single sign-on en betalingen onbeschermd tegen datalekken tussen verschillende websites.

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

Met restrict-properties zijn eigenschappen die gebruikt kunnen worden voor frame-counting en andere cross-site leak-aanvallen niet beschikbaar, maar basiscommunicatie tussen vensters via postMessage en closed is wel toegestaan.

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

  • Als u een service aanbiedt in een pop-upvenster, beschermt het instellen van Cross-Origin-Opener-Policy: restrict-properties u tegen diverse cross-site-lekaanvallen. U kunt nog steeds alle pagina's openen die u voorheen ook kon openen.
  • Als u een pop-up van een andere oorsprong wilt openen, kunt u met de instelling Cross-Origin-Opener-Policy: restrict-properties uw site beschermen tegen het tellen van iframes. U kunt dan dezelfde pop-ups openen als nu.
  • Als zowel de opener als de geopende pagina de header instellen en de pagina's afkomstig zijn van verschillende oorsprongen, gedraagt ​​het zich hetzelfde als wanneer slechts één van beide de header heeft ingesteld. Als ze afkomstig zijn van dezelfde oorsprong, wordt volledige toegang verleend.

Maak uw site cross-origin geïsoleerd.

Waarom we isolatie tussen verschillende oorsprongen nodig hebben

Sommige web-API's verhogen het risico op side-channel-aanvallen 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 isolated-status kan de webpagina gebruikmaken van geprivilegieerde functies zoals SharedArrayBuffer , performance.measureUserAgentSpecificMemory() en zeer nauwkeurige timers met een betere resolutie, terwijl de oorsprong wordt geïsoleerd van andere bronnen, tenzij deze zich hiervoor hebben 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-upflow verstoren die je mogelijk nodig hebt, zoals single sign-on en betalingen.

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

Je 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 Bronnen van verschillende oorsprong laden zonder CORP-headers met COEP: credentialless .

Demo

Probeer verschillende headeropties uit in deze demonstratie van cross-origin isolatie .

Experimenteer met de oorsprongsproef.

Om te experimenteren met Cross-Origin-Opener-Policy: restrict-properties , meld je je aan voor de origin trial .

Browserondersteuning

Cross-Origin-Opener-Policy: restrict-properties wordt momenteel alleen ondersteund in Chrome. Andere browsers nemen actief deel aan de discussie over standaardisatie .

Veelgestelde vragen

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

Het instellen COOP: restrict-properties op zowel de pop-up als uw hoofdpagina zal geen beperkingen veroorzaken. Als u dit alleen op de pop-up of alleen op de hoofdpagina instelt, wordt de toegang tot andere eigenschappen dan postMessage en closed geblokkeerd, ongeacht of de pop-up of de hoofdpagina van dezelfde oorsprong is.

Is de set van toegestane eigenschappen vastgelegd?

Op basis van de feedback tot nu toe lijken ` window.postMessage en window.closed voldoende te zijn voor de meeste workflows, maar we overwegen nog steeds om dit uit te breiden naar andere eigenschappen. Als je een use case hebt die niet kan worden opgelost met alleen postMessage en closed laat dan je feedback achter in de Intent to Experiment-thread .

Bronnen