CORS - Qual è la motivazione dietro l'introduzione di richieste di verifica preliminare?

La condivisione delle risorse tra origini è un meccanismo che consente a una pagina Web di inviare richieste XMLHttp a un altro dominio (da Wikipedia ).

Ho armeggiato con CORS negli ultimi due giorni e penso di avere una buona comprensione di come tutto funzioni.

Quindi la mia domanda non riguarda il funzionamento di CORS / preflight, ma il motivo alla base della creazione di preflight come nuovo tipo di richiesta . Non riesco a vedere alcun motivo per cui il server A debba inviare un preflight (PR) al server B solo per scoprire se la richiesta reale (RR) sarà accettata o meno - sarebbe certamente possibile per B accettare / rifiutare RR senza qualsiasi PR precedente.

Dopo aver cercato un po 'ho trovato questa informazione su www.w3.org (7.1.5):

Per proteggere le risorse da richieste di origine incrociata che non potrebbero provenire da determinati agenti utente prima dell'esistenza di questa specifica, viene effettuata una richiesta di verifica preliminare per garantire che la risorsa sia a conoscenza di tale specifica.

Trovo che questa sia la frase più difficile da capire di sempre. La mia interpretazione (è meglio chiamarla "ipotesi migliore") è che si tratta di proteggere il server B da richieste del server C che non sono a conoscenza delle specifiche.

Qualcuno può spiegare uno scenario / mostrare un problema che PR + RR risolve meglio della sola RR?

Ho passato un po 'di tempo a essere confuso riguardo allo scopo della richiesta di verifica preliminare, ma penso di averlo ora.

L'intuizione chiave è che le richieste di verifica preliminare non sono una questione di sicurezza . Piuttosto, sono una cosa che non cambia le regole .

Le richieste di verifica preliminare non hanno nulla a che fare con la sicurezza e non hanno attinenza con le applicazioni che sono in fase di sviluppo ora, con consapevolezza di CORS. Piuttosto, il meccanismo di verifica preliminare avvantaggia i server che sono stati sviluppati senza una conoscenza di CORS e funziona come un controllo di integrità tra il client e il server che sono entrambi a conoscenza di CORS. Gli sviluppatori di CORS ritenevano che ci fossero abbastanza server là fuori che si basavano sul presupposto che non avrebbero mai ricevuto, ad esempio una richiesta DELETE tra domini per aver inventato il meccanismo di preflight per consentire ad entrambe le parti di opt-in. Pensavano che l'alternativa, che sarebbe stata semplicemente quella di abilitare le chiamate tra domini, avrebbe infranto troppe applicazioni esistenti.

Esistono tre scenari qui:

1. Vecchi server, non più in fase di sviluppo e sviluppati prima di CORS. Questi server possono ipotizzare che non riceveranno mai, ad esempio, una richiesta DELETE tra domini.Questo scenario è il principale beneficiario del meccanismo di verifica preliminare. Sì, questi servizi potrebbero già essere abusati da un utente malintenzionato o non conforme (e CORS non fa nulla per cambiarlo), ma in un mondo con CORS il meccanismo di verifica preliminare fornisce un ulteriore "controllo di integrità" in modo che client e server non lo facciano rompere perché le regole sottostanti del web sono cambiate.

2. Server che sono ancora in fase di sviluppo, ma che contengono molto vecchio codice e per i quali non è possibile / desiderabile controllare tutto il vecchio codice per assicurarsi che funzioni correttamente in un mondo interdominio. Questo scenario consente ai server di aderire progressivamente a CORS, ad esempio dicendo "Ora consentirò questa particolare intestazione", "Ora consentirò questo particolare verbo HTTP", "Ora consentirò che i cookie / informazioni di autenticazione siano inviato ", ecc. Questo scenario beneficia del meccanismo di verifica preliminare.

3. Nuovi server scritti con consapevolezza di CORS. Secondo le pratiche di sicurezza standard, il server deve proteggere le proprie risorse di fronte a qualsiasi richiesta in arrivo: i server non possono fidarsi dei client per non fare cose dannose. Questo scenario non beneficia del meccanismo di verifica preliminare : il meccanismo di verifica preliminare non offre alcuna sicurezza aggiuntiva a un server che abbia adeguatamente protetto le sue risorse.

Qual è stata la motivazione dietro l'introduzione delle richieste di verifica preliminare?

