Quali sono i rischi per la sicurezza nell'utilizzo di XMLHttpRequest tra domini diversi?

Question

In molti luoghi ho visto persone parlare della XMLHttpRequest di Cross-Domain, che non è possibile, a causa di alcuni motivi di sicurezza . Tuttavia, non ho trovato un post che indichi quali sono i motivi di sicurezza in realtà?

Le persone hanno menzionato che JSONP è una delle buone alternative. Un'altra alternativa sarebbe utilizzare le intestazioni Origin e Access-Control-Allow-Origin.

Tuttavia, voglio solo sapere quali problemi di sicurezza possono essere generati a causa dell'uso di XMLHttpRequest tra domini diversi?

Answer 1

Penso che sarebbe meglio rispondere alla tua domanda su un esempio di PERCHE 'sarebbe terribilmente male.

Si visita il mio sito Web (esempio.org). Carico uno script che rende una richiesta AJAX lato client a facebook.com/messages/from/yourgirlfriend. Ti è capitato di accedere a Facebook e il tuo browser dice a Facebook che la mia richiesta è effettivamente te. Facebook dà felicemente alla mia richiesta quel messaggio sulle strane cose sessuali che vuoi provare. Ora so cose su di te che probabilmente non volevi che lo sapessi.

Questa, ovviamente, è un'esagerazione esagerata, e per fortuna non è possibile grazie alla stessa politica di origine.

Non ti senti più al sicuro ora?

Answer 2

Se consentito, un utente malintenzionato che riesce a inserire JavaScript nella tua pagina (tramite exploit/social engineering) può inviare dati (generalmente sensibili) che vengono acquisiti dai tuoi client senza che questi lo sappiano (poiché XMLHttpRequests non richiede le azioni dell'utente si verificano e sono silenziose). È una misura di sicurezza del browser.

JSONP è solo un'opera attorno a questa misura di sicurezza, in cui si fornisce alla destinazione una richiamata e si affida a ciò che restituirà attraverso questa richiamata.

EDIT: Esempi di un rischio per la sicurezza: si effettua il login al proprio account di posta elettronica attraverso il web (come Gmail o Yahoo). Continui a navigare (in un'altra scheda o anche nella scheda attuale) in un altro sito dannoso. Questo sito dannoso tenta di eseguire XHR nello stesso sito Web del tuo account di posta elettronica. Poiché XHR è sul tuo comportamento, e dal momento che si tratta di una richiesta client/browser, questa richiesta avrà la stessa sessione utilizzata per l'accesso e, pertanto, questo sito Web può fare tutto ciò che desidera con il tuo account (inviare una mail spam attraverso il tuo account, scarica i tuoi contatti, ... ecc.). Un altro esempio: in un forum, qualcuno riesce a iniettare Javascript con XHR su un altro sito web. Ora può rubare la lista dei contatti (e magari cancellarli) da tutte le persone che visitano il suo post nel forum (usando la stessa sessione della tua email web). Per non parlare del fatto che può condividere la sessione dei membri del forum visitando il suo post per ottenere tutti i dati che hanno nel forum (messaggi privati ​​/ amici..etc). Può quindi inviare questi dati al suo server per salvarli.

Answer 3

Senza questi "motivi di sicurezza" l'intera Internet come tu sai non potrebbe esistere. In effetti andrò su un arto e dico che c'è nessuna regola che è più importante per la sicurezza di Internet della politica di origine identica.

Nessuna pagina Web può disporre di autenticazione senza queste regole, google, account di posta Web, SO, nessuna di queste potrebbe esistere. Sarebbe come se avessi XSS su ogni dominio. Puoi eseguire un XHR contro gmail.com e leggere la posta di chiunque. I token CSRF non funzionerebbero perché potresti leggere qualsiasi pagina e falsificare la richiesta.

Non esiste un'unica politica di origine, ma le regole sono chiaramente definite nello Google Browser Security handbook. Questi sono molto logici e le regole per le varie piattaforme sono molto simili, perché questo è il modo in cui Internet deve funzionare.

Effettuando un Access-Control-Allow-Origin: * si sta perdendo i diritti concessi all'utente dai browser Web per tale pagina. Questo ha importanti implicazioni sulla sicurezza. Non sarai in grado di proteggerti da CSRF usando i token. Un capthca potrebbe mitigare questo problema, anche il controllo del referente potrebbe anche aiutare (sarà vuoto se l'origine è HTTPS). Dovresti leggere lo CSRF prevention cheat sheet.