Cross-Origin Resource Sharing (CORS) - Mi manca qualcosa qui?

Question

Stavo leggendo su CORS e penso che l'implementazione sia sia semplice che efficace.

Tuttavia, a meno che manchi qualcosa, penso che ci sia una grande parte mancante nelle specifiche. Come ho capito, è il sito straniero che decide, in base all'origine della richiesta (e facoltativamente includendo le credenziali), se consentire l'accesso alle sue risorse. Questo va bene.

Ma che cosa succede se il codice dannoso nella pagina desidera POSTARE le informazioni sensibili di un utente a un sito estraneo? Ovviamente il sito straniero sta per autenticare la richiesta. Quindi, ancora una volta se non mi manca qualcosa, CORS rende in realtà più facile rubare informazioni sensibili.

Penso che avrebbe molto più senso se il sito originale potesse fornire anche un elenco immutabile di server a cui la sua pagina è autorizzata ad accedere.

Quindi la sequenza espansa sarebbe:

1. alimentazione una pagina con la lista dei server CORS accettabili (abc.com, xyz.com, ecc)
2. Pagina vuole fare una richiesta XHR a abc. com - il browser lo consente perché è nella lista consentita e l'autenticazione procede normalmente
3. Page vuole fare una richiesta XHR a malicious.com - richiesta respinta localmente (ad esempio dal browser) perché il server non è nella lista.

so che codice dannoso potrebbe ancora utilizzare JSONP per fare il suo sporco lavoro, ma avrei pensato che una completa implementazione di CORS implicherebbe la chiusura del tag script multi-sito scappatoia.

Ho anche verificato le specifiche CORS ufficiali (http://www.w3.org/TR/cors) e non ho trovato alcun riferimento a questo problema.

Answer 1

Mi sembra che CORS stia semplicemente espandendo ciò che è possibile e provando a farlo in modo sicuro. Penso che questa sia chiaramente una mossa conservatrice. Rendere più severa la politica del dominio incrociato su altri tag (script/immagine) mentre è più sicura, spezzerebbe un sacco di codice esistente e renderebbe molto più difficile adottare la nuova tecnologia. Spero che si possa fare qualcosa per colmare questa lacuna nella sicurezza, ma penso che debbano assicurarsene una transizione facile.

Answer 2

Ma che cosa succede se il codice dannoso nella pagina desidera POSTARE le informazioni sensibili di un utente a un sito estraneo?

Che ne pensi? Puoi già farlo senza CORS. Persino fino a Netscape 2, sei sempre stato in grado di trasferire informazioni a qualsiasi sito di terze parti tramite semplici richieste GET e POST causate da interfacce semplici come form.submit(), new Image o impostando window.location.

Se il codice dannoso ha accesso a informazioni riservate, è già stato perso completamente.

3) Pagina vuole fare una richiesta XHR per malicious.com - richiesta respinta localmente

Perché una pagina di provare a fare una richiesta XHR a un sito che non sia già whitelist?

Se si sta tentando di proteggere dalle azioni di script dannoso iniettati a causa di vulnerabilità XSS, si sta tentando di correggere il sintomo, non la causa.

Answer 3

Condivido le preoccupazioni di David. La sicurezza deve essere costruita strato per strato e una lista bianca servita dal server di origine sembra essere un buon approccio.

Inoltre, questa lista bianca può essere utilizzata per chiudere scappatoie esistenti (moduli, tag di script, ecc ...), è sicuro presumere che un server che serve la lista bianca è progettato per evitare problemi di retro compatibilità.

Answer 4

Le tue preoccupazioni sono completamente valide.

Tuttavia, è più preoccupante il fatto che non sia necessario alcun codice nocivo presente per poter essere sfruttato. Esistono numerose vulnerabilità di scripting cross-site basate su DOM che consentono agli aggressori di sfruttare il problema descritto e inserire JavaScript dannoso in pagine Web vulnerabili. Il problema è più che la semplice destinazione dei dati, ma da dove i dati possono essere ricevuti.

ho parlare di questo più in dettaglio qui:

• http://isisblogs.poly.edu/2011/06/22/cross-origin-resource-inclusion/
• http://files.meetup.com/2461862/Cross-Origin%20Resource%20Inclusion%20-%20Revision%203.pdf

Answer 5

Ho anche verificato il funzionario CORS spec e non sono riuscito a trovare alcuna menzione di questo problema.

Diritto. La specifica CORS sta risolvendo un problema completamente diverso. Ti stai sbagliando che peggiora il problema - non rende il problema né migliore né peggiore, perché una volta che uno script dannoso è in esecuzione sulla tua pagina, può già inviare i dati ovunque.

La buona notizia, però, è che non v'è una specifica widely-implemented che risolve questo problema: il Content-Security-Policy. Ti consente di istruire il browser per porre limiti a ciò che la tua pagina può fare.

Ad esempio, è possibile indicare al browser di non eseguire alcuno script inline, che causerà immediatamente una perdita di molti attacchi XSS. Oppure, come richiesto qui, puoi dire esplicitamente al browser a quali domini è consentito contattare la pagina.

Answer 6

Il problema non è che un sito possa accedere ad altre risorse di siti a cui ha già avuto accesso. Il problema è di dominio - Se sto usando un browser nella mia azienda, e uno script ajax decide maliziosamente di provare 10.0.0.1 (potenzialmente il mio gateway), potrebbe avere accesso semplicemente perché la richiesta ora proviene dal mio computer (forse 10.0.0.2).

Quindi la soluzione - CORS. Non sto dicendo che sia il migliore, ma risolve questo problema.

1) Se il gateway non può restituire l'intestazione di origine accettata 'bobthehacker.com', la richiesta viene rifiutata dal browser. Questo gestisce server vecchi o non preparati.

2) Se il gateway consente solo gli elementi del dominio myinternaldomain.com, rifiuterà un'origine di "bobthehacker.com". Nel caso CORS SEMPLICE, restituirà effettivamente i risultati. Di default; puoi configurare il server in modo che non lo faccia nemmeno.Quindi i risultati vengono scartati senza essere caricati dal browser.

3) Infine, anche se accetterebbe determinati domini, si ha il controllo sulle intestazioni accettate e rifiutate per rendere la richiesta da tali siti conforme a una determinata forma.

Nota: le intestazioni ORIGIN e OPZIONI sono controllate dal richiedente, ovviamente qualcuno che crea la propria richiesta HTTP può inserire tutto ciò che desidera. Tuttavia, un browser moderno compatibile con CORS lo fa. È il browser che controlla l'interazione. Il browser impedisce a bobthehacker.com di accedere al gateway. Questa è la parte che ti manca.