Sono state introdotte richieste di verifica preliminare in modo che un browser potesse essere sicuro di avere a che fare con un server compatibile con CORS prima di inviare determinate richieste. Tali richieste sono state definite come potenzialmente pericolose (che cambiano lo stato) e nuove (non possibili prima del CORS a causa della stessa politica sull'origine ). L'uso delle richieste di verifica preliminare significa che i server devono attivare (rispondendo correttamente alla verifica preliminare) ai nuovi tipi di richieste potenzialmente pericolose rese possibili da CORS.

Questo è il significato di questa parte della specifica : "Per proteggere le risorse dalle richieste di origine incrociata che non potrebbero provenire da determinati agenti utente prima dell'esistenza di questa specifica, viene effettuata una richiesta di verifica preliminare per garantire che la risorsa sia a conoscenza di questa specifica".

Puoi farmi un esempio?

Immaginiamo che un utente del browser abbia effettuato l'accesso al proprio sito bancario all'indirizzo A.com. Quando accedono al malware B.com, quella pagina include alcuni Javascript a cui tenta di inviare una DELETErichiesta A.com/account. Poiché l'utente ha effettuato l'accesso A.com, tale richiesta, se inviata, includerebbe i cookie che identificano l'utente.

Prima di CORS, la stessa politica di origine del browser gli avrebbe impedito di inviare questa richiesta. Ma poiché lo scopo di CORS è quello di rendere possibile questo tipo di comunicazione tra origini, non è più appropriato.

Il browser potrebbe semplicemente inviare il DELETEe lasciare che il server decida come gestirlo. E se A.comnon fosse a conoscenza del protocollo CORS? Potrebbe andare avanti ed eseguire il pericoloso DELETE. Si potrebbe presumere che, a causa della stessa politica di origine del browser, non sia mai stato in grado di ricevere una simile richiesta, e quindi potrebbe non essere mai stato indurito contro tale attacco.

Per proteggere tali server non compatibili con CORS, quindi, il protocollo richiede al browser di inviare prima una richiesta di verifica preliminare . Questo nuovo tipo di richiesta è qualcosa a cui solo i server compatibili con CORS possono rispondere correttamente, consentendo al browser di sapere se è sicuro o meno inviare l'effettivo DELETE.

Perché tutte queste storie sul browser, l'attaccante non può semplicemente inviare una DELETErichiesta dal proprio computer?

Certo, ma tale richiesta non includerà i cookie dell'utente. L'attacco che questo ha lo scopo di prevenire si basa sul fatto che il browser invierà cookie (in particolare, informazioni di autenticazione per l'utente) per l'altro dominio insieme alla richiesta.

Che suona come Cross-Site Request Forgery , in cui un modulo sul sito B.comlattina POSTper A.comcon i cookie degli utenti e fare danni.

Giusto. Un altro modo per dirlo è che le richieste di verifica preliminare sono state create in modo da non aumentare la superficie di attacco CSRF per server non compatibili con CORS.

Ma osservando i requisiti per le richieste "semplici" che non richiedono preflight, vedo che POSTè ancora consentito. Ciò può cambiare stato ed eliminare i dati proprio come un DELETE!

È vero! CORS non protegge il tuo sito dagli attacchi CSRF. Inoltre, senza CORS non sei protetto dagli attacchi CSRF. Lo scopo delle richieste di verifica preliminare è solo quello di limitare l'esposizione CSRF a ciò che esisteva già nel mondo pre-CORS.

Sospiro. OK, accetto a malincuore la necessità di richieste di verifica preliminare. Ma perché dobbiamo farlo per ogni risorsa (URL) sul server? Il server gestisce CORS oppure no.

Sei sicuro di questo? Non è raro che più server gestiscano le richieste per un singolo dominio. Ad esempio, è possibile che le richieste A.com/url1vengano gestite da un tipo di server e le richieste da A.com/url2gestire da un diverso tipo di server. In genere non è il caso che il server che gestisce una singola risorsa possa offrire garanzie di sicurezza su tutte le risorse di quel dominio.

Belle. Scendiamo a compromessi. Creiamo una nuova intestazione CORS che consente al server di indicare esattamente per quali risorse può parlare, in modo da evitare ulteriori richieste di verifica preliminare a tali URL.

Buona idea! In effetti, l'intestazione è Access-Control-Policy-Pathstata proposta proprio per questo scopo. Alla fine, però, è stato lasciato fuori dalle specifiche, a quanto pare perché alcuni server hanno implementato erroneamente la specifica URI in modo tale che le richieste a percorsi che sembravano sicuri per il browser non sarebbero in effetti sicure sui server rotti.

È stata una decisione prudente che ha dato la priorità alla sicurezza rispetto alle prestazioni, consentendo ai browser di implementare immediatamente le specifiche CORS senza mettere a rischio i server esistenti? O era miope condannare Internet a sprecare larghezza di banda e raddoppiare la latenza solo per sistemare i bug in un determinato server in un determinato momento?

Le opinioni sono diverse.

Bene, almeno i browser memorizzeranno nella cache il preflight per un singolo URL?

Sì. Anche se probabilmente non per molto tempo. Nei browser WebKit il tempo massimo di cache di verifica preliminare è attualmente di 10 minuti .

Sospiro. Bene, se so che i miei server sono compatibili con CORS e quindi non necessitano della protezione offerta dalle richieste di verifica preliminare, c'è un modo per evitarli?

La tua unica vera opzione è assicurarti di soddisfare i requisiti per le richieste "semplici". Ciò potrebbe significare tralasciare le intestazioni personalizzate che altrimenti includeresti (come X-Requested-With), mentendo sul Content-Type, o altro.

Qualunque cosa tu faccia, devi assicurarti di avere adeguate protezioni CSRF in atto poiché la specifica CORS non affronta il rifiuto di richieste "semplici", incluso il non sicuro POST. Come afferma la specifica : "le risorse per le quali le richieste semplici hanno un significato diverso dal recupero devono proteggersi dalla falsificazione di richieste tra siti".

Considerare il mondo delle richieste tra domini prima di CORS. È possibile eseguire un POST di modulo standard o utilizzare scriptun imagetag o per inviare una richiesta GET. Non è possibile effettuare nessun altro tipo di richiesta diverso da GET / POST e non è possibile emettere intestazioni personalizzate su queste richieste.

Con l'avvento di CORS, gli autori delle specifiche hanno dovuto affrontare la sfida di introdurre un nuovo meccanismo interdominio senza interrompere la semantica esistente del web. Hanno scelto di farlo dando ai server un modo per optare per qualsiasi nuovo tipo di richiesta. Questo opt-in è la richiesta di verifica preliminare.

Pertanto, le richieste GET / POST senza intestazioni personalizzate non richiedono un preflight, poiché queste richieste erano già possibili prima di CORS. Ma qualsiasi richiesta con intestazioni personalizzate, o richieste PUT / DELETE, non hanno bisogno di una verifica preliminare, dal momento che questi sono nuovi al CORS spec. Se il server non è a conoscenza di CORS, risponderà senza intestazioni specifiche CORS e la richiesta effettiva non verrà effettuata.

Senza la richiesta di verifica preliminare, i server potrebbero iniziare a visualizzare richieste impreviste dai browser. Ciò potrebbe comportare un problema di sicurezza se i server non fossero preparati per questo tipo di richieste. Il preflight CORS consente di introdurre richieste Web tra domini in modo sicuro.

CORS ti consente di specificare più intestazioni e tipi di metodo di quanto fosse possibile in precedenza con cross-origin <img src>o <form action>.

Alcuni server avrebbero potuto essere (scarsamente) protetti supponendo che un browser non potesse effettuare, ad esempio DELETErichiesta di origine incrociata o richiesta di origine incrociata con X-Requested-Withintestazione, pertanto tali richieste sono "attendibili".

Per assicurarsi che il server supporti davvero CORS e che non capiti semplicemente di rispondere a richieste casuali, viene eseguito il preflight.

Ecco un altro modo di vederlo, usando il codice:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

Pre-CORS, il tentativo di exploit sopra fallito perché viola la politica della stessa origine. Un'API progettata in questo modo non necessitava della protezione XSRF, poiché era protetta dal modello di sicurezza nativo del browser. Per un browser pre-CORS era impossibile generare un POST JSON tra origini.

Ora CORS entra in scena - se non fosse richiesto l'adesione a CORS tramite pre-volo, improvvisamente questo sito avrebbe avuto un'enorme vulnerabilità, senza colpa propria.

Per spiegare perché ad alcune richieste è consentito saltare il pre-volo, questo risponde alla specifica:

Una semplice richiesta di origine incrociata è stata definita come congruente con quelle che possono essere generate da agenti utente attualmente distribuiti che non sono conformi a questa specifica.

Per districare ciò, GET non è pre-flight perché è un "metodo semplice" come definito da 7.1.5. (Le intestazioni devono anche essere "semplici" per evitare il pre-volo). La giustificazione di ciò è che la richiesta GET "semplice" tra origini potrebbe già essere eseguita ad es. <script src="">(Ecco come funziona JSONP). Poiché qualsiasi elemento con un srcattributo può innescare un GET tra origini, senza pre-volo, non ci sarebbe alcun vantaggio in termini di sicurezza nel richiedere un pre-combattimento su XHR "semplici".

Sento che le altre risposte non si stanno concentrando sul motivo per cui il pre-combattimento aumenta la sicurezza.

scenari:

1) Con pre-volo . Un utente malintenzionato invia una richiesta dal sito dummy-forums.com mentre l'utente viene autenticato su safe-bank.com
Se il server non verifica l'origine e in qualche modo presenta un difetto, il browser emetterà una richiesta pre-volo, OPZIONE metodo. Il server non sa nulla di quel CORS che il browser si aspetta come risposta, quindi il browser non procederà (nessun danno)

2) Senza pre-volo . Un utente malintenzionato forgia la richiesta nello stesso scenario di cui sopra, il browser emetterà immediatamente la richiesta POST o PUT, il server la accetterà e potrebbe elaborarla, ciò potrebbe causare alcuni danni.

