La stessa politica di origine (Same Origin Policy o SOP) è una regola applicata dai browser Web, che controlla l’accesso ai dati tra siti Web e applicazioni Web. Senza SOP, qualsiasi pagina Web sarebbe in grado di accedere al DOM di altre pagine. Ciò consentirebbe di accedere a dati potenzialmente sensibili da un’altra pagina Web e di eseguire azioni su altre pagine Web senza il consenso dell’utente.

SOP non è uno standard Internet o una regola fissa ma piuttosto una politica generale di sicurezza del browser. Viene interpretato in modo diverso da diversi browser. Funziona anche in modo diverso per diverse tecnologie, ad esempio per i cookie. Tuttavia, l’idea generale rimane la stessa: aiutare a garantire che non vi sia un accesso non autorizzato tra siti.

Qual è l’origine

In termini Web, l’origine è un insieme di caratteristiche comuni di una risorsa Web. Nella maggior parte dei casi, l’origine è una combinazione di tre elementi: lo schema (protocollo), il nome host (dominio / sottodominio) e la porta. Pertanto, tutte le risorse identificate dallo schema: nomehost / qualunque: porta hanno la stessa origine. Tuttavia, anche se uno dei tre elementi è diverso, i browser moderni come Google Chrome o Mozilla Firefox considerano le risorse di origine diversa. Solo nel caso di Microsoft Internet Explorer, la porta non è considerata parte dell’origine. Per esempio:

  • http://www.example.com/page.html e http://www.example.com/subpage/page2.html I documenti HTML hanno la stessa origine: il protocollo è HTTP, il dominio è www.example.com, e la porta è 80.
  • http://www.example.com/page.html e https://www.example.com/page.html hanno origini diverse a causa di un protocollo diverso (HTTP vs HTTPS).
  • http://www.example.com/page.html e http://example.com/page.html hanno origini diverse: il sottodominio (nome host) è diverso (www.example.com vs example.com).
  • http://www.example.com/page.html e http://www.example.com/page.html:8080 hanno un’origine diversa a causa di una porta diversa (80 vs 8080). Tuttavia, in Internet Explorer, hanno la stessa origine.

Quando viene applicata la stessa politica di origine

I controlli di origine vengono applicati dal browser in ogni caso di potenziale interazione tra elementi di origini diverse. Questo include, ma non è limitato a:

  • Codice JavaScript e Document Object Model (DOM), ad esempio, una pagina non può accedere al contenuto del suo iframe a meno che non siano della stessa origine.
  • I cookie, ad esempio, i cookie di sessione per un determinato sito non possono essere inviati a una pagina con origini diverse. Tuttavia, nel caso dei cookie, lo schema e la porta non vengono valutati, solo il dominio / sottodominio.
  • Chiamate AJAX (XmlHTTPRequest).

Tuttavia, SOP non elimina completamente l’interazione tra origini diverse. Il browser valuta se questa interazione può rappresentare una minaccia e, in caso contrario, è consentita. Per esempio:

  • Di solito puoi scrivere tra le origini. Ad esempio, è possibile creare collegamenti tra le origini e inviare i moduli tra le origini.
  • Di solito è possibile incorporare tra le origini. Ad esempio, è possibile utilizzare il contenuto di un’origine diversa in un iframe (se X-Frame-Options lo consente) o incorporare un img, un css o uno script da un altro sito.
  • Tuttavia, la lettura tra le origini è generalmente bloccata. Ciò significa spesso che è possibile inviare una richiesta tra origini ma non è possibile leggere la risposta.

Come allentare SOP

In alcuni casi, potresti voler allentare la stretta presa di SOP e consentire determinate interazioni tra le origini, ad esempio tra domini diversi che appartengono entrambi a te. In tali casi, è possibile garantire che SOP non ostacoli le funzionalità di interazione tra domini dell’applicazione Web in diversi modi.

Dichiarare l’origine

