Perché tornare correttamente alle origini non consentite

Question

Perché tornare correttamente alle origini non consentite

#1 da (2 voti)
#2 da (1 voti)

2

A quanto ho capito, con CORS, su richieste di origine incrociata, il browser invierà un'intestazione Origin , e se l'origine non è consentita, il server invierà ancora una risposta 200 con un non -matching Access-Control-Allow-Origin header (o una risposta che semplicemente non ha quell'intestazione), e lo lascia al browser web per bloccare la risposta dalla pagina.

La mia domanda è: perché il server non dovrebbe essere responsabile della rilevazione dell'origine non consentita e restituire invece una risposta 403 ? Non vorresti impedire che il contenuto venga fornito più a monte?

Ad esempio,

var xhr = new XMLHttpRequest() ; 
xhr.open( 'GET' , 'https://www.bing.com' ) ; 
xhr.send() ;

http web-browser cors

posta martin 13.04.2018 - 10:45

fonte

2 risposte

2

CORS non funziona come descrivi tu. non trasferisce dati al client che non possono essere trasferiti senza Javascript . Ogni richiesta che non può essere raggiunta senza Javascript è soggetta alla politica e il browser controllerà la politica CORS prima di effettuare tali richieste. In dettaglio:

Per richieste semplici è ammesso qualsiasi accesso incrociato all'origine. Le richieste semplici sono quelle che potrebbero anche essere attivate senza Javascript includendo l'immagine cross-site, l'invio di un modulo ecc., Cioè queste sono richieste XHR senza intestazioni o metodi speciali.
Per qualsiasi altra richiesta (come XHR con intestazione personalizzata, metodi diversi da GET, HEAD e POST) viene eseguita una richiesta di preflight per ottenere il criterio CORS dal server. E solo se questa norma consentirà le richieste previste, verrà effettivamente eseguita.

Per maggiori dettagli vedi Mozilla: Cross-Origin Resource Sharing (CORS) .

Certo, si potrebbe obiettare che un browser modificato potrebbe semplicemente ignorare la politica CORS e richiedere comunque il contenuto. Tuttavia, un browser modificato potrebbe anche inviare un'intestazione Origin falsificata per ingannare il server nel fornire i dati. In altre parole: CORS è non una sostituzione per l'autenticazione . È invece destinato a consentire le richieste cross-site utilizzando Javascript senza aggiungere ulteriori vettori per gli attacchi CSRF . Prima che il cross-site Javascript XHR di CORS fosse vietato e venivano utilizzati metodi non sicuri come JSONP.

risposta data 13.04.2018 - 12:44

fonte

Leggi altre domande sui tag http web-browser cors

Quali sono le conseguenze della disabilitazione di ssl v2 e cifrari deboli? Stabilire un canale sicuro con autenticazione reciproca in base a chiavi pubbliche pre-condivise

score 1 · Accepted Answer

retrocompatibilità.

Già nei giorni precedenti era possibile inviare richieste HTTP da JavaScript, non era necessario che i server web controllassero da quale sito era originata una richiesta, quindi non l'hanno fatto. Quando JavaScript ha acquisito questa capacità, doveva essere implementato in modo da non compromettere la sicurezza dei siti Web esistenti. Pertanto, i browser si sono assunti la responsabilità di assicurarsi che i dati di un sito Web non fossero accessibili da un altro sito. (Le richieste AJAX di origine incrociata semplicemente non funzionerebbero.)

Successivamente è stato deciso che questa politica era troppo restrittiva e quindi è stato creato lo standard CORS (Cross-Origin Resource Sharing). Ancora una volta, questo standard doveva essere retrocompatibile con i server esistenti e quei server non controllavano ancora l'intestazione Origin . Perché dovrebbero? I browser impedivano già l'accesso incrociato ai dati del sito automaticamente; non c'era bisogno di un controllo separato. Pertanto, CORS ha dovuto richiedere ai siti di optare esplicitamente per l'accesso incrociato a una pagina specifica. Richiedere un opt-out (rifiutando la richiesta se l'intestazione Origin è errata) interromperà di nuovo la sicurezza dei siti esistenti. Così è nata l'intestazione Access-Control-Allow-Origin .

Nonostante la compatibilità con le versioni precedenti, c'è comunque un vantaggio significativo nel non richiedere ai server di controllare l'intestazione Origin . L'accesso incrociato richiede un opt-in che garantisce che sviluppatori e server Web non compromettano accidentalmente la propria sicurezza non convalidando adeguatamente l'intestazione Origin . È sicuro per impostazione predefinita piuttosto che "non sicuro a meno che non si assicuri che questa particolare intestazione sia impostata sul valore corretto".