politica same-origin e CORS: qual è il punto?

Question

Ho qualche problema a capire la politica della stessa origine e i diversi modi per "risolverlo".

È chiaro che la politica della stessa origine esiste come misura di sicurezza, quindi uno script che proviene da un server/dominio non ha accesso ai dati provenienti da un altro server/dominio.

È anche chiaro che a volte è utile essere in grado di violare questa regola, ad esempio un'applicazione di mashup accede a informazioni da diversi server per creare i risultati desiderati. E uno dei modi per farlo è CORS.

1) Se non sbaglio, CORS permette il server di destinazione dire al browser "è ok per voi di prendere i dati/codice da me" con l'aggiunta di alcune intestazioni nella risposta. Ma, se questo è corretto, ciò significa che un server malevolo potrebbe semplicemente aggiungere questa intestazione e il browser consentirebbe il recupero di qualsiasi dato o codice, potenzialmente dannoso, proveniente da quel server.

2) Dall'altra parte, abbiamo JSONP, che ci consente di recuperare codice o dati arbitrari da un server senza CORS abilitato, evitando così l'obiettivo principale del SOP. Quindi, ancora una volta, un server malevolo in grado di gestire JSONP è in grado di iniettare dati o codice anche con il SOP cablato nel browser.

Quindi le mie domande sono:

La seconda argomentazione è corretta? È la decisione del server se il browser deve accettare i contenuti? La seconda argomentazione è corretta? È, ancora una volta, non nella decisione del browser se accettare o meno i dati?

JSONP non rende SOP inutile?

Grazie per avermi illuminato !!

Answer 1

La cosa importante da notare qui è che se l'utente è connesso a un sito http://example.com/ e la richiesta http://example.com/delete?id=1 cancella un post da parte dell'utente, quindi il seguente codice cancellerà postale dell'utente:

<script src="http://example.com/delete?id=1" /> 

Questo è chiamato attacco CSRF/XSRF (falsificazione di richieste cross-site). Questo è il motivo per cui la maggior parte delle applicazioni web lato server chiedere un biglietto di transazione: invece di http://example.com/delete?id=1 quello che dovete fare http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Ora il seguente attacco non funzionerà:

<script src="http://example.com/delete?id=1" /> 

... perché non lo fa contiene il parametro txid. Ora, consideriamo cosa succede se è possibile accedere al sito utilizzando XmlHttpRequest. Lo script in esecuzione sul browser dell'utente potrebbe dietro la schiena dell'utente recuperare e analizzare http://example.com/pageThatContainsDeleteLink, estrarre il TxID e quindi richiedere http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Ora, se XmlHttpRequest non può accedere a siti aventi una diversa origine, l'unico modo per cercare di recuperare il TxID sarebbe essere quello di cercare di fare qualcosa di simile:

<script src="http://example.com/pageThatContainsDeleteLink" /> 

... ma non aiuta come il risultato è una pagina HTML, non un pezzo di codice JavaScript. Quindi, c'è un motivo per cui è possibile includere lo <script>: s da altri siti ma non accedere ad altri siti tramite XmlHttpRequest.

Si può essere interessati a leggere questo: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Questo attacco ha funzionato contro Gmail di nuovo nel corso della giornata e ha permesso che si può riaccedere mail degli utenti da codice JavaScript in esecuzione su un altro sito. Tutto ciò dimostra che il modello di sicurezza del WWW è molto sottile e non ben pensato. Si è evoluto invece di essere ben progettato.

Come per la tua domanda: sembra che il server http://example.com/ sia malevolo. Questo non è il caso. Utilizzando le notazioni della mia risposta, http://example.com/ è il server che è la destinazione dell'attacco e http://attacker.com/ è il sito dell'utente malintenzionato. Se http://example.com/ apre la possibilità di inviare richieste usando JSONP o CORS, è vero che potrebbe diventare vulnerabile all'attacco CSRF/XSRF che ho appena descritto. Ma ciò non significa che altri siti potrebbero diventare vulnerabili all'attacco. Allo stesso modo, se http://attacker.com/ apre la possibilità di inviare richieste utilizzando JSONP o CORS, il sito dell'aggressore diventa vulnerabile a un attacco CSRF/XSRF. Pertanto, un amministratore di server disinformato può aprire un buco nel proprio sito ma non influisce sulla sicurezza di altri siti.