Cosa impedisce al codice dannoso di falsificare l'intestazione "Origin" per sfruttare CORS?

142

Per come lo capisco, se uno script sul lato client in esecuzione su una pagina da foo.com vuole richiedere dati da bar.com, nella richiesta deve specificare l'intestazione Origin: http://foo.come la barra deve rispondere Access-Control-Allow-Origin: http://foo.com.

Cosa c'è per impedire al codice dannoso del sito roh.com di falsificare semplicemente l'intestazione Origin: http://foo.comper richiedere pagine dalla barra?

— Jay Lamont
fonte

Credo che il punto sia che il dominio originale da cui viene pubblicata la pagina (qui, foo.com) deve fornire l' Access-Control-Allow-Originintestazione, altrimenti il browser non consente la richiesta bar.com.

— Chris Hayes,

La lettura di questo post mi ha davvero aiutato a comprendere il processo cors tra browser, server di origine e server di destinazione. html5rocks.com/en/tutorials/cors

— brendonparker

@ChrisHayes Non è affatto così che funziona CORS. Puoi leggere un po 'di più su questo guardando le specifiche , o questa fantastica pagina wiki MDN sull'argomento .

— Ray Nicholus,

@brendonparker Sì, è un ottimo articolo. Quell'autore risponde a molte domande CORS su SO e mantiene inoltre enable-cors.org .

— Ray Nicholus,

@RayNicholus Interessante, ero chiaramente lontano. Grazie per i collegamenti. A giudicare dai voti sul mio commento, non sono l'unico a soffrire sotto questa illusione. Spero che quei due tornino e imparino (e rimuovano i loro voti!).

— Chris Hayes,

Risposte:

149

I browser hanno il controllo dell'impostazione Origindell'intestazione e gli utenti non possono ignorare questo valore. Quindi non vedrai l' Originintestazione falsificata da un browser. Un utente malintenzionato potrebbe creare una richiesta di arricciatura che imposta manualmente l' Originintestazione, ma questa richiesta proviene dall'esterno di un browser e potrebbe non disporre di informazioni specifiche del browser (come i cookie).

Ricorda: CORS non è sicurezza. Non fare affidamento su CORS per proteggere il tuo sito. Se stai fornendo dati protetti, utilizza cookie o token OAuth o qualcosa di diverso Origindall'intestazione per proteggere tali dati. L' Access-Control-Allow-Originintestazione in CORS determina solo quali origini dovrebbero essere autorizzate a fare richieste di origine incrociata. Non fare affidamento su di esso per qualcosa di più.

— Monsur
fonte

Questo ha molto senso. Se il browser non consente a JavaScript di sovrascrivere l'intestazione Origin, non ci sono problemi. Se stai eseguendo richieste dall'esterno del browser, non avrai i cookie. Immagino di essere stato confuso perché in tutti i documenti che stavo leggendo, da nessuna parte è stato detto esplicitamente che l'intestazione Origin non poteva essere ignorata. Grazie!

— Jay Lamont,

Se qualcuno vuole falsificare qualcosa, allora può farlo. Usando praticamente qualsiasi linguaggio di scripting possono costruire richieste http. Perl e Python hanno librerie http che lo rendono abbastanza semplice. Le librerie memorizzano e inviano i cookie, consentono di aggiungere intestazioni arbitrarie e fornire molte informazioni di debug. Quindi le intestazioni CORS sono solo per rendere più difficile il javascript dannoso su un forum che leggi per fare qualcosa di brutto sul tuo conto bancario su un altro dominio quando accedi a entrambi nel tuo browser.

— Mnebuerquo,

E solo per chiarire, l'utente malintenzionato potrebbe semplicemente generare un'istanza del browser che è stata patchata per consentire loro il controllo manuale sull'intestazione Origin e quindi impersonare perfettamente un utente normale, i cookie, AJAX e tutto il resto.

— Jordan Rieger,

"I browser hanno il controllo dell'impostazione dell'intestazione Origin e l'utente non può ignorare questo valore." Sono sicuro che è molto facile usare uno strumento come Fiddler2 o Charles per modificare le intestazioni una volta che la richiesta lascia il browser.

— Asa,