Il modo più semplice per modificare l’origine del tuo sito è dichiararlo utilizzando JavaScript:

document.domain = “example.com”;

Tuttavia, questo è possibile solo per siti all’interno della stessa gerarchia di domini. In caso contrario, qualsiasi sito potrebbe fingere di avere la tua origine. Puoi utilizzare questo semplice metodo, ad esempio, se hai diversi micrositi che utilizzano diversi sottodomini come login.example.com, blog.example.com, ecc.

Condivisione delle risorse tra le origini

La condivisione di risorse tra origini (CORS) è un meccanismo HTTP che utilizza le intestazioni HTTP per definire le autorizzazioni di origine. Utilizzando le intestazioni CORS, puoi informare il browser che le risorse di un’altra origine hanno i diritti per accedere alle risorse sulla tua pagina.

Ad esempio, una richiesta GET a un sito può essere inviata con un’intestazione di richiesta Origin che dichiara l’origine esatta (simile a document.domain):

GET / HTTP/1.1
Host: www.example.com
(…)
Origin: http://example2.com

In risposta, la risorsa che supporta CORS invierà un’intestazione di risposta Access-Control-Allow-Origin:

HTTP/1.1 200 OK
(…)
Access-Control-Allow-Origin: http://example2.com
(…)

L’intestazione Access-Control-Allow-Origin può dichiarare una singola origine, un elenco di origini o un carattere jolly (*). Ovviamente, l’uso di caratteri jolly è molto rischioso, ma comunque per lo sviluppatore di applicazioni web.

Richieste di verifica preliminare (Preflight request)

Lo schema semplice sopra è utilizzato per le richieste che il browser Web considera sicure. Per richieste più rischiose, il browser Web si assicura innanzitutto che la comunicazione tra le origini sia consentita utilizzando una richiesta di verifica preliminare speciale. Preflight è richiesto nei seguenti casi:

  • Se nella richiesta è presente un’intestazione HTTP personalizzata (qualsiasi altra intestazione eccetto Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width).
  • Se il metodo della richiesta è PUT, DELETE, CONNECT, OPTIONS, TRACE o PATCH.
  • Se la richiesta è una richiesta POST ma il Content-Type non è text / plain, multipart / form-data o application / x-www-form-urlencoded.
  • Se XMLHttpRequestUpload ha almeno un listener di eventi registrato su di esso.
  • Se si utilizza un oggetto ReadableStream nella richiesta.

La richiesta di verifica preliminare è una richiesta OPTIONS con intestazioni CORS:

OPTIONS / HTTP/1.1
Host: www.example.com
(…)
Origin: http://example2.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-CUSTOM, Content-Type

In risposta, il server comunica al browser quali metodi sono consentiti, se accetta le intestazioni e per quanto tempo è valida la richiesta di verifica preliminare:

HTTP/1.1 204 No Content
(…)
Access-Control-Allow-Origin: http://example2.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-CUSTOM, Content-Type
Access-Control-Max-Age: 86400

Una volta completata la verifica preliminare, è possibile inviare richieste regolari con le intestazioni CORS.

SOP è abbastanza per prevenire gli attacchi?

La stessa politica di origine aumenta di per sé la sicurezza, ma non è sufficiente per prevenire tutti gli attacchi CSRF (Cross-Site Request Forgery), che in sostanza sono un tentativo di sfruttare origini diverse. Questo è il motivo per cui i token anti-CSRF dovrebbero essere ancora utilizzati come ulteriore forma di protezione. SOP è anche completamente inutile come metodo di protezione contro Cross-site Scripting (XSS) perché dovrebbe limitare il caricamento di script da siti diversi e ciò ostacolerebbe completamente la funzionalità delle applicazioni web.

Pertanto, sebbene SOP sia un efficace mezzo di protezione contro l’ovvio, non può essere considerato un meccanismo di protezione infallibile.
Tuttavia, è un meccanismo che gli sviluppatori Web devono comprendere e utilizzare.