Perché hai bisogno di un'opzione "con isolamento multiorigine" per funzionalità avanzate

Scopri perché è necessario l'isolamento multiorigine per usare funzionalità efficaci come SharedArrayBuffer, performance.measureUserAgentSpecificMemory() e timer ad alta risoluzione con maggiore precisione.

Introduzione

In Rendere il tuo sito web "isolato multiorigine" utilizzando COOP e COEP abbiamo spiegato come adottare lo stato "isolato multiorigine" utilizzando COOP e COEP. Questo è un articolo complementare che spiega perché l'isolamento multiorigine è necessario per attivare funzionalità efficaci nel browser.

Contesto

Il web si basa sul criterio same-origin, una funzionalità di sicurezza che limita il modo in cui documenti e script possono interagire con risorse di un'altra origine. Questo principio limita i modi in cui i siti web possono accedere alle risorse multiorigine. Ad esempio, a un documento di https://a.example viene impedito l'accesso ai dati ospitati in https://b.example.

Tuttavia, il criterio della stessa origine ha presentato alcune eccezioni storiche. Qualsiasi sito web può:

  • Incorpora iframe multiorigine
  • Includi risorse multiorigine come immagini o script
  • Apri finestre popup multiorigine con un riferimento DOM

Se il web fosse progettato da zero, queste eccezioni non esisterebbero. Sfortunatamente, quando la community web ha capito i principali vantaggi di un criterio rigoroso sulla stessa origine, il web si stava già facendo affidamento su queste eccezioni.

Gli effetti collaterali sulla sicurezza di un criterio della stessa origine di questo tipo lento sono stati applicati in due modi. Un modo è stata l'introduzione di un nuovo protocollo chiamato CORS (condivisione delle risorse tra origini), il cui scopo è garantire che il server consenta la condivisione di una risorsa con una determinata origine. L'altro modo è rimuovere implicitamente l'accesso diretto allo script alle risorse multiorigine, garantendo al contempo la compatibilità con le versioni precedenti. Queste risorse multiorigine sono chiamate risorse "opache". Ad esempio, questo è il motivo per cui la manipolazione dei pixel di un'immagine multiorigine tramite CanvasRenderingContext2D non riesce a meno che non venga applicato CORS all'immagine.

Tutte queste decisioni relative ai criteri avvengono all'interno di un gruppo di contesto di navigazione.

Gruppo di contesto di navigazione

Per molto tempo, la combinazione di risorse CORS e opache è stata sufficiente a rendere sicuri i browser. A volte sono stati scoperti casi perimetrali (come le vulnerabilità JSON) e occorre applicare le patch, ma nel complesso il principio di non consentire l'accesso in lettura diretto ai byte non elaborati delle risorse multiorigine ha avuto esito positivo.

Tutto è cambiato con Spectre, che rende potenzialmente leggibili tutti i dati caricati nello stesso gruppo di contesti di navigazione del tuo codice. Misurando il tempo richiesto da determinate operazioni, gli utenti malintenzionati possono indovinare i contenuti delle cache della CPU e, tramite questo, i contenuti della memoria del processo. Questi attacchi di temporizzazione sono possibili con timer a bassa granularità presenti nella piattaforma, ma possono essere accelerati con timer ad alta granularità, sia espliciti (come performance.now()) che impliciti (come SharedArrayBuffer). Se evil.com incorpora un'immagine multiorigine, può utilizzare un attacco Spectre per leggere i dati dei pixel, il che rende inefficaci le protezioni basate sull'"opacità".

Spettro

Idealmente, tutte le richieste multiorigine dovrebbero essere verificate esplicitamente dal server proprietario della risorsa. Se il server proprietario delle risorse non fornisce il controllo, i dati non verranno mai inseriti nel gruppo di navigazione di un utente malintenzionato, quindi non saranno raggiungibili da qualsiasi attacco di Spectre che una pagina web potrebbe portare a termine. Lo abbiamo definito stato con isolamento multiorigine. Questo è esattamente l'argomento di COOP+COEP.

In uno stato isolato multiorigine, il sito richiedente è considerato meno pericoloso e questo sblocca funzionalità potenti come SharedArrayBuffer, performance.measureUserAgentSpecificMemory() e timer ad alta risoluzione con maggiore precisione, che altrimenti potrebbero essere utilizzate per attacchi di tipo Spectre. Impedisce inoltre di modificare document.domain.

Norme sull'incorporamento multiorigine

