3. Principles of the Same-Origin Policy (Principi della politica same-origin)

Molti user agent intraprendono azioni per conto di parti remote. Ad esempio, gli user agent HTTP seguono i reindirizzamenti, che sono istruzioni provenienti da server remoti, e gli user agent HTML espongono ricche interfacce Document Object Model (DOM) agli script recuperati da server remoti.

Senza alcun modello di sicurezza, gli user agent potrebbero intraprendere azioni dannose per l'utente o per altre parti. Nel tempo, molte tecnologie legate al web sono converge verso un modello di sicurezza comune, noto colloquialmente come "politica same-origin" (same-origin policy). Sebbene questo modello di sicurezza si sia evoluto in gran parte organicamente, la politica same-origin può essere compresa in termini di una manciata di concetti chiave. Questa sezione presenta questi concetti e fornisce consigli su come utilizzare questi concetti in modo sicuro.

3.1 Trust (Fiducia)

La politica same-origin specifica la fiducia tramite URI. Ad esempio, i documenti HTML designano quale script eseguire con un URI:

<script src="https://example.com/library.js"></script>

Quando un user agent elabora questo elemento, l'user agent recupererà lo script all'URI designato ed eseguirà lo script con i privilegi del documento. In questo modo, il documento concede tutti i privilegi che possiede alla risorsa designata dall'URI. In sostanza, il documento dichiara di fidarsi dell'integrità delle informazioni recuperate da quell'URI.

Oltre a importare librerie da URI, gli user agent inviano anche informazioni a parti remote designate dall'URI. Ad esempio, consideriamo l'elemento form HTML:

<form method="POST" action="https://example.com/login">
 ... <input type="password"> ...
</form>

Quando l'utente inserisce la sua password e invia il modulo, l'user agent invia la password all'endpoint di rete designato dall'URI. In questo modo, il documento esporta i suoi dati segreti a quell'URI, dichiarando essenzialmente di fidarsi della riservatezza delle informazioni inviate a quell'URI.

3.1.1 Pitfalls (Insidie)

Quando si progettano nuovi protocolli che utilizzano la politica same-origin, assicurarsi che le distinzioni di fiducia importanti siano visibili negli URI. Ad esempio, se sia le risorse protette da Transport Layer Security (TLS) che quelle non protette utilizzano lo schema URI "http" (come in [RFC2817]), un documento non sarebbe in grado di specificare che desidera recuperare uno script solo tramite TLS. Utilizzando lo schema URI "https", i documenti sono in grado di indicare che desiderano interagire con risorse protette dagli attaccanti di rete attivi.

3.2 Origin (Origine)

In linea di principio, gli user agent potrebbero trattare ogni URI come un dominio di protezione separato e richiedere il consenso esplicito affinché il contenuto recuperato da un URI interagisca con un altro URI. Sfortunatamente, questa progettazione è ingombrante per gli sviluppatori perché le applicazioni web sono spesso composte da un certo numero di risorse che agiscono di concerto.

Invece, gli user agent raggruppano gli URI in domini di protezione chiamati "origini" (origins). In parole povere, due URI fanno parte della stessa origine (cioè rappresentano lo stesso principale) se hanno lo stesso schema, host e porta. (Vedere la Sezione 4 per i dettagli completi.)

D: Perché non usare solo l'host?

R: L'inclusione dello schema nella tupla dell'origine è essenziale per la sicurezza. Se gli user agent non includessero lo schema, non ci sarebbe isolamento tra http://example.com e https://example.com perché i due hanno lo stesso host. Tuttavia, senza questo isolamento, un attaccante di rete attivo potrebbe corrompere il contenuto recuperato da http://example.com e fare in modo che quel contenuto istruisca l'user agent a compromettere la riservatezza e l'integrità del contenuto recuperato da https://example.com, aggirando le protezioni offerte da TLS [RFC5246].

D: Perché usare il nome host completamente qualificato invece del solo dominio di "primo livello"?

