CORS è un modo sicuro per fare richieste AJAX interdominio?

Dopo aver letto su CORS (Cross-Origin Resource Sharing), non capisco come migliora la sicurezza. La comunicazione AJAX tra domini è consentita se viene inviata l’intestazione ORIGIN corretta. Ad esempio, se invio

ORIGINE: http://example.com

Il server controlla se questo dominio è nella lista bianca e, se lo è, intestazione:

Access-Control-Allow-Origin: [url ricevuto qui]

viene rispedito, insieme alla risposta (questo è il caso semplice, ci sono anche richieste prefigurate, ma la domanda è la stessa).

È davvero sicuro? Se qualcuno vuole ricevere le informazioni, fingere un’intestazione ORIGIN sembra un compito davvero banale. Anche lo standard dice che la politica è applicata nel browser, bloccando la risposta se Access-Control-Allow-Origin non è corretto. Ovviamente se qualcuno sta cercando di ottenere quelle informazioni, non userà un browser standard per bloccarlo.

Non è progettato per impedire alle persone di ottenere i dati. Non puoi esporlo senza che la gente lo capisca.

È progettato in modo tale che:

  • Alice, una persona che fornisce un’API progettata per l’accesso tramite Ajax
  • Bob, una persona con un browser web
  • Charlie, una terza parte che gestisce il proprio sito web

Se Bob visita il sito web di Charlie, Charlie non può inviare JS al browser di Bob in modo che recuperi i dati dal sito Web di Alice e li manda a Charlie.

La situazione di cui sopra diventa più importante se Bob ha un account utente sul sito web di Alice che gli consente di fare commenti come post o cancellare dati – poiché senza protezione, Charlie potrebbe dire al browser di Bob di farlo dietro alle spalle di Bob.

Se si desidera impedire a persone non autorizzate di visualizzare i dati, è necessario proteggere con password, certificati client SSL o altri mezzi di autenticazione / authorization basati sull’id quadro.

Lo scopo è quello di prevenire questo –

  • Vai al sito X.
  • L’autore del sito X ha scritto uno script malvagio che viene inviato al tuo browser
  • quello script in esecuzione sul tuo browser si collega al tuo sito web della banca e fa cose malvagie e perché funziona come tu nel tuo browser ha il permesso di farlo.

L’idea è che il sito web della tua banca abbia bisogno di un modo per dire al tuo browser se è necessario affidarsi agli script sul sito X per accedere alle pagine della tua banca.

Giusto per aggiungere la risposta di @jcoder, l’intero punto dell’intestazione Origin , non è quello di proteggere le risorse richieste su un server, quella attività dipende dal server stesso, esattamente perché un utente malintenzionato è effettivamente in grado di spoofare questa intestazione con gli strumenti appropriati.

Il punto dell’intestazione Origin è proteggere l’utente. Lo scenario è il seguente:

  • un aggressore Marie crea un sito Web dannoso M

  • un utente Alice è ingannato per connettersi a M, che contiene uno script che tenta di eseguire alcune azioni tramite CORS su un server B che supporta effettivamente CORS

  • B probabilmente non ha M nel suo header Access-Control-Allow-Origin , perché dovrebbe?

  • Il punto cardine è che M non ha mezzi per falsificare o sovrascrivere l’intestazione Origin , perché le richieste sono avviate dal browser di ALICE. Quindi il suo browser imposterà il (corretto) Origin a M, che non è in Access-Control-Allow-Origin di B, quindi la richiesta fallirà.

Ora, Alice poteva modificare l’intestazione Origin , ma perché avrebbe voluto, perché avrebbe significato che si stava facendo del male a se stessa?

TL; DR: L’intestazione Origin protegge l’utente innocente. Non protegge le risorse. È ansible effettuare lo spoofing da un utente malintenzionato sulla propria macchina, ma non può essere falsificato su una macchina che non è sotto il suo controllo.

I server dovrebbero comunque proteggere le loro risorse, poiché un’intestazione Origin corrispondente non significa un accesso autorizzato. Tuttavia, un’intestazione Origin che NON corrisponde, significa un accesso non autorizzato.

Lo scopo della stessa politica di origine non è quello di impedire alle persone di accedere al contenuto del sito Web in generale; se qualcuno vuole farlo, non ha nemmeno bisogno di un browser. Il punto è fermare gli script client che accedono al contenuto su un altro dominio senza i necessari diritti di accesso. Vedere la voce di Wikipedia per la stessa politica di origine .

Dopo aver letto su CORS, non capisco come migliori la sicurezza.

CORS non migliora la sicurezza. CORS fornisce un meccanismo per i server per indicare ai browser come devono essere accessibili da domini esterni e cerca di farlo in modo coerente con il modello di sicurezza del browser esistente prima di CORS (vale a dire la stessa politica di origine ).

Ma la stessa politica di origine e CORS hanno un ambito limitato. Nello specifico, la specifica CORS non ha alcun meccanismo per respingere le richieste. Può utilizzare le intestazioni per dire al browser di non lasciare che una pagina da un dominio straniero legga una risposta. E, nel caso di richieste di verifica preliminare, può chiedere al browser di non inviarle determinate richieste da un dominio straniero. Ma CORS non specifica alcun mezzo per il server di rifiutare (cioè non eseguire) una richiesta effettiva.

Facciamo un esempio. Un utente ha effettuato l’accesso al sito A tramite un cookie. L’utente carica il sito M dannoso, che tenta di inviare un modulo che esegue un POST a A Cosa accadrà? Bene, con o senza CORS, e con o senza M un dominio consentito, il browser invierà la richiesta ad A con il cookie di authorization dell’utente, e il server eseguirà il POST dannoso come se l’utente l’avesse avviato.

Questo attacco è chiamato contraffazione di richieste tra siti e CORS stesso non fa nulla per mitigarlo. Ecco perché le protezioni CSRF sono così importanti se si consente alle richieste di modificare i dati per conto degli utenti.

Ora, l’uso dell’intestazione Origin può essere una parte importante della protezione CSRF. In effetti, il controllo fa parte dell’attuale raccomandazione per la difesa CSRF su più fronti . Ma Origin dell’intestazione Origin rientra nelle specifiche CORS.

In breve, CORS è una specifica utile per estendere il modello di sicurezza della politica Same Same esistente ad altri domini accettati. Non aggiunge sicurezza, e i siti richiedono lo stesso tipo di meccanismi di difesa che hanno fatto prima di CORS.

Sono in ritardo per rispondere ma non penso che nessun post qui fornisca realmente la risposta ricercata. Il più grande asporto dovrebbe essere che il browser è l’agente che sta scrivendo il valore dell’intestazione di origin . Uno script malvagio non può scrivere il valore dell’intestazione di origin . Quando il server risponde con un’intestazione Access-Control-Allow-Origin , il browser cerca di garantire che questa intestazione contenga il valore di origin inviato in precedenza. In caso contrario, genera un errore e non restituisce il valore allo script richiedente. Le altre risposte a questa domanda rappresentano uno scenario valido per quando si desidera negare una risposta al copione malvagio.

@daniel f fornisce anche una buona risposta alla domanda