Se l'attaccante invia una richiesta direttamente, tra origini, da un host casuale è molto probabile che si stia pensando a una richiesta senza autenticazione. Questa è una richiesta falsa, ma non una richiesta xsrf. quindi il server controllerà le credenziali e fallirà. CORS non tenta di impedire a un utente malintenzionato che disponga delle credenziali di inoltrare richieste, sebbene una lista bianca possa contribuire a ridurre questo vettore di attacco.

Il meccanismo pre-volo aggiunge sicurezza e coerenza tra client e server. Non so se questo vale la stretta di mano in più per ogni richiesta poiché la memorizzazione nella cache è praticamente utilizzabile lì, ma è così che funziona.

Inoltre, per i metodi di richiesta HTTP che possono causare effetti collaterali sui dati dell'utente (in particolare, per metodi HTTP diversi da GET o per l'utilizzo POST con determinati tipi MIME), la specifica impone che i browser "eseguano il preflight" della richiesta

fonte

Le richieste pre-volo sono necessarie per le richieste che possono cambiare stato sul server. Esistono 2 tipi di richieste:

1) Chiamate che non possono cambiare stato sul server (come GET) - L'utente potrebbe ottenere una risposta per la richiesta (se il server non controlla l'origine) ma se il dominio richiedente non viene aggiunto all'intestazione della risposta Access-Control- Allow-Origin, il browser non mostra i dati all'utente, ovvero la richiesta viene inviata dal browser ma l'utente non è in grado di visualizzare / utilizzare la risposta.