l'utente malintenzionato potrebbe semplicemente generare un'istanza del browser che è stata patchata per consentire loro il controllo manuale sull'intestazione Origin Se si ha accesso alla macchina al punto in cui è possibile "generare semplicemente un'istanza del browser patchata" (in realtà non sembra così semplice per me), perché non leggere direttamente i cookie dal disco? Sono memorizzati in testo normale che conosci. Nella vita reale, lo scripting tra siti è una vera minaccia, mentre il tuo scenario di attacco è solo inventato e poco pratico.

— Stijn de Witt,

TLDR: non c'è nulla che impedisce al codice dannoso di falsificare l'origine. Quando ciò accade, il tuo server non lo saprà mai e agirà sulle richieste. A volte queste richieste sono costose. Quindi non utilizzare CORS al posto di alcun tipo di sicurezza.

Di recente ho giocato con CORS e mi sono posto la stessa domanda. Quello che ho scoperto è che il browser potrebbe essere abbastanza intelligente da conoscere una richiesta CORS falsificata quando ne vede una, ma il tuo server non è così intelligente.

La prima cosa che ho scoperto è che l' Originintestazione è un nome di intestazione proibito HTTP che non può essere modificato a livello di codice. Ciò significa che puoi modificarlo in circa 8 secondi usando Modifica intestazioni per Google Chrome .

Per verificarlo, ho impostato due domini Client e un dominio Server. Ho incluso una whitelist CORS sul server, che ha consentito le richieste CORS dal client 1 ma non dal client 2. Ho testato entrambi i client, e in effetti le richieste CORS del client 1 hanno avuto successo mentre il client 2 ha fallito.

Quindi ho falsificato l' Originintestazione del client 2 in modo che corrispondesse a quella del client 1. Il server ha ricevuto l' Originintestazione contraffatta e ha superato con successo il controllo della whitelist (o non è riuscito se sei un tipo mezzo vuoto). Successivamente, il server ha funzionato rispettosamente consumando tutte le risorse che è stato progettato per consumare (chiamate al database, invio di e-mail costose, invio di messaggi sms ancora più costosi, ecc.). Fatto ciò, il server ha rispedito felicemente l' Access-Control-Allow-Originintestazione contraffatta al browser.

La documentazione che ho letto afferma che il Access-Control-Allow-Originvalore ricevuto deve corrispondere Originesattamente al valore inviato nella richiesta. Hanno abbinato, quindi sono rimasto sorpreso quando ho visto il seguente messaggio in Chrome:

XMLHttpRequest non può essere caricato http://server.dev/test. L'intestazione "Access-Control-Allow-Origin" ha un valore http://client1.dev che non è uguale all'origine fornita. http://client2.dev Pertanto, Origin non può accedere.

La documentazione che ho letto non sembra essere accurata. La scheda di rete di Chrome mostra chiaramente sia le intestazioni di richiesta che di risposta http://client1.dev, ma puoi vedere nell'errore che Chrome in qualche modo conosce la vera origine http://client2.deve rifiuta correttamente la risposta. Il che non importa a questo punto perché il server aveva già accettato la richiesta falsificata e speso i miei soldi.

— Nocturno
fonte

@ Notturno, grazie per l'esempio. Vorrei solo aggiungere la mia osservazione. CORS si riferisce alle funzionalità di sicurezza del browser. Se un browser sicuro viene modificato dal suo stato originario, ciò potrebbe essere interpretato in quanto il browser probabilmente non ha una funzione di sicurezza.

— Luka Žitnik

Per niente brillante. Manca completamente il punto di CORS. Se sei in grado di intercettare richieste provenienti dal computer dell'utente, puoi semplicemente leggere i loro cookie, installare keylogger, virus e tutte quelle altre minacce reali. CORS è lì per proteggere gli utenti onesti che hanno effettuato l'accesso al sito A da uno script dannoso che in qualche modo è stato iniettato nel sito B. Lo script sul sito B (che potrebbe essere uno snippet di Javascript in un post del forum che non è stato salvato correttamente dal sito B) esegue azioni sul sito A sotto l'account dell'utente (ad es. eliminare elementi, ecc.), utilizzando il cookie di sessione dal sito A.

— Stijn de Witt,

