Protezione dagli attacchi cookie cross-subdominio

21

Ho letto degli attacchi cookie cross-subdomain qui .

Una rapida panoramica di come funziona (da Wikipedia):

  1. Un sito web www.example.com distribuisce sottodomini a terze parti non attendibili
  2. Una di queste feste, Mallory, che ora controlla evil.example.com, attira Alice nel suo sito
  3. Una visita a evil.example.com imposta un cookie di sessione con il dominio .example.com nel browser di Alice
  4. Quando Alice visita www.example.com, questo cookie verrà inviato con la richiesta, come indicato dalle specifiche per i cookie, e Alice avrà la sessione specificata dal cookie di Mallory.
  5. Se Alice ora accede, Mallory può usare il suo account.

Stiamo creando un'app Web in cui i clienti avranno i propri sottodomini: subdomain.ourapp.com .

Ogni cliente sarà in grado di caricare file modello che possono contenere javascript (per l'interazione lato client).

Poiché javascript può essere usato per leggere / scrivere cookie, come possiamo prevenire l'attacco di fissazione della sessione sopra? Si noti che stiamo memorizzando solo l'ID di sessione nel cookie.

Siti come squarespace.com consentono anche agli utenti di inserire il proprio javascript nelle loro pagine sul proprio sottodominio. Dal momento che sarebbe quasi impossibile provare a filtrare le dichiarazioni javascript che impostano / leggono i cookie nei file modello caricati, come possiamo mitigare questo vettore di attacco?

    
posta F21 06.04.2013 - 14:35
fonte

5 risposte

10

Lo scenario specifico può essere facilmente impedito: Crea un nuovo sessionid al login.

Si noti che i problemi esistono tra i domini, se il sessionid è un parametro url.

Generare un nuovo sesionid, tuttavia, non è sufficiente per prevenire altri tipi di attacco: una volta che Alice ha effettuato l'accesso e visita il sottodominio di Mallory, il cookie verrà trasmesso?

È prassi comune utilizzare un dominio completamente diverso per tutte le attività attendibili. Ad esempio, Google utilizza google.com per attività attendibili e * .googleusercontent.com per siti non attendibili.

    
risposta data 06.04.2013 - 17:33
fonte
8

La risposta più sicura è usare domini completamente diversi.

Se si utilizzano sottodomini dello stesso dominio, iniziare imparando a conoscere i dettagli dei possibili attacchi. C'è già molto scritto su questo, su questo sito. Vedi, ad es. Quali attacchi di cookie sono possibili tra i computer nei relativi domini DNS (* .example.com)? , Prevenire la webapp non sicura sul sottodominio compromette la sicurezza della webapp principale , Sottodomini specifici dell'utente: sicurezza JavaScript , la mia risposta a È aumentata la sicurezza utilizzando un sottodominio per cliente in un'app web .

Se si utilizzano sottodomini dello stesso dominio, ecco alcuni passaggi che è possibile adottare per proteggersi: memorizzare tutti gli stati sul lato server (non utilizzare i cookie per memorizzare lo stato sul client, l'unico cookie che si usa dovrebbe essere un ID di sessione); creare un nuovo ID di sessione al login e alla disconnessione; assicurati che il cookie abbia come ambito il sottodominio (ad esempio, il suo ambito dovrebbe essere foo.ourapp.com, non .ourapp.com); controllare sul lato server per essere sicuro di non ricevere più cookie con il nome; assicurati di proteggerti dalla fissazione della sessione; se utilizzi CORS, fai molta attenzione con la tua norma sui domini incrociati per assicurarti di non consentire le richieste di sottodominio secondario.

    
risposta data 06.04.2013 - 22:23
fonte
5

Suffisso pubblico ha un elenco di domini che tutti i fornitori (Chrome / Firefox / IE / Safari / Opera) utilizzano per evitare questo problema di rubare i cookie da altri sottodomini (insieme ad altre funzionalità). L'elenco viene aggiornato ogni giorno ed è mantenuto su Github .

Ho ricevuto queste informazioni da blog di Heroku .

Ho verificato che il dominio googleusercontent.com di Google è incluso nell'elenco insieme a herokuapp.com , herokussl.com domini.

    
risposta data 20.09.2016 - 12:12
fonte
0

Ho appena avuto un'idea. Possiamo prendere in prestito un'idea dal Pattern token crittografato : crittografare il valore del cookie!

Se si accede al cookie solo dal server, è possibile utilizzare la crittografia simmetrica a basso costo. Altrimenti, utilizza la più costosa crittografia a chiave pubblica.

Ciò ti consentirà di rilevare quando sottodomini malevoli cancellano i cookie e / o rilevano i loro tentativi di scrivere cookie falsi.

    
risposta data 10.06.2014 - 16:17
fonte
0

Sono riuscito a risolvere questo problema memorizzando il sottodominio esatto in Session data on Server. E invio del sottodominio esatto nell'impostazione del dominio dei cookie.

Se l'utente visita dom1.website.com per la prima volta lo memorizzerò in Session e controllerà in tutte le future richieste che corrisponde alla sessione di reset sul server.

Quindi, se l'utente che utilizza è riuscito a ingannare il browser e è riuscito a inviare lo stesso cookie per dom2.website.com, il codice controllerà che il valore del nome di dominio memorizzato in Session non corrisponda al dominio che ha inviato. quindi resetterà la sessione sul server.

Solo l'effetto collaterale è che anche la sessione su dom1.website.com verrà cancellata.

    
risposta data 04.08.2017 - 10:54
fonte

Leggi altre domande sui tag