R: Sebbene il DNS abbia una delega gerarchica, le relazioni di fiducia tra i nomi host variano in base alla distribuzione. Ad esempio, presso molte istituzioni educative, gli studenti possono ospitare contenuti su https://example.edu/~student/, ma ciò non significa che un documento scritto da uno studente dovrebbe far parte della stessa origine (cioè abitare lo stesso dominio di protezione) di un'applicazione web per la gestione dei voti ospitata su https://grades.example.edu/.

La distribuzione example.edu illustra che il raggruppamento delle risorse per origine non si allinea sempre perfettamente con ogni scenario di distribuzione. In questa distribuzione, il sito web di ogni studente abita la stessa origine, il che potrebbe non essere desiderabile. In un certo senso, la granularità dell'origine è un artefatto storico di come si è evoluto il modello di sicurezza.

3.2.1 Examples (Esempi)

Tutte le seguenti risorse hanno la stessa origine:

http://example.com/
http://example.com:80/
http://example.com/path/file

Ciascuno degli URI ha gli stessi componenti schema, host e porta.

Ciascuna delle seguenti risorse ha un'origine diversa dalle altre:

http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/

In ciascun caso, almeno uno dei componenti schema, host e porta differirà dagli altri nell'elenco.

3.3 Authority (Autorità)

Sebbene gli user agent raggruppino gli URI in origini, non ogni risorsa in un'origine porta la stessa autorità (nel senso di sicurezza della parola "autorità", non nel senso [RFC3986]). Ad esempio, un'immagine è contenuto passivo e, pertanto, non porta alcuna autorità, il che significa che l'immagine non ha accesso agli oggetti e alle risorse disponibili per la sua origine. Al contrario, un documento HTML porta l'autorità completa della sua origine, e gli script all'interno (o importati) del documento possono accedere a ogni risorsa nella sua origine.

Gli user agent determinano quanta autorità concedere a una risorsa esaminando il suo tipo di media. Ad esempio, le risorse con un tipo di media image/png sono trattate come immagini, e le risorse con un tipo di media text/html sono trattate come documenti HTML.

