Cors è un modo sicuro per fare richieste Ajax incrociate?

StackOverflow https://stackoverflow.com/questions/4850702

Domanda

Dopo aver letto CORS (condivisione delle risorse incrociate), non capisco come migliora la sicurezza. La comunicazione AJAX a dominio è consentita se viene inviata l'intestazione di origine corretta. Ad esempio, se mando

ORIGINE: http://example.com

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

Access-Control-Alow-Origin: [URL ricevuto qui

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

È davvero sicuro? Se qualcuno vuole ricevere le informazioni, fingere un'intestazione di origine sembra un compito davvero banale. Inoltre, lo standard afferma che la politica viene applicata nel browser, bloccando la risposta se l'accesso-controllo-origine non è corretta. Ovviamente se qualcuno sta cercando di ottenere tali informazioni, non userà un browser standard per bloccarlo.

È stato utile?

Soluzione

Non puoi fingere un'intestazione di origine con JavaScript in un browser Web. Cors è progettato per impedirlo.

Al di fuori di un browser web, non importa. Non è progettato per impedire alle persone di ottenere dati disponibili al pubblico. Non puoi esporlo al pubblico senza che i membri del pubblico lo ottengano.

È progettato in modo che dato:

  • Alice, una persona che fornisce un'API progettata per accedere 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 da recuperare i dati dal sito Web di Alice e inviarli 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 cose come post commenti, eliminare i dati o vedere i dati che sono non Disponibile al pubblico in generale - dal momento che senza protezione, JS di Charlie potrebbe dire al browser di Bob di farlo dietro la schiena di Bob (e poi inviare i risultati a Charlie).

Se si desidera impedire alle persone non autorizzate di vedere i dati, è necessario proteggerli con password, certificati client SSL o altri mezzi di autenticazione/autorizzazione basate sull'identità.

Altri suggerimenti

Lo scopo è impedire questo -

  • Vai al sito web x
  • L'autore del sito Web X ha scritto uno script malvagio che viene inviato al tuo browser
  • Quello script in esecuzione sul tuo browser registra sul tuo sito Web bancario e fa cose malvagie e perché è in esecuzione come te Nel tuo browser ha il permesso di farlo.

Le idee sono che il sito web della tua banca ha bisogno di un modo per dire al tuo browser se gli script sul sito Web X dovrebbero essere attendibili per accedere alle pagine sulla tua banca.

Solo per aggiungere la risposta di @jcoder, l'intero punto del Origin L'intestazione non è per proteggere le risorse richieste su un server. Tale attività dipende dal server stesso tramite altri mezzi esattamente perché un utente malintenzionato è effettivamente in grado di falsificare questa intestazione con gli strumenti appropriati.

Il punto del Origin L'intestazione è proteggere l'utente. Lo scenario è il seguente:

  • Un aggressore crea un sito web dannoso m

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

  • B probabilmente non avrà m nel suo Access-Control-Allow-Origin Intestazione, perché dovrebbe?

  • Il punto fondamentale è che M non ha mezzi per parodia o sovrascrivere il Origin Intestazione, 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à.

Alice potrebbe alterare il Origin Header stessa, ma perché dovrebbe, poiché significherebbe che si sta danneggiando?

Tl; dr: il Origin L'intestazione protegge l'utente innocente. Non garantisce risorse su un server. È spodiabile da un aggressore sulla sua macchina, ma non può essere falsificato su una macchina non sotto il suo controllo.

I server dovrebbero ancora proteggere le loro risorse, come abbinamento Origin L'intestazione non significa un accesso autorizzato. Tuttavia, a Origin Intestazione che non corrisponde significa un accesso non autorizzato.

Lo scopo della stessa politica di origine non è impedire alle persone di accedere ai contenuti del sito Web in generale; Se qualcuno vuole farlo, non hanno nemmeno bisogno di un browser. Il punto è smettere Script del cliente Accesso ai contenuti su un altro dominio senza i diritti di accesso necessari. Vedere la voce di Wikipedia per Stessa politica di origine.

Dopo aver letto CORS, non capisco come migliora la sicurezza.

CORS non migliora la sicurezza. CORS fornisce un meccanismo per i server per raccontare ai browser come dovrebbero essere accessibili da domini stranieri e cerca di farlo in modo coerente con il modello di sicurezza del browser che esisteva prima di Cors (vale a dire Stessa politica di origine).

Ma la stessa politica di origine e CORS hanno un ambito limitato. In particolare, il Specifiche CORS stesso non ha meccanismo per il rifiuto delle richieste. Può usare le intestazioni per dire al browser di non lasciare che una pagina da un dominio straniero legga una risposta. E, nel caso delle richieste di preflight, può chiedere al browser di non inviarlo determinate richieste da un dominio estero. Ma CORS non specifica alcun mezzo per il rifiuto del server (cioè non eseguire) una richiesta effettiva.

Facciamo un esempio. Un utente viene effettuato al sito A tramite un biscotto. Il utente carica il sito dannoso M, che cerca di presentare un modulo che fa a POST a A. Cosa accadrà? Bene, con o senza cors e con o senza M Essendo un dominio consentito, il browser invierà la richiesta a A con il cookie di autorizzazione dell'utente e il server eseguirà il dannoso POST come se l'utente lo avesse avviato.

Questo attacco è chiamato Fal, e Cors stesso non fa nulla per mitigarlo. Ecco perché le protezioni CSRF sono così importanti se si consentono alle richieste di modificare i dati per conto degli utenti.

Ora, l'uso del Origin L'intestazione può essere una parte importante della protezione CSRF. In effetti, controllarlo fa parte del Raccomandazione attuale per la difesa CSRF a più fronti. Ma quell'uso del Origin L'intestazione cade fuori dalle specifiche CORS.

In sintesi, CORS è una specifica utile per estendere il modello di sicurezza della stessa politica di origine esistente ad altri domini accettati. Non aggiunge sicurezza e i siti hanno bisogno degli stessi tipi di meccanismi di difesa che hanno fatto prima delle CORS.

Sono in ritardo per rispondere, ma non credo che nessun post qui fornisca davvero la risposta ricercata. Il più grande asporto dovrebbe essere che il browser sia l'agente che sta scrivendo il origin Valore dell'intestazione. Una sceneggiatura malvagia non può scrivere il origin Valore dell'intestazione. Quando il server risponde con un Access-Control-Allow-Origin Intestazione, il browser cerca di garantire che questa intestazione contenga il origin valore inviato in precedenza. In caso contrario, innesca un errore e non restituisce il valore allo script richiedente. Le altre risposte a questa domanda presentano un buon scenario a quando si desidera negare una risposta alla sceneggiatura malvagia.

@Daniel F fornisce anche una buona risposta alla domanda

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top