Il criterio di incorporamento multiorigine (COEP) impedisce a un documento di caricare le risorse multiorigine che non concedono esplicitamente l'autorizzazione per il documento (utilizzando CORP o CORS). Con questa funzione, puoi dichiarare che un documento non può caricare queste risorse.

Come funziona COEP

Per attivare questo criterio, aggiungi la seguente intestazione HTTP al documento:

Cross-Origin-Embedder-Policy: require-corp

La parola chiave require-corp è l'unico valore accettato per COEP. In questo modo viene applicato il criterio secondo cui il documento può caricare risorse solo dalla stessa origine o risorse contrassegnate esplicitamente come caricabili da un'altra origine.

Per poter caricare le risorse da un'altra origine, devono supportare la condivisione delle risorse tra origini (CORS) o il criterio CORP (Cross Origin Resource Policy).

Condivisione delle risorse tra origini

Se una risorsa multiorigine supporta la condivisione delle risorse tra origini (CORS), puoi utilizzare l'attributo crossorigin per caricarla sulla tua pagina web senza essere bloccata da COEP.

<img src="https://third-party.example.com/image.jpg" crossorigin>

Ad esempio, se questa risorsa immagine viene pubblicata con intestazioni CORS, utilizza l'attributo crossorigin in modo che la richiesta di recupero della risorsa utilizzi la modalità CORS. In questo modo inoltre impedisce il caricamento dell'immagine, a meno che non imposti le intestazioni CORS.

Analogamente, puoi recuperare i dati multiorigine tramite il metodo fetch(), che non richiede una gestione speciale purché il server risponda con le intestazioni HTTP corrette.

Criterio delle risorse multiorigine

Il cross Origin Resource Policy (CORP) è stato originariamente introdotto come attivazione per proteggere le tue risorse dal caricamento da parte di un'altra origine. Nel contesto del COEP, il CORP può specificare il criterio del proprietario per stabilire chi può caricarne una.

Sono possibili tre valori per l'intestazione Cross-Origin-Resource-Policy:

Cross-Origin-Resource-Policy: same-site

Le risorse contrassegnate con same-site possono essere caricate solo dallo stesso sito.

Cross-Origin-Resource-Policy: same-origin

Le risorse contrassegnate con same-origin possono essere caricate solo dalla stessa origine.

Cross-Origin-Resource-Policy: cross-origin

Le risorse contrassegnate con cross-origin possono essere caricate da qualsiasi sito web. (Questo valore è stato aggiunto alla specifica CORP insieme al COEP.)

Criterio di apertura multiorigine

Cross Origin Opener Policy (COOP) ti consente di assicurarti che una finestra di primo livello sia isolata dagli altri documenti inserendoli in un diverso gruppo di contesti di navigazione, in modo che non possano interagire direttamente con la finestra di primo livello. Ad esempio, se un documento con COOP apre un popup, la sua proprietà window.opener sarà null. Inoltre, la proprietà .closed del riferimento dell'opener restituirà true.

COOP

Sono possibili tre valori per l'intestazione Cross-Origin-Opener-Policy:

Cross-Origin-Opener-Policy: same-origin

I documenti contrassegnati con same-origin possono condividere lo stesso gruppo di contesti di esplorazione con documenti della stessa origine che sono anche contrassegnati esplicitamente same-origin.

COOP

Cross-Origin-Opener-Policy: same-origin-allow-popups

Un documento di primo livello con same-origin-allow-popups conserva i riferimenti a tutti i suoi popup che non impostano COOP o che disattivano l'isolamento impostando un COOP pari a unsafe-none.

COOP

Cross-Origin-Opener-Policy: unsafe-none

unsafe-none è l'impostazione predefinita e consente di aggiungere il documento al gruppo di contesto di navigazione dell'elemento di apertura, a meno che l'elemento di apertura non abbia un COOP pari a same-origin.

Riepilogo

Se vuoi garantire l'accesso a funzionalità potenti come SharedArrayBuffer, performance.measureUserAgentSpecificMemory() o timer ad alta risoluzione con maggiore precisione, ricorda che il tuo documento deve utilizzare sia COEP con valore require-corp sia COOP con valore same-origin. In assenza di queste funzionalità, il browser non garantisce un isolamento sufficiente per attivare in sicurezza queste potenti funzionalità. Puoi determinare la situazione della tua pagina controllando se self.crossOriginIsolated restituisce true.

Per scoprire la procedura per implementarla, consulta Rendere il tuo sito web "interorigine interorigine" utilizzando COOP e COEP.

Risorse