2) Chiamate che possono cambiare stato sul server (come POST, DELETE) - Dato che in 1), vediamo che il browser non blocca la richiesta ma la risposta, le chiamate che cambiano stato non dovrebbero essere fatte senza controlli preventivi . Tali chiamate potrebbero apportare modifiche a un server fidato che non controlla l'origine delle chiamate (chiamato falsificazione richiesta cross site), anche se la risposta al browser potrebbe essere un errore. Per questo motivo, abbiamo il concetto di richieste pre-volo che effettuano una chiamata OPTIONS prima di poter inviare al server qualsiasi chiamata che cambia stato.

Non sono le richieste preflight su Performance ? Con le richieste preflight, un client può sapere rapidamente se l'operazione è consentita prima di inviare una grande quantità di dati, ad esempio in JSON con metodo PUT. O prima di trasferire i dati sensibili nelle intestazioni di autenticazione via cavo.

Il fatto di PUT, DELETE e altri metodi, oltre alle intestazioni personalizzate, non sono consentiti per impostazione predefinita (hanno bisogno di un'autorizzazione esplicita con "Access-Control-Request-Methods" e "Access-Control-Request-Headers"), che suona proprio come un doppio controllo, poiché queste operazioni potrebbero avere più implicazioni per i dati dell'utente, invece di GET richieste. Quindi, sembra che:

"Ho visto che permetti richieste cross-site da http: //foo.example , ma sei SICURO di consentire richieste DELETE? Hai considerato gli impatti che queste richieste potrebbero causare nei dati dell'utente?"

Non ho capito la correlazione citata tra le richieste preflight e i vantaggi dei vecchi server. Un servizio Web implementato prima di CORS, o senza consapevolezza CORS, non riceverà mai NESSUNA richiesta cross-site, perché prima la loro risposta non avrà l'intestazione "Access-Control-Allow-Origin".

In un browser che supporta CORS, le richieste di lettura (come GET) sono già protette dalla stessa politica di origine: un sito Web dannoso che tenta di effettuare una richiesta tra domini autenticata (ad esempio al sito Web di Internet banking della vittima o all'interfaccia di configurazione del router) non lo farà essere in grado di leggere i dati restituiti perché la banca o il router non imposta l' Access-Control-Allow-Originintestazione.

Tuttavia, con la scrittura di richieste (come POST) il danno è causato quando la richiesta arriva al server web. * Un server web potrebbe controllare l' Originintestazione per determinare se la richiesta è legittima, ma questo controllo spesso non viene implementato perché il server web non è necessario per CORS o il server web è più vecchio di CORS e pertanto presuppone che i POST tra domini siano completamente vietati dalla stessa politica di origine.

Questo è il motivo per cui ai server web viene data la possibilità di opt-in per ricevere richieste di scrittura tra domini .

_{* Essenzialmente la versione AJAX di CSRF.}