Se una richiesta CORS non ha bisogno di autenticazione, perché non posso inviarla senza i cookie?

Question

Se una richiesta CORS non ha bisogno di autenticazione, perché non posso inviarla senza i cookie?

#1 da (3 voti)
#2 da (1 voti)

7

Molte volte negli ultimi N anni, avevo bisogno della mia pagina (ABC.com) per ottenere alcuni dati da un'origine diversa (XYZ.com) e visualizzarla (tutto in JavaScript, senza recupero del server).

Questo non funziona perché XYZ.com non ha ABC.com nella sua intestazione Access-Control-Allow-Origin . Se l'intestazione includeva ABC.com, i cookie del mio browser (ovvero il cookie di autenticazione) per XYZ.com verrebbero inviati insieme alla richiesta di XYZ.com. Capisco perfettamente perché il browser vorrebbe impedire a ABC.com di effettuare richieste autenticate su XYZ.com se non ha accesso.

Ma in tutti i miei scenari, le richieste fatte a XYZ.com sono risorse disponibili al pubblico, non c'è autenticazione / cookie necessari, chiunque può prenderle. So che ci sono soluzioni alternative per questo (chiedi al server di ABC.com di richiedere i dati da XYZ.com). O XYZ.com può pubblicare JSONP. Ma nei miei casi, a volte sto servendo il mio file dal file system locale, quindi non c'è un server. Ottenere da un server è un PITA. E infine, non ho avuto il controllo di XYZ.com e non posso costringerlo a pubblicare anche JSONP. n La carne della domanda - se ABC.com non è nell'intestazione del Controllo degli accessi per XYZ.com, perché il browser non consentirebbe al JavaScript di ABC.com di fare una richiesta a XYZ.com MA NON invia nessuna delle XYZ.com cookie memorizzati nel browser per quell'utente. Se i produttori di browser lo hanno fatto, questo apre l'utente a una sorta di altra vulnerabilità? Perché non riesco a pensare a niente. Cosa mi manca? E 'solo una questione di manodopera, ci vorrà troppo tempo per programmarlo?

access-control cors

posta viggity 21.02.2017 - 22:02

fonte

2 risposte

Leggi altre domande sui tag access-control cors

Questo file è dannoso e in che modo viene trasferito tramite youtube? Cookie sicuri protetti rispetto ai prefissi dei cookie

score 3 · Answer 1

Storia

Le implementazioni XMLHttpRequest originali non avevano il concetto di "permetti le credenziali" - tutte le richieste avevano le credenziali allegate. Ovviamente, ciò sarebbe estremamente pericoloso per consentire il cross-domain, quindi XMLHttpRequest è stato inizialmente autorizzato solo per la stessa origine. Quando è stato aggiunto CORS, volevano minimizzare le modifiche per ridurre il rischio di conseguenze indesiderate, quindi mantenere il comportamento della stessa origine per i siti non CORS aveva senso.

Autenticazione non prevista

Quando una richiesta non ha "Consenti credenziali" c'è il rischio che il browser includa inavvertitamente credenziali. Un esempio che il browser non può evitare sono le restrizioni di rete, come ad esempio un sito Internet che accede a un sito Intranet. Potrebbero esserci altri esempi, come i certificati client. Non sarei sorpreso se alcuni browser aggiungessero ancora un certificato cliente, anche su una richiesta non creduta.

Sicurezza prima

Le ragioni di cui sopra non sono così forti. CORS avrebbe potuto essere progettato per consentire richieste non credenziali per impostazione predefinita. Tuttavia, questo è il design più rischioso. Quando è stato sviluppato CORS, i progettisti di browser erano ben consapevoli dei problemi di sicurezza e hanno scelto di implementare la progettazione meno rischiosa.

score 1 · Answer 2

Credo che faccia parte della difesa a più livelli nell'ecosistema browser / server per contribuire a contrastare il Cross Site Request Forgery (CSRF)

References:

Wikipedia OWASP

Fondamentalmente, i browser non sanno quali risorse web potrebbero o potrebbero non aver bisogno di cookie o auth prima che vengano richieste. L'invio ciecamente dei cookie, ad esempio di ABC.com, significa che il browser non sa se l'utente vuole autorizzare su XYZ.com o meno. Quindi, si sbaglia dalla parte della cautela, se non viene detto diversamente.

Dal tuo primo paragrafo, lo capisci già. Quindi, supponiamo che ABC.com ospiti una bacheca (per esempio) e un utente malintenzionato pubblichi qualche javascript. quando la vittima legge quel messaggio, il suo browser ora legge ed esegue "just javascript" da ABC.com che ABC e XYZ non approvano né sanno nulla. Fondamentalmente, il browser non può dire cosa è "da" il proprietario di ABC.com e cosa potrebbe essere stato iniettato da un cattivo attore (magari tramite una rete pubblicitaria ospitata).

In ogni caso, è possibile effettuare richieste interdominio, ma non dovrebbero essere autenticate automaticamente.

Ad esempio, immagina di aver effettuato l'accesso a MyBank.com e di visitare ABC.com e BadGuy ha nascosto una richiesta javascript in un annuncio che ti viene mostrato, che in pratica dice "http://MyBank.com/xfer-money -to = BadGuy & amount = 100.00 "Se il tuo browser viene inviato con i cookie auth, BadGuy potrebbe fare fare al tuo browser qualcosa che non vuoi. Esempio ovviamente troppo semplificato, ma hai un'idea.

[Modifica] Inoltre, ho appena trovato questa risposta già esistente che, penso, legge meglio della mia. Aggiungendo come riferimento Scambio pila di sicurezza