JSONP è sicuro da usare?

Question

Ci sono problemi di sicurezza che dovrebbero essere considerati quando si usa JSONP?

Answer 1

Aggiornamento: JSONP è un trucco comune per eseguire richieste tra domini. I browser moderni ora hanno Cross Source Resource Sharing e IE8 + hanno XDomainRequest che è simile. Vedi http://enable-cors.org/ per maggiori informazioni.

JSONP è solo uno script include che consente di utilizzare una richiamata. Si dovrebbe tuttavia essere a conoscenza di Cross-site request forgery (CSRF).

Finché si controlla lo script e il server, JSONP non è più insicuro rispetto a uno script incluso. A meno che non si disponga di un servizio JSONP che restituisce dati sensibili agli utenti registrati. Un sito dannoso può inviare una richiesta al servizio (sperando che l'utente abbia effettuato l'accesso sul tuo sito) e recuperare i dati. Il servizio può controllare il referrer della richiesta, ma è possibile falsificare il referrer usando il flash (grazie Chris Moschini).

Immagina questo senario: - Un utente accede al suo account di internet banking. Memorizzazione di un cookie di sessione nel browser degli utenti. Questo sito ha un servizio jsonp con informazioni sensibili sull'utente e sui suoi account. - Altri siti non sapranno che l'utente ha effettuato l'accesso, ma potrebbero fare un'ipotesi e provare ad accedere al servizio jsonp. Poiché l'utente ha un cookie di sessione, il browser riceverà una risposta e non c'è nulla che impedisca al sito di eseguire un post su Ajax per salvare i dati sensibili sul proprio server.

Aggiornamento 28 giugno 2012: Se si desidera proteggere da CSRF attacchi si dovrebbe leggere questo in profondità post sul blog da un esperto di sicurezza: http://erlend.oftedal.no/blog/?blogid=130

Answer 2

Sì, è necessario stare attenti, ma se usato correttamente con servizi affidabili è relativamente sicuro.

Ecco una sintesi dei problemi di sicurezza con JSONP, se ho capito bene:

Dal punto di vista del consumatore:

• Devi fidarti il ​​provider di non ritorno doloso JavaScript invece che l'atteso JSON avvolto nel callback JSONP specificato.
• Lo stesso vale anche per qualsiasi componente aggiuntivo incorporato di JavaScript di terze parti, come Google Analytics.
• È simile agli attacchi XSS in quanto consente a una terza parte di eseguire JavaScript arbitrario nella propria applicazione, tuttavia, è necessario prima scegliere di affidarsi a tale terza parte effettuando la richiesta in primo luogo.

Dal punto di vista del fornitore:

• non si deve supporre che anche se biscotto (s) dei clienti sono presenti nella richiesta che il consumatore è una pagina web sotto il vostro controllo. Controlla l'intestazione del Referer su una whitelist di URL autorizzati e/o non fare affidamento sull'autenticazione basata su cookie.
• Analogo a un attacco del CSRF/confuso.

Answer 3

Ci sono problemi di sicurezza per entrambe le parti. Il più serio è per il sito incluso JSONP.

Se si include un da un altro dominio (che non si controlla), tale dominio può modificare lo script in qualsiasi momento. Possono fare il javascript fare qualsiasi cosa nel contesto della tua pagina web, che il tuo javascript potrebbe fare. Non c'è modo di aggirare questo se usi JSONP. Dovresti esaminare le comunicazioni tra domini utilizzando iframe, operazione che viene eseguita al meglio dall'eccellente libreria EasyDXM.

Se si offre un servizio Web che gestisce JSONP, è necessario proteggere da Cross-Site Request Forgery (CSRF). È qui che il tuo servizio web restituisce informazioni riservate agli utenti che hanno effettuato l'accesso. Se un utente ha effettuato l'accesso al tuo sito, qualsiasi altro sito può generare una richiesta GET al servizio JSONP e i cookie del dominio TU vengono inviati con la richiesta, in pratica, autenticare l'utente che ha effettuato l'accesso, tranne che ora, il remoto il dominio riceve la risposta ed è in grado di leggere i dati sensibili!

Il modo migliore per proteggersi da CSRF è generare un nonce (un numero generato a caso, generato casualmente) e memorizzarlo nella sessione. Emetti questo nonce in tutti i tuoi moduli sulle tue pagine web e includilo in tutte le richieste JSONP sulle tue pagine. Sul server, assicurati che il nonce sia presente e corretto nella richiesta (che sia GET, POST, ecc.) Altri domini non saranno in grado di indovinare questo nonce, e quindi non in grado di ottenere le informazioni sensibili, nonostante i cookie è stato mandato.

Infine, esiste un altro tipo di problema di sicurezza: JSONP semplicemente non supporta l'autenticazione dell'utente nel browser, del tipo che è possibile con OAuth. Ovviamente è possibile ottenere dal server una sorta di token di accesso (come con OAuth) e utilizzarlo. Tuttavia, se si desidera eseguire l'autenticazione interamente nel browser, è necessario utilizzare la comunicazione tra domini con iFrame. Penso che questo sia il modo in cui OAuth 2.0 lo fa. Ecco come lo configuri: le pagine ospitate sul tuo sito hanno pieno accesso al tuo server. Avere una libreria javascript che carica EasyDXM e la usa per impostare un iframe nascosto sul tuo sito e parlarne usando questo.

Answer 4

soluzione! soluzione!

Mi viene da pensare che esista un haframe crossdomain che non esegue il codice che viene, ma consente di passare una variabile. Perché non usarlo per avvolgersi per sicurezza? ...

E sì, qualcuno ha questa idea prima, come al solito :)

http://beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/

E c'è anche window.postMessage, che è sicuro e non hacky