8. Security Considerations (Considerazioni sulla sicurezza)

La politica same-origin è una delle pietre angolari della sicurezza per molti user agent, inclusi i browser web. Storicamente, alcuni user agent hanno provato altri modelli di sicurezza, tra cui il tracciamento delle contaminazioni e la prevenzione dell'esfiltrazione, ma questi modelli si sono rivelati difficili da implementare all'epoca (sebbene ci sia stato un recente interesse nel far rivivere alcune di queste idee).

Valutare la sicurezza della politica same-origin è difficile perché il concetto di origine stesso gioca un ruolo così centrale nel panorama della sicurezza. L'origine concettuale stessa è solo un'unità di isolamento, imperfetta come lo sono la maggior parte delle nozioni universali. Detto questo, ci sono alcune debolezze sistemiche, discusse di seguito.

8.1 Reliance on DNS (Dipendenza da DNS)

In pratica, la politica same-origin si basa sul Domain Name System (DNS) per la sicurezza perché molti schemi URI comunemente utilizzati, come http, utilizzano autorità di denominazione basate su DNS. Se il DNS è parzialmente o completamente compromesso, la politica same-origin potrebbe non fornire le proprietà di sicurezza richieste dalle applicazioni.

Alcuni schemi URI, come https, sono più resistenti alla compromissione DNS perché gli user agent impiegano altri meccanismi, come i certificati, per verificare la fonte del contenuto recuperato da questi URI. Altri schemi URI, come lo schema URI chrome-extension (vedere Sezione 4.3 di [CRX]), utilizzano un'autorità di denominazione basata su chiave pubblica e sono completamente sicuri contro la compromissione DNS.

Il concetto di origine web isola il contenuto recuperato da diversi schemi URI; questo è essenziale per contenere gli effetti della compromissione DNS.

8.2 Divergent Units of Isolation (Unità di isolamento divergenti)

Nel tempo, un numero di tecnologie è convergso sul concetto di origine web come unità di isolamento conveniente. Tuttavia, molte tecnologie in uso oggi, come i cookie [RFC6265], precedono il concetto moderno di origine web. Queste tecnologie hanno spesso unità di isolamento diverse, portando a vulnerabilità.

Un'alternativa è utilizzare solo il dominio "controllato dal registro" anziché il nome di dominio completamente qualificato come unità di isolamento (ad esempio, "example.com" invece di "www.example.com"). Questa pratica è problematica per diversi motivi e NON È RACCOMANDATA:

La nozione di dominio "controllato dal registro" è una funzione della pratica umana che circonda il DNS piuttosto che una proprietà del DNS stesso. Ad esempio, molti comuni in Giappone gestiscono registri pubblici piuttosto in profondità nella gerarchia DNS. Esistono "elenchi di suffissi pubblici" ampiamente utilizzati, ma questi elenchi sono difficili da mantenere aggiornati e variano tra le implementazioni.
Questa pratica è incompatibile con schemi URI che non utilizzano un'autorità di denominazione basata su DNS. Ad esempio, se un dato schema URI utilizza chiavi pubbliche come autorità di denominazione, la nozione di chiave pubblica "controllata dal registro" è alquanto incoerente. Peggio ancora, alcuni schemi URI, come nntp, utilizzano la delega puntata nella direzione opposta rispetto a DNS (ad esempio, alt.usenet.kooks), e altri utilizzano il DNS ma presentano le etichette nell'ordine inverso rispetto all'ordine usuale (ad esempio, com.example.www).

Nel migliore dei casi, l'utilizzo di domini "controllati dal registro" è specifico dello schema URI e dell'implementazione. Nel peggiore dei casi, le differenze tra schemi URI e implementazioni possono portare a vulnerabilità.

8.3 Ambient Authority (Autorità ambientale)

Quando si utilizza la politica same-origin, gli user agent concedono autorità al contenuto in base al suo URI piuttosto che in base a quali oggetti il contenuto può designare. Questo disaccoppiamento della designazione dall'autorità è un esempio di autorità ambientale e può portare a vulnerabilità.

Consideriamo, ad esempio, il cross-site scripting nei documenti HTML. Se un attaccante può iniettare contenuto di script in un documento HTML, quegli script verranno eseguiti con l'autorità dell'origine del documento, consentendo forse allo script di accedere a informazioni sensibili, come le cartelle cliniche dell'utente. Se, tuttavia, l'autorità dello script fosse limitata a quegli oggetti che lo script può designare, l'attaccante non otterrebbe alcun vantaggio iniettando lo script in un documento HTML ospitato da una terza parte.

8.4 IDNA Dependency and Migration (Dipendenza e migrazione IDNA)

Le proprietà di sicurezza della politica same-origin possono dipendere in modo cruciale dai dettagli dell'algoritmo IDNA impiegato dall'user agent. In particolare, un user agent potrebbe mappare alcuni nomi di dominio internazionalizzati (ad esempio, quelli che coinvolgono il carattere U+00DF) a rappresentazioni ASCII diverse a seconda che l'user agent utilizzi IDNA2003 [RFC3490] o IDNA2008 [RFC5890].

La migrazione da un algoritmo IDNA a un altro potrebbe ridisegnare un numero di confini di sicurezza, potenzialmente erigendo nuovi confini di sicurezza o, peggio ancora, abbattendo i confini di sicurezza tra due entità che si diffidano reciprocamente. Modificare i confini di sicurezza è rischioso perché combinare due entità che si diffidano reciprocamente nella stessa origine potrebbe consentire a una di attaccare l'altra.