Recentemente ho dovuto impostare Access-Control-Allow-Originper *poter effettuare chiamate ajax tra sottodomini.
Ora non posso fare a meno di sentire che sto mettendo il mio ambiente a rischio 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 fondamentalmente che qualsiasi sito può inviare una richiesta XHR al tuo sito e accedere alla risposta del server, il 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 autorizzazione basato su qualcosa che viene fornito automaticamente dal browser (cookie, sessioni basate su cookie, ecc.), Anche le richieste attivate dai siti di terze parti li utilizzeranno.

Ciò rappresenta effettivamente 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? .

Access-Control-Allow-Origin: *è totalmente sicuro da aggiungere a qualsiasi risorsa, a meno che tale risorsa non contenga dati privati ​​protetti da qualcosa di diverso dalle credenziali standard (cookie, autenticazione di base, certificati client TLS).

Ad esempio: i dati protetti dai cookie sono al sicuro

Immagina https://example.com/users-private-data, che potrebbe esporre dati privati ​​a seconda dello stato di accesso dell'utente. Questo stato utilizza un cookie di sessione. È sicuro aggiungere Access-Control-Allow-Origin: *a questa risorsa, poiché questa intestazione consente l'accesso alla risposta solo se la richiesta viene effettuata senza cookie e i cookie sono necessari per ottenere i dati privati. Di conseguenza, nessun dato privato viene trapelato.

Ad esempio: i dati protetti da posizione / ip / rete interna non sono sicuri (purtroppo comune con intranet ed elettrodomestici):

Immagina https://intranet.example.com/company-private-data, che espone i dati di un'azienda privata, ma è possibile accedervi solo se sei sulla rete Wi-Fi dell'azienda. Non è sicuro aggiungere Access-Control-Allow-Origin: *a questa risorsa, poiché è protetta utilizzando qualcosa di diverso dalle credenziali standard. Altrimenti, uno script errato potrebbe usarti come tunnel per la intranet.

Regola del pollice

Immagina cosa vedrebbe un utente se accedesse alla risorsa in una finestra di navigazione in incognito. Se sei soddisfatto che tutti vedano questo contenuto (incluso il codice sorgente ricevuto dal browser), puoi aggiungerlo senza problemi Access-Control-Allow-Origin: *.

Per quanto ne so, Access-Control-Allow-Origin è solo un'intestazione http inviata dal server al browser. Limitarlo a un indirizzo specifico (o disabilitarlo) non rende il tuo sito più sicuro, ad esempio, per i robot. Se i robot lo desiderano, possono semplicemente ignorare l'intestazione. I normali browser disponibili (Explorer, Chrome, ecc.) Per impostazione predefinita rispettano l'intestazione. Ma un'applicazione come Postman lo ignora semplicemente.

L'estremità del server non controlla effettivamente qual è l '"origine" della richiesta quando restituisce la risposta. Aggiunge solo l'intestazione http. È il browser (l'estremità client) che ha inviato la richiesta che decide di leggere l'intestazione del controllo di accesso e di agire su di essa. Si noti che nel caso di XHR può utilizzare una richiesta speciale "OPZIONI" per richiedere prima le intestazioni.

Quindi, chiunque abbia capacità di scripting creativo può facilmente ignorare l'intera intestazione, qualunque cosa sia impostata in essa.

Vedi anche Possibili problemi di sicurezza dell'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 a rischio per la sicurezza.

Se qualcuno vuole attaccarti, può facilmente bypassare Access-Control-Allow-Origin. Ma abilitando "*" si fornisce all'attaccante qualche altro "vettore di attacco" con cui giocare, ad esempio, utilizzando normali browser web che rispettano l'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 connesso a causa di un cookie. Altri utenti su Internet possono raggiungere gli stessi URL della mia banca come me, ma non saranno in grado di accedere al mio account senza il cookie. Se le richieste cross-origin sono consentite, un sito Web dannoso può effettivamente impersonare l'utente.

- Brad

Supponi di avere un router domestico comune, come un Linksys WRT54g o qualcosa del genere. Supponiamo che il router consenta richieste cross-origin. Uno script sulla mia pagina web potrebbe effettuare richieste HTTP agli indirizzi IP del router comune (come 192.168.1.1) e riconfigurare il router per consentire gli attacchi. Può persino utilizzare il router direttamente come nodo DDoS. (La maggior parte dei router ha pagine di test che consentono ping o semplici controlli del server HTTP. Questi possono essere utilizzati in modo improprio in massa.)

- Brad

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

Nello scenario in cui il server tenta di disabilitare completamente CORS impostando le intestazioni di seguito.

• Access-Control-Allow-Origin: * (indica al browser che il server accetta richieste cross-site da qualsiasi ORIGIN)

• Access-Control-Allow-Credentials: true (indica al browser che le richieste cross-site possono inviare cookie)

C'è un fail safe implementato nei browser che comporterà il seguente errore

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

Quindi, nella maggior parte degli scenari, l'impostazione di "Controllo accesso-Consenti-Origine" *non sarà un problema. Tuttavia, per proteggersi dagli attacchi, il server può mantenere un elenco di origini consentite e ogni volta che il server riceve una richiesta di origine incrociata, può convalidare l'intestazione ORIGIN rispetto all'elenco delle origini consentite e quindi ripetere lo stesso in Access-Control-Allow-Origin intestazione.

Poiché l'intestazione ORIGIN non può essere modificata da javascript in esecuzione sul browser, il sito dannoso non sarà in grado di falsificarlo.