Diciamo che Alice sta usando l'applicazione web di Bob (in esecuzione sul server di Bob). HTTP non ha un concetto di sessione, quindi ogni pagina caricata da Alice esiste in isolamento. Il cookie di sessione è qualcosa che Bob rimanda al browser di Alice quando accede, in modo da poter tenere traccia di tutte le richieste provenienti da Alice.
Pertanto, il cookie di sessione ha annunciato a Bob "questa richiesta proviene da Alice". Bob si fida implicitamente di ciò. Quando vede il cookie, sa che sta parlando con Alice.
Dove va questo? Quando qualcun altro di Alice può vedere il cookie.
Supponi che Alice si trovi su una rete wifi non criptata. Mallory è seduto sulla stessa rete e vede il traffico tra Alice e Bob. Supponiamo che il traffico non sia crittografato (HTTP anziché HTTPS). Ora Mallory vede il cookie HTTP che Alice invia a Bob. Mallory può usare il proprio know-how tecnico per inviare una richiesta a Bob con il cookie di Alice incorporato in esso, e Bob risponderà a Mallory pensando di rispondere ad Alice. Questo è ciò che gli strumenti come Firesheep automatizzano, ma in realtà chiunque può fare questo tipo di attacco su qualsiasi sito a cui si accede tramite HTTP su una rete aperta.
Ora, tornando alla tua domanda, questo spiega le pratiche comuni con i cookie di sessione:
- Non inserire mai l'ID di sessione nell'URL. Altrimenti Alice potrebbe inviare un link a Mallory tramite IM o qualche altro canale che include il suo ID di sessione. Mallory ha il suo id di sessione, quindi può fingere di essere lei.
- Utilizza sempre HTTPS per impedire l'intercettazione tramite Wifi. Se il traffico di rete può essere intercettato e il cookie può essere ascoltato, Mallory può usarlo per fingere di essere Alice.
Se un'applicazione viene utilizzata su HTTP, la sessione può essere intercettata da qualcuno che ascolta il traffico di rete e l'applicazione è aperta per l'attacco. Quanto è probabile questo dipende dal fatto che qualcuno decida di indirizzare l'app e possa trovare reti non protette in cui viene utilizzata l'app. Pertanto, per le app web impopolari il rischio è basso, ma per le app Web più diffuse il rischio è molto alto. Questo è il motivo per cui Facebook è stato spostato su HTTPS per impostazione predefinita e perché Yahoo Mail ora ha l'opzione per attivarlo.
Non c'è alcun rischio in F12, perché Alice non conosce alcun danno conoscendo il proprio cookie. C'è solo un rischio se Mallory può vedere il suo schermo e copiare i cookie per i suoi usi privati.