Che cosa rende ajax non sicuro il cross domain?

Question

Non sono sicuro di capire quali tipi di vulnerabilità causano.

Quando ho bisogno di accedere ai dati da un'API, devo usare ajax per richiedere un file PHP sul mio server e che il file PHP accede all'API. Cosa rende questo più sicuro del semplice fatto di permettermi di colpire direttamente l'API con ajax?

Se è per questo, sembra che usando JSONP http://en.wikipedia.org/wiki/JSONP puoi fare tutto ciò che ajax ti permetterebbe di fare.

Qualcuno potrebbe illuminarmi?

Answer 1

Penso che tu abbia frainteso il problema che la politica della stessa origine sta cercando di risolvere.

Immagina di essere connesso a Gmail e che Gmail disponga di una risorsa JSON, http : //mail.google.com/information-about-current-user.js, con informazioni sull'utente che ha effettuato l'accesso. Questa risorsa è presumibilmente pensata per essere utilizzata dall'interfaccia utente di Gmail, ma, se non fosse per la politica di origine identica, qualsiasi sito che ho visitato e sospettava che potessi essere un utente Gmail, poteva eseguire una richiesta AJAX per ottenere quella risorsa come me e recuperare informazioni su di me, senza che Gmail sia in grado di fare molto su di esso.

