Quale scopo ha Access-Control-Allow-Origin?

4

Ho un malinteso riguardo l'intestazione Access-Control-Allow-Origin di CORS.

Il nome dice "allow" da cui capisco che se faccio una richiesta da un "Origin" che non è consentito, la richiesta dovrebbe fallire.

Ma posso sempre modificare /etc/hosts per fare in modo che il punto "Origine" sia il mio indirizzo IP.

Ad esempio, per una risposta che potrebbe contenere questo:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://example.com
Access-Control-Expose-Headers: Access-Control-Allow-Origin,Access-Control-Allow-Credentials

Posso sempre modificare /etc/hosts e avere:

127.0.0.1   example.com

... e la chiamata funzionerà.

Che cos'è esattamente questa intestazione? Posso usare Access-Control-Allow-Origin: * anziché Access-Control-Allow-Origin: http://example.com ? Qual è la differenza?

    
posta pepe 14.04.2016 - 17:07
fonte

3 risposte

3

It's name says "allow" from which I understand that if I make a request from an "Origin" that is not allowed the request should fail.

È giusto (dipende dalla richiesta). Tuttavia, non consentire una richiesta non è una proprietà di CORS , a causa del politica di origine dello spam .

CORS non è realmente un'intestazione pensata per proteggere nulla, è un'intestazione che intende indebolire la stessa politica di origine e consentire le richieste di origine incrociata (che potrebbero essere richieste da alcune applicazioni).

In particolare non è progettato per il controllo degli accessi, quindi la possibilità di accedere ai siti Web modificando la configurazione dei sistemi non influisce in alcun modo sulla sicurezza.

    
risposta data 14.04.2016 - 17:29
fonte
3

La politica CORS limita il codice caricato dal sito A ed eseguito sul tuo browser può fare con il sito B, cioè limita le richieste di cross-origine. Non è per limitare ciò che può essere fatto con il sito B in generale, cioè si preoccupa solo di richieste di origine incrociata e non fornisce alcun tipo di controllo di autenticazione.

Hai ragione che in teoria potresti semplicemente modificare il tuo sistema per aggirare questa politica. Ma l'attaccante su qualche server web remoto non può farlo. Se l'autore dell'attacco sul sito B desidera utilizzare una richiesta cross-site contro il sito A, ma il sito A consente solo il sito G, l'utente malintenzionato dovrebbe in qualche modo apparire come sito G per il browser. Per fare ciò l'attaccante deve avere accesso al tuo sistema o alle impostazioni DNS del sito G, che non è qualcosa che ci si potrebbe aspettare dall'attaccante.

    
risposta data 14.04.2016 - 17:36
fonte
0

Access-Control-Allow-Origin modifica la protezione offerta all'utente finale in merito a come la Stessa politica di origine gestisce AJAX risposte.

Se un utente è disposto a scherzare con i file host per modificare ulteriormente questa protezione da solo, l'unica cosa che sta compromettendo è la loro stessa sicurezza.

L'intestazione consente a un'altra origine di leggere una risposta AJAX se viene inviata una richiesta di origine incrociata all'origine che emette l'intestazione.

Can I use Access-Control-Allow-Origin: * instead of Access-Control-Allow-Origin: http://example.com? What's the difference?

La differenza è la prima opzione che consente a qualsiasi origine di leggere le risposte AJAX. La seconda opzione consente solo a http://example.com di leggere le risposte AJAX.

Se Access-Control-Allow-Credentials è true, la prima opzione non funzionerà - CORS non ti consentirà di aprire il tuo sito web fino a richieste credenziali globali. In tal caso, e il tuo sito web conteneva informazioni riservate (ad esempio Gmail potrebbe avere una funzione AJAX che restituisce i messaggi nella Posta in arrivo), quindi qualsiasi sito Web visitato da un utente sarebbe in grado di leggere queste informazioni riservate dal tuo sito web nel contesto del sessione dell'utente corrente.

Se davvero desideri che tutte le origini siano in grado di leggere dalla sessione dell'utente corrente, puoi leggere l'intestazione della richiesta Origin e quindi riflettere questa origine nell'intestazione Access-Control-Allow-Origin (avendo cura di disinfettare correttamente, naturalmente , rimuovendo CRLF e simili). Ciò equivarrebbe effettivamente all'output di Access-Control-Allow-Origin: * e a consentire le richieste con credenziali tramite Access-Control-Allow-Credentials .

    
risposta data 15.04.2016 - 10:44
fonte

Leggi altre domande sui tag