Questo si chiama cross-site scripting e senza CORS si potrebbe fare senza mai avere il controllo della macchina dell'utente. Questo è il punto. Non era necessario alcun controllo sulla macchina dell'utente perché, quando si effettuavano richieste al sito A, il browser usava aggiungere automaticamente il cookie di sessione alla richiesta in modo che sembrasse una richiesta valida dell'utente stesso quando in realtà proveniva da uno script su qualche altro posto. La politica della stessa origine lo impedisce e CORS viene utilizzato per autorizzare i domini a cui dovrebbe essere concesso l'accesso anche se si trovano su un'origine diversa.

— Stijn de Witt,

@Nocturno Sì, forse ero un po 'troppo rozzo, mi dispiace per quello. Il tuo punto originale è valido. La politica Same-Origin è una funzionalità di sicurezza del browser e CORS è un meccanismo per indebolire tale sicurezza autorizzando alcuni domini. OP deve capire che lo spoofing dell'intestazione Origin non è realmente praticabile come un 'attacco' poiché non ti porta nulla che non si possa avere con, ad esempio, il ricciolo.

— Stijn de Witt,

@ Notturno Penso che la tua dichiarazione di apertura sia un po 'fuorviante. There's nothing stopping malicious code from spoofing the origin-> Sì, non è possibile impostare JavaScript Origin. Sì, un utente può modificare il proprio browser / utilizzare il violinista per cambiare origine, ma non è ciò che CORS sta difendendo; I siti Web controllati dagli aggressori non possono cambiare Origin, il che è tutto ciò che conta.

— RJFalconer,

Solo un umile riassunto:

D: La stessa politica di origine (SOP) viene applicata solo dai browser?
A: Sì. Per tutte le chiamate effettuate all'interno di un browser, l'SOP viene sicuramente applicato dal browser. Il server potrebbe o meno verificare l'origine della richiesta.

D: Se una richiesta non è conforme a SOP, il browser la blocca?
A: No, va oltre l'autorità dei browser. I browser inviano semplicemente richieste di origine incrociata e attendono la risposta per vedere se la chiamata viene segnalata dal server tramite le Access-Controlintestazioni - *. Se il server non restituisce l' Access-Control-Allow-Originintestazione, non riecheggia l'origine del chiamante o non restituisce *l'intestazione, tutto ciò che un browser farà è astenersi dal fornire la risposta al chiamante.

D: Significa che non posso fare lo spoofing Origin?
A: Nel browser e utilizzando gli script, non è possibile eseguire Originl' override poiché è sotto il controllo del browser. Tuttavia, se vuoi hackerarti, puoi manomettere le chiamate che escono dal TUO browser usando le estensioni del browser o altri strumenti che installi sul tuo computer. È anche possibile emettere HTTPle chiamate utilizzando curl, Python, C#, ecc e alterare Originl'intestazione ai server trucco.

D: Quindi, se posso ingannare il server alterando Origin, significa che CORSnon è sicuro?
A: di CORS per sé tace sulla sicurezza, vale a dire l'autenticazione e l'autorizzazione delle richieste. Spetta ai server ispezionare le richieste e autenticarle / autorizzarle con qualsiasi meccanismo con cui lavorano come cookie e intestazioni. Detto questo, può proteggerci un po 'di più in caso di attacchi come XSS:

Esempio: supponiamo che tu abbia effettuato l'accesso al tuo sito Web e uno script dannoso tenti di inviare una richiesta al sito Web della tua banca per verificare il tuo saldo: un attacco XSS riflesso . Il sito Web della tua banca si fida delle credenziali provenienti da (qui per conto di) il tuo sito Web in modo che la richiesta venga autenticata e HTTPvenga emessa una risposta mirante al codice dannoso. Se il sito Web della tua banca non si preoccupa di condividere i suoi endpoint con altre origini, non includeAccess-Control-Allow-Originintestazione nella risposta. Ora, all'arrivo della richiesta, il browser si rende conto che la richiesta era una richiesta di Cross Origins, ma la risposta non mostra che il server è stato felice di condividere la risorsa (qui l'endpoint della query del saldo) con il tuo sito Web. Quindi interrompe il flusso, quindi il risultato restituito non raggiungerà mai il codice dannoso.

— Alireza
fonte

Bello, migliore / più chiaro della risposta accettata IMO

— 3dGrabber