Quindi la politica della stessa origine non è quella di proteggere la pagina PHP dal sito di terze parti; e non è per proteggere qualcuno che visita la tua pagina PHP dal sito di terze parti; piuttosto, è per proteggere qualcuno che visita la tua pagina PHP, e qualsiasi sito di terze parti a cui hanno accesso speciale, dalla tua pagina PHP. (L'accesso speciale può essere dovuto a cookie, HTTP AUTH o una whitelist di indirizzi IP o semplicemente essere sulla rete giusta — forse qualcuno lavora alla NSA e sta visitando il tuo sito, questo non significa che dovresti essere in grado di attivare un dump di dati da una pagina interna NSA.)

JSONP elabora questo in modo sicuro, introducendo una diversa limitazione: funziona solo se la risorsa è JSONP. Pertanto, se Gmail vuole che una determinata risorsa JSON sia utilizzabile da terze parti, può supportare JSONP per tale risorsa, ma se desidera che tale risorsa sia utilizzabile dalla propria interfaccia utente, può supportare solo JSON normale.

Answer 2

Con lo scripting cross-site si avrebbe quindi una pagina Web che sarebbe in grado di estrarre dati da qualsiasi luogo e quindi essere in grado di eseguire nello stesso contesto degli altri dati sulla pagina e in teoria avere accesso al cookie e altre informazioni sulla sicurezza a cui non si desidera dare l'accesso. Lo scripting cross-site sarebbe molto insicuro in questo senso poiché sarebbe possibile accedere a qualsiasi pagina e, se consentito, lo script su quella pagina potrebbe semplicemente caricare dati da qualsiasi luogo e quindi avviare l'esecuzione di codice errato, quindi il motivo non è consentito.

JSONP sull'altra mano consente di ottenere dati in formato JSON poiché si fornisce il callback necessario per l'inoltro dei dati, quindi fornisce la misura del controllo in quanto i dati non verranno eseguiti dal browser a meno che non sia richiamata la funzione esegue ed esegue o tenta di eseguirla. I dati saranno in un formato JSON che potrai quindi fare ciò che desideri, tuttavia non verrà eseguito, quindi è più sicuro e quindi è consentito.

Answer 3

Molti servizi Web non sono costruiti per resistere a XSRF, quindi se un sito Web può caricare a livello di codice dati utente tramite una richiesta che trasporta i cookie tra domini solo in virtù dell'utente che ha visitato il sito, chiunque abbia la capacità di eseguire javascript può rubare dati utente.

CORS è un'alternativa sicura pianificata a XHR che risolve il problema tramite not carrying credentials by default. Le specifiche CORS spiegano il problema:

Gli agenti utente applicano comunemente le restrizioni della stessa origine alle richieste di rete. Queste restrizioni impediscono a un'applicazione Web lato client in esecuzione da un'origine di ottenere dati recuperati da un'altra origine e limitano anche le richieste HTTP non sicure che possono essere avviate automaticamente verso destinazioni diverse dall'origine dell'applicazione in esecuzione.

Nei programmi utente che seguono questo modello, le richieste di rete in genere utilizzano le informazioni di autenticazione ambientale e di gestione delle sessioni, tra cui l'autenticazione HTTP e le informazioni sui cookie.

EDIT:

Il problema con solo facendo il lavoro XHR tra domini è che molti servizi web espongono ambient authority. Normalmente quell'autorità è disponibile solo per il codice dalla stessa origine.

Ciò significa che un utente che si fida di un sito Web si fida di tutto il codice di quel sito Web con i propri dati privati. L'utente considera attendibile il server a cui invia i dati e qualsiasi codice caricato da pagine servite da quel server. Quando le persone dietro un sito Web e le librerie che carica sono affidabili, la fiducia dell'utente è ben posizionata.

Se XHR ha funzionato in modo incrociato e ha caricato i cookie, tale autorizzazione ambientale sarebbe disponibile per codificare chiunque possa offrire un codice all'utente. Le decisioni di fiducia che l'utente ha precedentemente fatto potrebbero non essere più in una posizione favorevole.

CORS non eredita questi problemi perché i servizi esistenti non espongono l'autorizzazione ambientale a CORS.

Answer 4

Il modello di JS->Server(PHP)->API rende possibile e non solo la migliore, ma la pratica essenziale per controllare l'integrità mentre si passa attraverso il server. In aggiunta a ciò, cose come i risolutori locali irritati (ovvero i worm DNS) ecc. Sono molto meno probabili su un server, piuttosto che su qualche client casuale.

Per quanto riguarda JSONP: questo non è un bastone da passeggio, ma una stampella. IMHO potrebbe essere visto come un exploit contro una disfunzione della combo HTML/JS, che non può essere rimosso senza rompere il codice esistente. Altri potrebbero pensare diversamente da questo.

Mentre JSONP permette di eseguire unreflectedly codice somwhere nel vasto mondo cattivo, nessuno forze di farlo. Le implementazioni sane di JSONP usano sempre una sorta di hashing per verificare che il provider di quel codice sia affidabile. Di nuovo gli altri potrebbero pensare diversamente.

Answer 5

Il original XHR non è mai stato progettato per consentire richieste di origine incrociata. Il motivo era una vulnerabilità di sicurezza tangibile che è nota principalmente da CSRF attacks.

In questo scenario di attacco, un sito di terze parti può costringere lo user agent di una vittima a inviare richieste contraffatte ma valide e legittime al sito di origine. Dal punto di vista del server di origine, tale richiesta forgiata non è indiscernibile da altre richieste da parte dell'utente che sono state avviate dalle pagine Web del server di origine. Il motivo è che in realtà è l'agente utente che invia queste richieste e includerebbe automaticamente anche tutte le credenziali come i cookie, l'autenticazione HTTP e persino i certificati SSL sul lato client.

Ora tali richieste possono essere facilmente falsificate: a partire da semplici richieste GET utilizzando <img src="…"> fino alle richieste POST utilizzando i moduli e inviandoli automaticamente.Questo funziona fintanto che è prevedibile come forgiare richieste così valide.

Ma questo non è il motivo principale per vietare richieste di cross-origine per XHR. Perché, come mostrato sopra, ci sono modi per falsificare le richieste anche senza XHR e anche senza JavaScript. No, il motivo principale per cui XHR non consentiva le richieste di origine incrociata è perché sarebbe il JavaScript nella pagina web della terza parte a cui sarebbe inviata la risposta. Quindi non sarebbe solo possibile inviare richieste di origine incrociata ma anche ricevere la risposta che può contenere informazioni sensibili che sarebbero poi accessibili da JavaScript.

Ecco perché la specifica XHR originale non consentiva richieste di origine incrociata. Ma con l'avanzare della tecnologia, ci sono state richieste ragionevoli per supportare richieste di origine incrociata. Ecco perché la specifica XHR originale è stata estesa a XHR level 2 (XHR e XHR livello 2 sono ora uniti) in cui l'estensione principale supporta le richieste di origine incrociata in base a requisiti specifici specificati come CORS. Ora il server ha la possibilità di verificare l'origine di una richiesta ed è anche in grado di limitare il set di origini consentite e l'insieme di metodi HTTP e campi di intestazione consentiti.

Da ora a JSONP: per ottenere la risposta JSON di una richiesta in JavaScript ed essere in grado di elaborarla, dovrebbe essere una richiesta di origine uguale o, nel caso di una richiesta di origine incrociata, il server e l'agente utente dovrebbe supportare CORS (di cui quest'ultimo è supportato solo dai browser moderni). Ma per essere in grado di lavorare con qualsiasi browser, è stato inventato JSONP che è semplicemente una chiamata di funzione JavaScript valida con il JSON come parametro che può essere caricato come JavaScript esterno tramite <script> che, simile a <img>, non è limitato alla stessa origine richieste. Ma oltre a qualsiasi altra richiesta, una richiesta JSONP è anche vulnerabile a CSRF.

Quindi, per concludere che, dal punto di vista della sicurezza: è necessario

• XHR per fare richieste di risorse JSON per ottenere le loro risposte in JavaScript
• XHR2/CORS è tenuto ad effettuare le richieste cross-origine per le risorse JSON per ottenere le loro risposte in JavaScript
• JSONP è una soluzione per aggirare le richieste cross-origine con XHR

Ma anche:

• richieste forgiatura è risibile facile, anche se forgiare le richieste valide e legittime è più difficile (ma spesso abbastanza facile così)
• attacchi CSRF non sono un essere sottovalutati minaccia, in modo da imparare a protect against CSRF