È possibile rubare un cookie non sicuro (Flag di sicurezza è falso) quando il server Web (IIS) consente solo Https?
Ovviamente è possibile ...
Pensaci in questo modo:
secure garantisce che il cookie sia bloccato su HTTPS. Ora, se rimuovi il primo passaggio, ovviamente il cookie può essere inviato in una richiesta HTTP ...
Quale può essere inviato a un server diverso ....
Che sta impersonando il tuo server web.
Esistono molte forme di attacco (ad es. spoofing del DNS) che potrebbero causare la connessione con il server sbagliato e, naturalmente, HTTPS (utilizzando TLS / SSL) lo attenua abbastanza bene.
Anche se la tua applicazione reale utilizza HTTPS, non c'è alcuna garanzia che il server falso sia, giusto?
Ma non fermiamoci qui, c'è uno scenario ancora più banale.
Dici che il tuo server web consente solo HTTPS.
Cioè, accetterà solo le richieste che sono HTTPS e rifiuterà a titolo definitivo qualsiasi richiesta HTTP.
Ma quella richiesta HTTP era già stata inviata in chiaro.
Se un utente malintenzionato - o anche solo un programmatore disattento - può causare solo una singola richiesta da inviare il browser dell'utente su HTTP, quindi verrà inviato quel cookie. Su HTTP. In chiaro. Senza crittografia. (In realtà ho visto questo in natura, il 2 ° tipo più del 1 ° ...)
Spesso, questo è tutto ciò che è necessario.
Fai un favore a te stesso (e ai tuoi utenti), applica sempre HTTPS ai livelli tutti .
Il punto principale è che sebbene il server accetti solo HTTPS, il client non lo conosce . L'utente umano potrebbe, ma non il client software.
Supponi la seguente configurazione:
https://www.bank.com/ . Quindi l'autore dell'attacco deve solo includere nel forum Web il seguente estratto HTML:
<img src="http://www.bank.com:443/foo.png"/>Proprioquesto.Quandoiltuobrowserlovedrà,apriràunaconnessioneTCPawww.bank.comsullaporta443;quellaconnessionefunzionerà,perchéwww.bank.comeffettivamentesiaspettaconnessioniinentratasullaporta443.Naturalmente,labancavorrà"parlare SSL", ma a livello TCP, la connessione ha successo (SYN, ACK + SYN, ACK).
Quindi il tuo browser invia una richiesta HTTP GET tramite la connessione. Quella richiesta includerà il cookie , in semplice visualizzazione, poiché il target è www.bank.com e il cookie non è stato contrassegnato come "sicuro". Naturalmente, il server rifiuterà il tentativo perché si aspetta un messaggio ClientHello SSL, non HTTP; tuttavia, è troppo tardi, il cookie ha già viaggiato prima degli sguardi indiscreti dell'attaccante.
(Le varianti degli attacchi includono un attaccante più attivo con, ad esempio, lo spoofing del DNS per impersonare un falso www.bank.com , ma lo stesso principio rimane: poiché il browser non sa che il server farà solo HTTPS, lo farà allegramente invia il cookie su un semplice HTTP.)