Iniezione / invalidazione della sessione MITM

Naviga le tue risposte
1

Quando si invia un cookie al server, il browser non restituisce il flag "sicuro": il server non può verificare se il cookie inviato proviene effettivamente dall'origine "sicura" ( link ). Potrebbe invece provenire dall'origine non sicura corrispondente ( link ). Inoltre un malintenzionato può utilizzare MITM per sovrascrivere qualsiasi cookie utilizzando l'origine non sicura: questo cookie iniettato verrà inviato dal browser anche all'origine protetta.

Quindi un utente malintenzionato potrebbe utilizzare un MITM per disconnettere qualcuno da qualsiasi sito Web HTTPs:

  1. Si collega al sito link di B's (il sito potrebbe essere un sito Web HTTPS completo senza alcun sito web http: // corrispondente) e ottenere un "sicuro" "cookie;
  2. Bob usa MITM per iniettare un <img src="http://example.com">(questositoWebnondeveesistereaffattocomespiegatodiseguito)inqualsiasialtrositoWebHTTPcheAlicestavisitando;
  3. IlbrowserdiAlicerecuperal'immaginenel link ;
  4. Bob forgia una risposta (il sito collegamento potrebbe non esistere affatto) e reimposta il cookie di sessione su qualsiasi valore;
  5. Alice è disconnessa example.com.

Blocco sessione

Utilizzando una leggera variazione, Bob potrebbe creare un account utente falso su link , accedere a esso, ottenere l'ID di sessione e impostarlo utilizzando lo stesso tecnica sul browser di Alice. In questo modo, Alice potrebbe essere ingannata nell'invio di informazioni private sul falso account utente. Bob può quindi accedere utilizzando questo account falso per ottenere le informazioni private di Alice:

  1. Bob crea un account su link con accesso;
  2. Alice accede al link
  3. Bob accede al link utilizzando il suo account falso e ottiene un ID di sessione per questo account falso;
  4. Bob MITM a <img src="https://example.com"/>suqualsiasisitoWebHTTPcheAlicestavisitando;
  5. IlbrowserdiAlicerecuperal'immaginenel link ;
  6. Bob forgia la risposta e imposta un cookie utilizzando il suo ID di sessione;
  7. La successiva richiesta di Alice sul link sta infatti utilizzando l'account falso ma potrebbe non essere notata a meno che non verifichi il suo accesso su ogni pagina;
  8. Alice invia alcuni dati privati sul sito web (aggiunge un segnalibro, effettua una richiesta di motore di ricerca, carica alcune foto ...);
  9. Bob accede utilizzando l'account falso e recupera i dati privati di Alice.

C'è qualche ragione per cui non funziona? C'è un modo per evitarlo? Questo attacco ha un nome? C'è qualche riferimento o discussione disponibile su questo (OWASP, documenti di sicurezza ...)? Questa vulnerabilità è stata utilizzata nella pratica? C'è qualche soluzione / piano per aggirarlo aggiungendo funzionalità ai browser (forse qualche nuova intestazione del cookie per i cookie per-origine)?

Questo è leggermente discusso in RFC 6265 sezione 8.6 "Debole integrità".

Quello che sto descrivendo è meglio descritto dal documento "Difese robuste per la falsificazione di richieste tra siti" 2 come" sovrascrittura dei cookie "(citato da fatfredyy).

Possibili soluzioni

  1. Usa HSTS con includeSubDomains

    Non supportato molto bene (browser più vecchi). Problema di bootstrap come sottolineato in una risposta di Hendrik Brummermann.

  2. Utilizza l'ID sessione SSL per il tracciamento della sessione anziché i cookie

    L'ID sessione SSL non può essere iniettato da un aggressore MITMing. Le sessioni sono stabili con questo tipo di configurazione?

  3. Utilizza l'autenticazione del certificato client per il tracciamento della sessione anziché i cookie

    Non molto intuitivo (e privo di funzionalità standard di "disconnessione").

posta ysdx 19.07.2012 - 16:02
fonte

2 risposte

1

Sì, questo attacco funziona in pratica.

Per il proprietario di un sito ci sono fondamentalmente due modi per mitigare questo attacco:

  • HSTS, ma la stessa HSTS è vulnerabile a un utente malintenzionato attivo alla prima richiesta.
  • mostra l'immagine del nome utente / profilo dell'utente che ha effettuato l'accesso, ma questo è vulnerabile a un attacco tempestivo.

In teoria questo attacco potrebbe essere prevenuto da una modifica del protocollo: se il browser avesse incluso il dominio e le informazioni http / https nell'intestazione del cookie, il server sarebbe in grado di verificarlo.

I browser possono eliminare cookie protetti da qualsiasi tentativo di modifica da parte di una fonte http. Ignorare tali modifiche è una cattiva idea perché interromperà il logout su alcune pagine.

    
risposta data 19.07.2012 - 22:54
fonte
3

Non capisco davvero cosa stai dicendo, ma cercherò di capire / spiegare alcune cose.

Innanzitutto, il flag di sicurezza nel cookie significa che questo valore del cookie verrà inviato solo quando si accede al sito tramite la connessione HTTPS .

In secondo luogo, i cookie sono dominio e percorso in modo che non vengano inviati a un altro dominio o percorso.

L'attacco che stai descrivendo è noto come attacco di accesso CSRF, in gran parte trascurato / sottovalutato e contrassegnato come un piccolo attacco di piccolo impatto (imho falsamente). Puoi leggere ulteriori informazioni in: "Difese robuste per falsi falsi tra siti"

E infine Se l'attaccante è in grado di montare il MITM con HTTP, possiamo fare ben poco e nulla sarà più sicuro di HTTPS. Quindi sono d'accordo con te, per essere sicuri i siti dovrebbero essere solo HTTPS completi o per niente. Inoltre, come misura aggiuntiva, i browser Web potrebbero impedire l'override di una risposta HTTP del modulo cookie sicuro.

    
risposta data 19.07.2012 - 19:52
fonte

Leggi altre domande sui tag

Avast dice che non ho bisogno di usare connessioni criptate per i miei account di posta elettronica Quante possibilità possono i computer di oggi controllare (al secondo) in un hash SHA512 di una voce casuale lunga 50 byte? [chiuso]