Quali sono i rischi per la sicurezza di impostare Access-Control-Allow-Origin?

Di recente ho dovuto impostare Access-Control-Allow-Origin su * per poter effettuare chiamate ajax su più sottodomini.
Ora non posso fare a meno di sentire che sto mettendo il mio ambiente ai rischi per la sicurezza.
Per favore aiutami se sto sbagliando.

Rispondendo con Access-Control-Allow-Origin: * , la risorsa richiesta consente la condivisione con ogni origine. Ciò significa sostanzialmente che qualsiasi sito può inviare una richiesta XHR al tuo sito e accedere alla risposta del server che non sarebbe il caso se non avessi implementato questa risposta CORS.

Quindi qualsiasi sito può fare una richiesta al tuo sito per conto dei suoi visitatori ed elaborare la sua risposta. Se hai implementato qualcosa come uno schema di autenticazione o di authorization basato su qualcosa che viene fornito automaticamente dal browser (cookie, sessioni basate su cookie, ecc.), Le richieste triggerste dai siti di terze parti le useranno anche.

Ciò rappresenta in effetti un rischio per la sicurezza, in particolare se si consente la condivisione delle risorse non solo per le risorse selezionate ma per ogni risorsa. In questo contesto dovresti dare un’occhiata a Quando è sicuro abilitare CORS? .

AFAIK, Access-Control-Allow-Origin è solo un’intestazione http inviata dal server al browser. Limitare ad un indirizzo specifico (o disabilitarlo) non rende il tuo sito più sicuro per, ad esempio, i robot. Se i robot lo desiderano, possono semplicemente ignorare l’intestazione. I normali browser (Explorer, Chrome, ecc.) Di default rispettano l’intestazione. Ma un’applicazione come Postman semplicemente lo ignora.

Il server non controlla effettivamente quale sia l’origine della richiesta quando restituisce la risposta. Aggiunge semplicemente l’intestazione http. È il browser (il client end) che ha inviato la richiesta che decide di leggere l’intestazione del controllo accessi e agire di conseguenza. Si noti che nel caso di XHR può utilizzare una speciale richiesta ‘OPZIONI’ per chiedere prima le intestazioni.

Quindi, chiunque abbia capacità di scripting creativo può facilmente ignorare l’intera intestazione, qualunque sia la sua impostazione.

Vedi anche Possibili problemi di sicurezza nell’impostazione di Access-Control-Allow-Origin .


Ora per rispondere effettivamente alla domanda

Non posso fare a meno di sentire che sto mettendo il mio ambiente ai rischi per la sicurezza.

Se qualcuno vuole attaccarti, può facilmente bypassare Access-Control-Allow-Origin. Ma abilitando ‘*’ date all’attaccante alcuni “vettori di attacco” in più per giocare con, come, usando normali browser che onorino quell’intestazione HTTP.

Ecco 2 esempi pubblicati come commenti, quando un carattere jolly è davvero problematico:

Supponiamo che acceda al sito web della mia banca. Se vado su un’altra pagina e poi torno alla mia banca, sono ancora loggato a causa di un cookie. Altri utenti su Internet possono ottenere gli stessi URL sulla mia banca come faccio io, tuttavia non potranno accedere al mio account senza il cookie. Se sono consentite richieste di origine incrociata, un sito Web dannoso può effettivamente impersonare l’utente.

– Brad

Supponiamo che tu abbia un router domestico comune, come un Linksys WRT54g o qualcosa del genere. Supponiamo che il router consenta richieste di origine incrociata. Uno script sulla mia pagina Web potrebbe fare richieste HTTP a indirizzi IP di router comuni (come 192.168.1.1) e riconfigurare il router per consentire attacchi. Può persino utilizzare il router direttamente come nodo DDoS. La maggior parte dei router dispone di pagine di test che consentono ping o semplici controlli server HTTP, che possono essere violati in massa.

– Brad

Ritengo che questi commenti avrebbero dovuto essere risposte, perché spiegano il problema con un esempio di vita reale.