Perché l'intestazione Access-Control-Allow-Origin è necessaria?

Question

Perché l'intestazione Access-Control-Allow-Origin è necessaria?

#1 da (25 voti)
#2 da (9 voti)

49

Comprendo lo scopo del Access-Control-Allow-Credentials intestazione , ma non riesce a vedere quale problema risolve l'intestazione Access-Control-Allow-Origin .

Più precisamente, è facile vedere come, se le richieste AJAX tra domini con credenziali fossero consentite per impostazione predefinita, o se alcuni server emettessero Access-Control-Allow-Credentials di intestazioni su ogni richiesta, gli attacchi CSRF sarebbero essere reso possibile che non potrebbe altrimenti essere eseguito. Il metodo di attacco in questo scenario sarebbe semplice:

Attira un utente ignaro verso la mia pagina dannosa.
JavaScript sulla mia pagina dannosa invia una richiesta AJAX - con cookie - a qualche pagina di un sito di destinazione.
JavaScript sulla mia pagina dannosa analizza la risposta alla richiesta AJAX ed estrae il token CSRF da esso.
JavaScript sulla mia pagina dannosa utilizza qualsiasi mezzo - AJAX o una nave tradizionale per una richiesta CSRF, come un modulo POST - per eseguire azioni utilizzando la combinazione dei cookie dell'utente e del loro token CSRF rubato.

Tuttavia, ciò che non posso vedere è quale scopo viene offerto non consentendo le richieste AJAX tra domini non registrate senza un'intestazione Access-Control-Allow-Origin . Supponiamo che dovessi creare un browser che si comportava come se ogni risposta HTTP che avesse mai ricevuto contenesse

Access-Control-Allow-Origin: *

ma ha comunque richiesto un'appropriata intestazione Access-Control-Allow-Credentials prima di inviare cookie con richieste AJAX tra domini.

Poiché i token CSRF devono essere legati ai singoli utenti (ad esempio ai singoli cookie di sessione), la risposta a una richiesta AJAX noncredentialed non espone alcun token CSRF. Quindi quale metodo di attacco - se esiste - l'ipotetico browser descritto sopra esporrà i suoi utenti a?

http csrf same-origin-policy cors

posta Mark Amery 10.10.2013 - 19:11

fonte

2 risposte

9

Ciò che inizialmente mi ha infastidito con le politiche CORS è stata la loro applicazione indiscriminata a prescindere dal tipo di risorsa / tipo, sento che il sentimento riecheggia abbastanza bene con la tua domanda. Le specifiche W3 in realtà consiglia che:

A resource that is publicly accessible, with no access control checks, can always safely return an Access-Control-Allow-Origin header whose value is "*"

Quindi, mentre lo scenario nella risposta di @ SilverlightFox è possibile, IMHO era improbabile che fosse preso in considerazione quando scrivevo il spec. Invece, W3 sembra essere guidato da un "tutto ciò che non è esplicitamente permesso dovrebbe essere ristretto" mentalità in questa istanza, che si ritorce quando le intestazioni corrette non sono impostate o il supporto manca ai singoli browser:

Ricche applicazioni lato client che utilizzano API RESTful di terze parti in cui l'autenticazione, se presente, viene inviata ad ogni richiesta in modo che non vi sia alcuna "sessione" per dirottare (che è stateless per te!). Tuttavia, le risposte di .json sono soggette a CORS, quindi ora devi convincere la terza parte a implementare jsonp , o un'appropriata intestazione Access-Control-Allow-Origin , oppure rinunciare e impostare un tunnel al loro endpoint (indovina quale io? userò).
I caratteri web sono soggetti a CORS , anche se afaik ha implementato solo Firefox questo progetto di spec. Ciò significa che se stai utilizzando un CDN per i caratteri (o un sottodominio per tutti i contenuti statici), è meglio * -enabled!
Bonus herp derp punti per CDN che non rispondono con un'intestazione * ma echo invece il valore dell'intestazione Origin della richiesta: se viene memorizzato nella cache su un proxy con un ...-Allow-Origin: domainA , i tuoi utenti di altri domini non potranno accedervi senza cachebusting (che è una sorta di battuta d'arresto in termini di benefici prestazionali della CDN).
Ci sono anche alcuni scenari marginali come utilizzando immagini / video esterni con canvas .

Questi inconvenienti quando si accede a risorse di * -adattabili possono essere semplicemente considerati accettabili poiché almeno CORS è in gioco di default quando è importante la maggior parte .

risposta data 18.11.2013 - 22:50

fonte

Leggi altre domande sui tag http csrf same-origin-policy cors

Derivazione della chiave effimera WPA2 Perché posso accedere ai file protetti di Windows quando avvio Ubuntu da USB?

score 25 · Accepted Answer

Se ti capisco correttamente, stai dicendo perché il browser blocca l'accesso a una risorsa che può essere liberamente ottenuta su Internet se i cookie non sono coinvolti? Prendi in considerazione questo scenario:

www.evil.com : contiene codice script malizioso che cerca di sfruttare vulnerabilità CSRF.

www.privatesite.com - questo è il tuo sito esterno, ma invece di bloccarlo usando le credenziali, lo hai impostato per essere senza cookie e per consentire l'accesso solo dall'IP statico del tuo router domestico.

mynas (192.168.1.1) - questo è il tuo server di casa, accessibile solo sulla tua rete wifi domestica. Dato che sei l'unico che permetti di connetterti alla tua rete Wi-Fi domestica, questo server non è protetto da credenziali e consente l'accesso anonimo e disinvolto.

Sia www.privatesite.com che mynas generano token nei campi modulo nascosti per la protezione contro CSRF - ma poiché hai disabilitato l'autenticazione, questi token non sono legati a nessuna sessione utente.

Ora se accidentalmente visiti www.evil.com questo dominio potrebbe fare richieste a www.privatesite.com/turn_off_ip_lockdown passando il token ottenuto dalla richiesta tra domini, o anche a mynas/format_drive usando lo stesso metodo.

Probabilmente lo so, ma suppongo che lo standard sia scritto per essere il più robusto possibile e non ha senso rimuovere Access-Control-Allow-Origin poiché aggiunge vantaggi in scenari come questo.