Quando si ospita contenuto non affidabile (come contenuto generato dall'utente), le applicazioni web possono limitare l'autorità di quel contenuto restringendo il suo tipo di media. Ad esempio, servire contenuto generato dall'utente come image/png è meno rischioso che servirlo come text/html. Naturalmente, molte applicazioni web incorporano contenuto non affidabile nei loro documenti HTML. Se non fatto con attenzione, queste applicazioni rischiano di far trapelare l'autorità della loro origine al contenuto non affidabile, una vulnerabilità comunemente nota come cross-site scripting.

3.3.1 Pitfalls (Insidie)

Quando si progettano nuove parti della piattaforma web, fare attenzione a non concedere autorità alle risorse indipendentemente dal tipo di media. Molte applicazioni web servono contenuto non affidabile con tipi di media ristretti. Una nuova funzionalità della piattaforma web che concede autorità a questi pezzi di contenuto rischia di introdurre vulnerabilità nelle applicazioni esistenti. Invece, preferire concedere autorità ai tipi di media che già possiedono l'autorità completa dell'origine o a nuovi tipi di media progettati specificamente per portare la nuova autorità.

Per rimanere compatibili con i server che forniscono tipi di media errati, alcuni user agent impiegano il "content sniffing" e trattano il contenuto come se avesse un tipo di media diverso dal tipo di media fornito dal server. Se non fatto con attenzione, il content sniffing può portare a vulnerabilità di sicurezza perché gli user agent potrebbero concedere a tipi di media a bassa autorità, come le immagini, i privilegi dei tipi di media ad alta autorità, come i documenti HTML [SNIFF].

3.4 Policy (Politica)

In generale, gli user agent isolano origini diverse e consentono comunicazioni controllate tra le origini. I dettagli di come gli user agent forniscono isolamento e comunicazione variano a seconda di diversi fattori.

3.4.1 Object Access (Accesso agli oggetti)

La maggior parte degli oggetti (noti anche come interfacce di programmazione delle applicazioni o API) esposti dall'user agent sono disponibili solo per la stessa origine. Nello specifico, il contenuto recuperato da un URI può accedere agli oggetti associati al contenuto recuperato da un altro URI se, e solo se, i due URI appartengono alla stessa origine, ad esempio, hanno lo stesso schema, host e porta.

Ci sono alcune eccezioni a questa regola generale. Ad esempio, alcune parti dell'interfaccia Location di HTML sono disponibili tra le origini (ad esempio, per consentire la navigazione in altri contesti di navigazione). Come altro esempio, l'interfaccia postMessage di HTML è visibile tra le origini esplicitamente per facilitare la comunicazione cross-origin. Esporre oggetti a origini straniere è pericoloso e dovrebbe essere fatto solo con grande cura perché ciò espone questi oggetti a potenziali attaccanti.

3.4.2 Network Access (Accesso alla rete)

L'accesso alle risorse di rete varia a seconda che le risorse siano nella stessa origine del contenuto che tenta di accedervi.

In generale, la lettura di informazioni da un'altra origine è vietata. Tuttavia, un'origine è autorizzata a utilizzare alcuni tipi di risorse recuperate da altre origini. Ad esempio, un'origine è autorizzata a eseguire script, renderizzare immagini e applicare fogli di stile da qualsiasi origine. Allo stesso modo, un'origine può visualizzare contenuto da un'altra origine, come un documento HTML in un frame HTML. Le risorse di rete possono anche scegliere di consentire ad altre origini di leggere le loro informazioni, ad esempio utilizzando Cross-Origin Resource Sharing [CORS]. In questi casi, l'accesso è tipicamente concesso su base per origine.

L'invio di informazioni a un'altra origine è consentito. Tuttavia, l'invio di informazioni sulla rete in formati arbitrari è pericoloso. Per questo motivo, gli user agent limitano i documenti all'invio di informazioni utilizzando protocolli particolari, come in una richiesta HTTP senza intestazioni personalizzate. L'espansione dell'insieme di protocolli consentiti, ad esempio aggiungendo il supporto per WebSocket, deve essere fatta con attenzione per evitare di introdurre vulnerabilità [RFC6455].

3.4.3 Pitfalls (Insidie)

Ogni volta che gli user agent consentono a un'origine di interagire con risorse da un'altra origine, invitano problemi di sicurezza. Ad esempio, la capacità di visualizzare immagini da un'altra origine rivela la loro altezza e larghezza. Allo stesso modo, la capacità di inviare richieste di rete a un'altra origine dà origine a vulnerabilità di cross-site request forgery [CSRF]. Tuttavia, gli implementatori di user agent spesso bilanciano questi rischi con i benefici di consentire l'interazione cross-origin. Ad esempio, un user agent HTML che bloccasse le richieste di rete cross-origin impedirebbe ai suoi utenti di seguire i collegamenti ipertestuali, una caratteristica fondamentale del web.

Quando si aggiungono nuove funzionalità alla piattaforma web, può essere allettante concedere un privilegio a una risorsa ma negare quel privilegio a un'altra risorsa nella stessa origine. Tuttavia, negare i privilegi in questo modo è inefficace perché la risorsa senza il privilegio di solito può comunque ottenere il privilegio perché gli user agent non isolano le risorse all'interno di un'origine. Invece, i privilegi dovrebbero essere concessi o negati alle origini nel loro complesso (piuttosto che discriminare tra singole risorse all'interno di un'origine) [BOFGO].

3.5 Conclusion (Conclusione)

La politica same-origin utilizza gli URI per designare le relazioni di fiducia. Gli URI sono raggruppati in origini, che rappresentano domini di protezione. Alcune risorse in un'origine (ad esempio, contenuto attivo) ricevono l'autorità completa dell'origine, mentre altre risorse nell'origine (ad esempio, contenuto passivo) non ricevono l'autorità dell'origine. Il contenuto che porta l'autorità della sua origine riceve l'accesso agli oggetti e alle risorse di rete all'interno della propria origine. A questo contenuto viene anche concesso un accesso limitato agli oggetti e alle risorse di rete di altre origini, ma questi privilegi cross-origin devono essere progettati con attenzione per evitare vulnerabilità di sicurezza.