Quali siti sono ancora vulnerabili a FireSheep?

In conclusione, tutto ciò che non utilizza HTTPS per tutte le connessioni è vulnerabile a Firesheep.

Posso immaginare che molti degli script del gestore originale non funzionano più perché un numero elevato di siti ha corretto i propri siti per utilizzare HTTPS. O se fossero veramente pigri, hanno solo modificato leggermente le cose per oscurare le cose.

Ho provato Firesheep quando è stato rilasciato e non ho potuto ascoltare il traffico pubblico con la scheda wifi integrata del mio portatile. Se questo è il problema che stai avendo è probabilmente perché non supporta la modalità di monitoraggio. Un dongle wifi USB da 10-20 $ risolverà il problema.  Ho un ASUS USB-N13 che supporta la modalità di monitoraggio. Credo che vada per 20 $ o giù di lì ora.

Come Rook menziona, l'intera rete di siti Stack Exchange è vulnerabile. In effetti, l'ultima volta che ho controllato i creatori di Stack Exchange non pensate nemmeno che sia importante . O almeno non era abbastanza importante per la difficoltà in questione.

Firesheep ha lo scopo di mostrare la nota insicurezza di non utilizzare HTTPS. Ha funzionato bene come molti siti Web hanno iniziato a utilizzare HTTPS subito dopo il rilascio.

C'è un altro uso per Firesheep che è un po 'meno conosciuto. Può anche essere utilizzato su reti WPA2-AES crittografate per mostrare la vulnerabilità "Hole196" in WPA2. Non credo che la versione originale di Firesheep includa questa funzionalità ma esistono versioni modificate che lo fanno. Il creatore di Firesheep pensava che includere la funzione WPA2 fosse troppo pericoloso, e sono d'accordo. (citazione necessaria)

Come rook, i siti di stackexchange indicati non utilizzano cookie (HTTPS) o HTTPS sicuri ovunque sui loro siti (tranne l'autenticazione tramite terzi).

Ciò significa che quando si effettua l'accesso a stackexchange, un intercettatore (utilizzando firesheep, wireshark o simili) può rubare i cookie che indicano che si è effettuato l'accesso a stackexchange. Possono quindi utilizzare questi cookie per mesi per accedere al tuo account come te.

Ora potrebbero anche essere in grado di prendere la tua password reale che è legata al tuo nome utente se origliano quando fai il login, a seconda del meccanismo che usi. Cioè se accedi a google / yahoo / myopenid / facebook le tue credenziali di accesso saranno protette dagli intercettatori che catturano i pacchetti attraverso la rete.

Tuttavia (!), se accedi con un account stackexchange non ci sono https (anche nel modulo post azione), quindi il tuo nome utente / password viene inviato a stackexchange in testo normale a chiunque si preoccupi di ascoltare.

Esistono due tipi di siti vulnerabili:

1. Siti che utilizzano HTTP ovunque sul sito. Alcuni siti supportano solo HTTP e non supportano HTTPS (ad es. StackExchange); sono vulnerabili. Alcuni siti utilizzano un mix di HTTP e HTTPS (ad es. Amazon); anche loro sono solitamente vulnerabili.

2. Siti che utilizzano cookie che non dispongono del flag sicuro. I cookie con il flag sicuro verranno inviati solo tramite HTTPS. I cookie senza il flag di sicurezza verranno restituiti al sito tramite qualsiasi connessione, inclusi HTTP e HTTPS. (Se un sito imposta un cookie non sicuro su una connessione HTTPS, verrà comunque inviato su connessioni HTTP.) Pertanto, se il sito imposta cookie non sicuri, un utente malintenzionato attivo può attivare il browser per connettersi al sito tramite HTTP e poi rubare il cookie. Questo si applica anche se il sito utilizza HTTPS in tutto il sito.

Per difendersi dagli attacchi tipo Firesheep, i siti devono fare due cose:

1. Devono utilizzare HTTPS in tutto il sito. (Non utilizzare HTTP per qualcosa.)

2. Devono impostare il flag di sicurezza su tutti i cookie.

Devono fare entrambe le cose: solo uno non è sufficiente.