Quali sono i rischi della comunicazione JSONP tra domini diversi?

Question

Nella nostra applicazione web ci siamo imbattuti nella situazione in cui abbiamo bisogno di effettuare chiamate AJAX tra domini da un dominio che controlliamo completamente in un altro dominio che controlliamo completamente. Ho navigato in giro per la soluzione migliore e le due che mi vengono in mente sono un file proxy locale (file locale che utilizza php :: fopen) o jquery/JSONP.

Quando guardo in linea, vedo le persone parlare abitualmente di come sia pericoloso utilizzare JSONP perché qualcuno potrebbe iniettare dati dannosi con esso. Il dilemma è che la maggior parte degli argomenti contro di essa non sembra trattenere molta acqua, quindi vengo qui per chiedere chiarimenti allo Stack.

Quali sono i vettori specifici di attacco che verranno aperti da JSONP tra domini diversi?

Dalla mia comprensione l'unico vettore per JSONP è esattamente lo stesso vettore, che è aperto includendo un tag <script> sul tuo sito il cui src è quello di qualsiasi sito che non è controllato da voi: che potevano girare dannoso e inizia a coltivare sessioni utente/cookie/dati. Se ciò è vero, sembrerebbe che non sia il protocollo (JSONP) a preoccupare, ma piuttosto la fonte da cui i dati vengono raccolti.

Perché se si trattasse di un proxy lato server, un tag <script> o ajax/JSONP, il rischio è che sto inserendo il contenuto di qualcun altro sulla mia pagina e che potrebbero iniziare a organizzare sessioni utente se si sentissero obbligati (in un modo che è esattamente ciò che Google Analytics fa con un tag script).

Molti vettori che ascolto online dipendono dalla convalida errata di moduli e dati inviati dall'utente. Nell'esempio, JSONP viene utilizzato per estrarre alcuni file, che inseriscono i dati in un modulo, quindi il modulo viene inviato per l'inserimento del database. Se i dati di tale modulo sono attendibili, poiché provengono da fonti attendibili (dati JSONP) e inseriti senza convalida, di nuovo non è il JSONP ad essere stato criticato, ma l'input dell'utente convalidato in modo errato. Un utente può fare esattamente le stesse modifiche a quel modulo usando Firebug, ma l'ultima volta che ho controllato nessuno ha chiamato Firebug un vettore di sicurezza.

L'ultimo elemento è la nozione che con il proxy server-side esiste una maggiore capacità di filtrare i risultati prima di passarli al client. Tuttavia, che si tratti di PHP o Javascript, potrei filtrare i risultati per rimuovere elementi come, onclick o iframe. Certo, qualcuno lato client potrebbe alterare la mia funzione javascript per rimuovere il filtro, ma il filtraggio influenzerebbe solo la specifica esperienza del cliente e non verrebbe alterato per altri utenti, impedendo in tal modo un attacco XSS permanente multi-cliente.

Ovviamente, ci sono alcuni vantaggi per il proxy lato server perché renderebbe più semplice la registrazione di potenziali attacchi XSS, ma in termini di prevenzione dell'attacco stesso sia PHP che Javascript sembrano avere utilità adeguate. In un certo senso, sembrerebbe che JSONP sia effettivamente più sicuro di un semplice tag <script> perché almeno con JSONP il risultato passa attraverso una funzione che significa in qualche modo filtrata, piuttosto che solo un trust globale, come avviene con <script>.

C'è qualche rischio che mi manchi o mi stia sfuggendo? Se comprendo correttamente il problema, non vi è alcun rischio per la sicurezza nell'utilizzo di JSONP per includere il contenuto di un file di cui ci fidiamo da una fonte attendibile. È una valutazione accurata?

SOLUZIONE

1. Se entrambe le estremità sono attendibili, non v'è alcun pericolo nel JSONP (è fondamentalmente solo un tag <script>).

2. Entrambi Script/JSONP mantengono le stesse vulnerabilità di sicurezza perché vengono eseguiti automaticamente, anziché semplicemente trasmettere come dati. L'utilizzo di un proxy sul lato server significa che il ritorno tra domini viene passato come dati e può essere filtrato per contenuti dannosi. Se il dominio incrociato è completamente affidabile, allora JSONP/SCRIPT è sicuro, se si sospetta il rischio, passarlo attraverso un proxy di filtro.

Answer 1

Quando non controlli entrambe le estremità della richiesta, la maggior parte dei tradizionali sicurezza preoccupazioni per JSONP non sono un problema.

Un ulteriore problema che si verifica è che alcuni utenti bloccano script di terze parti come misura di sicurezza. Ciò bloccherà anche le tue richieste JSONP. L'approccio proxy lato server non ha questo problema.

Answer 2

C'è una GRANDE differenza tra server-side-proxy e <script>/JSONP. Nel primo caso, si scarica dati, in quest'ultimo si scarica e eseguire automaticamentecodice

Quando si crea un server-side-proxy, il codice JavaScript può utilizzare XmlHttpRequest per scaricare dati. Questi dati non verranno eseguiti automaticamente; devi fare esplicitamente qualcosa di stupido, come eval(), per farlo eseguire. Anche se il formato dei dati è JSON e l'altro server è stato compromesso e il proprio proxy server-side non riesce a raggiungere il compromesso, è ancora disponibile una linea di difesa per il codice client. È possibile, ad esempio, analizzare il JSON utilizzando safeJSON parser e rifiutare lo script dannoso.

Ma quando si utilizza JSONP o un tag <script>, si include direttamente il codice di un'altra persona. Poiché il suo codice (e non i dati), il browser lo esegue automaticamente, senza darti la possibilità di ispezionarlo o modificarlo.

In sintesi, sul lato server-proxy offre due ulteriori linee di difesa -

1. capacità di ispezionare dati sul server per contenuti dannosi
2. capacità di ispezionare dati in javascript prima esecuzione, se non del tutto necessario per eseguirlo.