Quali attacchi di cookie sono possibili tra computer in domini DNS correlati (* .example.com)?

36

Qui, diversi server nello stesso dominio DNS emettono cookie in una varietà di impostazioni (scope, HTTPS, Secure) e un altro host emette un cookie con lo stesso valore.

Esempio

Supponiamo che un utente abbia il seguente cookie impostato a secure.example.com :

 authCookie = SomeSessionToken (Scope example.com, Secure, HTTPOnly)

Quindi l'utente passa a blog.example.com che è compromessa (forse in un'altra scheda). Imposta un cookie non HTTPOnly come questo:

 authCookie = AlternateSessionToken (Scope example.com, Secure, not-HTTPOnly)

La prossima richiesta di secure.example.com utilizzerà le credenziali alternative?

È possibile questo scenario?
- Il browser imposta due cookie diversi (con lo stesso nome) per due server rispettivi?

- Oppure authCookie viene sovrascritto?

    
posta random65537 05.03.2012 - 02:03
fonte

1 risposta

42

Riepilogo. Sì, questo è possibile. Non è un bug del browser. Fa parte della funzionalità come progettata dei cookie. Non c'è un browser che sia al sicuro da questo. I cookie sono tecnologia antica e il loro modello di sicurezza è solo parzialmente integrato con il resto del web. I dettagli sono disordinati e brutti.

I dettagli cruenti

Il sito blog.example.com può impostare i cookie con scope blog.example.com o con scope example.com . I cookie con quest'ultimo ambito verranno restituiti a secure.example.com , se l'utente visita secure.example.com .

Se il sito secure.example.com imposta un cookie con scope example.com , il sito blog.example.com può sovrascrivere quel cookie arbitrariamente. Ogni volta che i browser visualizzano un cookie con lo stesso nome e lo stesso scope di uno già presente nel contenitore dei cookie, eliminano il vecchio valore del cookie e lo sovrascrivono con il nuovo cookie. Pertanto, blog.example.com può sovrascrivere qualsiasi cookie il cui ambito è example.com .

Peggio ancora, un cookie può ombreggiare un cookie con un altro ambito. Supponiamo che secure.example.com imposti un cookie con scope secure.example.com e name SESSIONID . Supponiamo che blog.example.com imposti un cookie con scope example.com e lo stesso nome. Infine, supponiamo che l'utente visita il sito secure.example.com . Che succede? È brutto: il browser invia entrambi i cookie, in un ordine non definito, e il server non ha modo affidabile per sapere quale valore del cookie proviene da quale sito. Quindi, il server può rilevare che si trova in una situazione confusa, ma non ha un buon modo per non confondersi. Peggio ancora, alcuni framework di applicazioni web possono nascondere la confusione dal codice dell'applicazione, utilizzando uno dei valori del cookie e ignorando silenziosamente l'altro. Ciò può portare a qualcosa che si comporta in modo efficace come blog.example.com ha sovrascritto il cookie da secure.example.com , in una situazione in cui nessuno si sarebbe ragionevolmente aspettato che fosse in grado di farlo.

(Come nota a margine, il flag secure non impedisce la sovrascrittura di un cookie. Infatti, un sito HTTP può sovrascrivere un cookie con un flag secure , a condizione che i nomi di dominio siano correlati in modo appropriato. Il flag secure fornisce la protezione della riservatezza ma non la protezione dell'integrità.)

Infine, esiste un altro modo per eliminare i cookie: un sito dannoso può impostare un sacco di cookie, traboccando il limite fisso sul numero di cookie che il browser memorizzerà. Il risultato è che il browser "dimentica" i cookie più vecchi di altri siti. Ciò consente a blog.example.com di eliminare tutti i cookie impostati da secure.example.com (indipendentemente dal loro ambito) e quindi di impostare un nuovo cookie con l'ambito example.com che verrà rinviato a secure.example.com - che ha più o meno lo stesso effetto come sovrascrittura di un cookie esistente. Questo potrebbe essere ciò a cui stavi pensando quando hai menzionato "overflow di cookie cookie".

Discussione

È disordinato. Purtroppo, questo è il modo in cui i cookie funzionano su Internet. Se vuoi evitarlo, la difesa più semplice è usare un nuovo dominio di secondo livello per i siti non fidati. Probabilmente c'è una difesa migliore che non limita la denominazione dei tuoi siti, ma non so di cosa si tratta.

Come nota generale, per domande come queste su come funziona il web, consiglio vivamente il manuale sulla sicurezza del browser . È pieno di pepite. In questo caso, potresti leggere il suo materiale su la politica di origine identica per i cookie .

    
risposta data 05.03.2012 - 08:15
fonte

Leggi altre domande sui tag