Implicazioni del modello di sicurezza dei cookie HTTP sulle connessioni HTTPS

Question

Implicazioni del modello di sicurezza dei cookie HTTP sulle connessioni HTTPS

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

1

Ho una funzionalità che richiederebbe all'utente di fornire l'URL per uno script personalizzato, archiviare l'URL in un cookie e incorporare lo script nelle risposte successive.

Questo, naturalmente, solleva immediatamente preoccupazioni sulle possibilità di un attacco di cross-site scripting, ma usando HTTP, dato che nessun terzo può manipolare i cookies * a meno che non esegua un attacco man-in-the-middle, al quale puntualizzare che è più facile inserire direttamente gli script nella pagina, questo non compromette ulteriormente l'integrità del sito.

* supponendo che tutte le porte di tutti i sottodomini del dominio di origine siano attendibili, poiché i cookie non rientrano nella stessa regolazione dell'origine originale

Utilizzando HTTPS, tuttavia, ci si aspetterebbe che, utilizzando la crittografia e la certificazione appropriate, come qualsiasi altra parte della comunicazione, i cookie possano essere attendibili per provenire dall'utente, impostando indirettamente tramite il server o direttamente tramite un apposito interfaccia utente, eliminando il rischio di un man-in-the-middle.

Risulta che non è questo il caso, dal momento che i browser possono essere istruiti a non inviare cookie impostati attraverso canali sicuri su canali non sicuri (utilizzando l'attributo secure ), ma inviano prontamente i cookie ottenuti attraverso canali non sicuri su canali sicuri.

Quindi, ad esempio, un utente malintenzionato, deviando il traffico intorno a un punto di accesso wireless, potrebbe attirare una vittima nella richiesta di una pagina nel dominio specificato tramite HTTP (facendo clic su un collegamento, visualizzando una risorsa incorporata come un'immagine o reindirizzandola a esso), rispondere con un cookie contraffatto e fare in modo che la vittima utilizzi il cookie contraffatto mentre comunica con il server utilizzando HTTPS (iniettando uno script dannoso, fissando la sua sessione ecc.).

Considerando tutto ciò, ho diverse domande:

La comprensione di cui sopra è corretta, e se un server che comunica con il client tramite HTTPS considera tutti i cookie potenzialmente compromessi, li utilizza solo in un modo che impedisce di compromettere la sicurezza del sito (consentendo solo una selezione di script predefiniti fidati, rigenerazione dell'ID di sessione, ecc.)?
Esiste un modo per fornire il framework disponibile di HTTP per garantire l'integrità dei cookie quando si utilizza una connessione sicura a cui non avevo pensato? (Forse usando la crittografia?)
C'è qualche sforzo di standardizzazione in corso per risolvere questo problema, di cui non ho sentito parlare? In caso contrario, come mai i fornitori di browser, che si spingono fuori strada per applicare la stessa politica di origine ovunque e per avvisare gli utenti dei rischi di contenuti misti, non affrontano questa debolezza nel protocollo?

http cookies tls same-origin-policy

posta Joó Ádám 18.09.2015 - 21:18

fonte

2 risposte

2

Sì, la tua comprensione è corretta.

Risposta breve: imposta una Politica HSTS (HTTP Transport Transport Security). Una volta impostato per ogni istanza del browser, qualsiasi semplice connessione HTTP creata dal browser verrà automaticamente aggiornata a HTTPS.

Si noti che questo ha effetto solo dopo la prima visita, quando l'intestazione HTTP HSTS viene ricevuta su HTTPS. Per evitare attacchi che impostano il cookie prima della loro prima visita da un browser, puoi richiedere che il tuo dominio sia elencato nel Preload HSTS . Questo elenco è incluso nelle build dai principali fornitori di browser e non richiede una prima visita a un dominio per abilitare HSTS per tutti i domini precaricati.

L'uso del precarico HSTS significa che ogni sottodominio del tuo sito dovrà utilizzare HTTPS - questa è comunque una buona pratica, perché come hai notato la stessa politica di origine per i cookie non è molto severa quando si tratta di domini.

L'approccio precedente impedisce a Man-In-The-Middle di iniettare i cookie nel tuo sito intercettando qualsiasi richiesta HTTP e reindirizzarlo al tuo dominio e impedirà gli attacchi di sottodominio .

Il flusso con HSTS

Senza precarico

First HTTP visit --> Server redirects to HTTPS --> HSTS Set
--> Cookie containing JavaScript set

Next HTTP Visit | browser upgrades to HTTPS --> Safe JavaScript in cookie runs

Con precarico HSTS

First HTTP visit | browser upgrades to HTTPS --> ...

Qualsiasi utente malintenzionato che reindirizza l'utente da un attacco MITM

Senza HSTS

User requests a plain HTTP site --> HTTP 3xx redirect to your site --> Evil cookie set over plain HTTP
User requests your site over HTTP --> Server redirects to HTTPS --> Malicious JavaScript is ran

Con HST

User requests a plain HTTP site --> HTTP 3xx redirect to your site | browser upgrades connection to HTTPS --> Attack thwarted as attacker cannot MITM the HTTPS connection

Anche con i cookie di sicurezza, il server non può interrogare il fatto che il flag di sicurezza è stato impostato - tutto il server riceve è la coppia nome / valore. Pertanto, non c'è modo di sapere che il cookie è stato avvelenato. L'HSTS è una soluzione efficace perché elimina l'insicuro canale HTTP semplice.

_{Si noti che le domande dicono che un URL è memorizzato nel cookie non diretto JavaScript - tuttavia includere il codice JS da un dominio di terze parti ha esattamente lo stesso effetto - il codice viene eseguito nell'origine del dominio richiedente}

Se hai bisogno del supporto HTTP semplice

Il motivo per cui hai bisogno di HSTS è perché la Stessa politica di origine per i cookie è più lasso di quelli del DOM e durante le richieste AJAX:

cookies have scoping mechanisms that are broader and essentially incompatible with same-origin policy rules (e.g., as noted, no ability to restrict cookies to a specific host or protocol) - sometimes undoing some content security compartmentalization mechanisms that would otherwise be possible under DOM rules.

Quindi, l'unico modo per proteggere i cookie che contengono codice JS in modo sicuro è avere un semplice supporto HTTP solo su un dominio completamente diverso. per esempio. https://example.org con HTTPS e HSTS per il tuo contenuto sicuro e il cookie e http://example.com per il tuo contenuto non sicuro.

Un'alternativa ai cookie

Se non riesci a fare quanto sopra, il perché non utilizzare HTML5 Session Storage invece dei cookie, e solo impostare o leggere il valore su HTTPS? Questo metodo ti consentirà di memorizzare l'URL JavaScript nel browser ed eseguirlo secondo necessità, senza la possibilità che un MITM intercetti e modifichi il valore su un semplice HTTP:

separation means that a value saved to LocalStorage on http://htmlui.com cannot be accessed by pages served from https://htmlui.com (and vice versa). [*]

risposta data 22.09.2015 - 09:48

fonte

Leggi altre domande sui tag http cookies tls same-origin-policy

Rilevazione di diversi jailbreak Come costruire il segreto pre-master [duplicato]

score 2 · Accepted Answer

In generale, un server considera ogni elemento di dati in arrivo come potenzialmente ostile. C'è, qui, un problema di definizione quando parli di "integrità del sito": questo può riguardare l'integrità del sito come l'utente lo vede , o l'integrità del sito come altri utenti vederlo . Se tutto il server fa restituire il cookie al client che lo ha detto, come uno script da eseguire, allora il problema è più semplice.

A quanto ho capito, temi il seguente scenario:

Il sito consente a un utente U di caricare alcuni Javascript, che il tuo server "memorizzerà" e servirà allo stesso utente U . Questo caricamento avviene attraverso un processo correttamente protetto (HTTPS, autenticazione utente ...). Lo spazio di archiviazione non viene effettivamente eseguito nel server, ma come valore di cookie nel browser dell'utente.
Sfruttando la creduloneria dell'utente, o dirottando l'accesso alla rete dell'utente, l'hacker riesce a spingere alcuni H ostili nel browser dell'utente, collegato (come valore del cookie) al tuo server nome.
Quando l'utente U si connette al tuo server, il codice Javascript H è inviato al tuo server (come un coookie) e il server lo rimanda al client, da eseguire.

Descritto in questo modo, allora il tuo problema è davvero riconoscere i cookie "ufficiali" che sono stati trasferiti sul tuo server attraverso il normale processo (con HTTPS e autenticazione dell'utente). La crittografia può aiutare con un MAC : vuoi taggare un valore del cookie, in modo che solo il tuo server possa calcolare un tag corretto e può verificarlo. In questo modo, il tuo server rifiuterà i valori dei cookie che non sono stati precedentemente registrati attraverso il processo di registrazione sicuro. Nello scenario sopra riportato, il valore di H ostile mancherebbe di un valore MAC corretto (poiché l'utente malintenzionato non conosce la chiave MAC utilizzata dal server), quindi il server rifiuterà di inviare nuovamente i contenuti dei cookie come script da eseguire.

In generale, ciò che stai cercando di fare è di scaricare lo stato del server sui client. Questo può essere fatto con:

un MAC per preservare l'integrità (contro i clienti che modificano i loro cookie, volenti o nolenti);
crittografia, se il contenuto dello stato non deve essere mostrato all'utente (questo non si applica al tuo caso specifico, come lo descrivi).

Per alcuni dettagli, vedi questa domanda .

Fai attenzione che le dimensioni di un singolo cookie e il numero di cookie registrati da un browser per un dato sito siano entrambi soggetti a browser- limitazioni specifiche .