it-swarm.dev

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

Capisco scopo dell'intestazione Access-Control-Allow-Credentials , ma non riesco a vedere quale problema risolve l'intestazione Access-Control-Allow-Origin.

Più precisamente, è facile vedere come, se cross-domain AJAX con credenziali erano consentite per impostazione predefinita, oppure se alcuni server sputassero le intestazioni Access-Control-Allow-Credentials su ogni richiesta, sarebbero possibili attacchi CSRF che altrimenti non potrebbero essere eseguiti. Il metodo di attacco in questo scenario sarebbe semplice:

  1. Attira un utente ignaro sulla mia pagina malevola.
  2. JavaScript sulla mia pagina dannosa invia una AJAX richiesta - con cookie - ad alcune pagine di un sito di destinazione.
  3. JavaScript sulla mia pagina dannosa analizza la risposta alla AJAX ed estrae il token CSRF da essa.
  4. 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 di i cookie dell'utente e il loro token CSRF rubato.

Tuttavia, ciò che io non riesco a vedere è quale scopo è servito non permettendo non accreditato cross-domain AJAX richieste senza intestazione Access-Control-Allow-Origin. Supponi che dovrei creare un browser che si comporti come se contenesse ogni risposta HTTP che abbia mai ricevuto

Access-Control-Allow-Origin: *

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

Poiché i token CSRF devono essere associati a singoli utenti (ovvero a singoli cookie di sessione), la risposta a un non accreditato AJAX = richiesta non esporrebbe alcun token CSRF, quindi a quale metodo di attacco - se del caso - l'ipotetico browser sopra descritto esponerebbe i suoi utenti?

50
Mark Amery

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

www.evil.com: Contiene codice di script dannoso che cerca di sfruttare le vulnerabilità di CSRF.

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

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

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

Ora, se visiti accidentalmente www.evil.com, Questo dominio potrebbe inviare richieste a www.privatesite.com/turn_off_ip_lockdown Passando il token ottenuto dalla richiesta tra domini o addirittura mynas/format_drive Usando lo stesso metodo.

È improbabile che lo sappia, ma immagino che lo standard sia stato scritto per essere il più robusto possibile e non ha senso rimuovere Access-Control-Allow-Origin Poiché aggiunge un vantaggio in scenari come questo.

25
SilverlightFox

Ciò che inizialmente mi ha infastidito con le politiche CORS è stata la loro applicazione indiscriminata indipendentemente dalla risorsa/dal tipo, sento che il sentimento risuona abbastanza bene con la tua domanda. Specifiche W3 in realtà avvisa che:

Una risorsa accessibile pubblicamente, senza controlli di controllo dell'accesso, può sempre restituire in modo sicuro un'intestazione Access-Control-Allow-Origin il cui valore è "*"

Quindi, mentre lo scenario in la risposta di @ SilverlightFox è possibile, IMHO è improbabile che venga preso in considerazione quando si scrive la specifica. Invece, W3 sembra essere guidato da una mentalità "tutto ciò che non è esplicitamente permesso dovrebbe essere limitato" in questo caso, che si ritorce contro quando le intestazioni corrette non sono 'set o supporto mancano dai singoli browser:

  • Rich applicazioni lato client che utilizzano API RESTful di terze parti in cui l'autenticazione, se presente, viene inviata con ogni richiesta in modo che non vi sia alcuna "sessione" per Hijack (che è apolide per te!). Tuttavia, le risposte .json sono soggette a CORS, quindi ora devi convincere la terza parte a implementare jsonp, o un'intestazione Access-Control-Allow-Origin Adatta, oppure rinunciare e impostare un tunnel al loro endpoint (indovina quale userò).

  • Webfonts sono soggetti a CORS , anche se solo Firefox ha implementato questa bozza di specifiche. Ciò significa che se stai usando un CDN per i caratteri (o un sottodominio per tutto il contenuto statico), è meglio che sia abilitato *!

  • Bonus punti herp derp per i CDN che non rispondono con un'intestazione * Ma fanno eco alla richiesta Origin valore dell'intestazione invece: se viene memorizzato nella cache su un proxy con un ...-Allow-Origin: domainA, i tuoi utenti di altri domini non saranno in grado di accedervi senza cachebusting (che è una specie di battuta d'arresto in termini di vantaggi prestazionali della CDN).

  • Ci sono anche alcuni scenari marginali come sando immagini/video esterni con canvas .

Questi inconvenienti quando si accede a * - risorse adeguate potrebbero essere semplicemente considerate accettabili poiché almeno CORS è in gioco per impostazione predefinita quando conta di più .

12
o.v.