Session hijacking - steal
Command injection flaws
Esattamente come sopra, questa volta però la visualizzazione dei file di sessione su server è demandata ai comandi shell (ove si riesca nell'intento ovviamente). Salvando le sessioni su db si evita questo tipo di attacco, a meno di non riuscire a "scovare" le password di accesso allo stesso. Cosa che per la verità richiede solo pazienza, dacché gli script PHP generalmente sono in chiaro e quindi è possibile leggervi le password di connessione.
Già che abbiamo affrontato l'argomento: è bene usare tool appositi di terze parti che criptano e semicompilano il codice sorgente dei nostri script PHP, per lo meno in caso di applicazioni che vadano al di là del semplice sito Web.
Furto del SID
Per utenti facenti parte di una stessa organizzazione od a stretto contatto, se il SID viene propagato via query string è possibile che venga visto da qualcuno - cui per la verità dovrei fare i complimenti per rapidità di sguardo e memoria - e replicato altrove, sempre in query string, prima dello scadere della sessione.
Sniffer
Se il SID viene propagato via query string o cookies, si è in rete locale e si usa una connessione non cifrata, è sufficiente uno sniffer di rete al fine di rubare SID (e ben altro): i packet sniffer sono programmi che intercettano il traffico di rete, dipendentemente dalla topologia della rete stessa, mostrando tutto ciò che attraverso tale rete le parti si scambiano, compresi login, password, e-mail private, e via discorrendo.
Va da sé che l'unico rimedio possibile per evitare lo sniffing è usare un sistema di tunneling SSL per proteggere i dati in transito. Nell'immagine seguente è mostrato come ricavare, via sniffer, nome utente e password di un utente terzo che in rete locale è in procinto di verificare se gli sono arrivati messaggi di posta, via webmail.
Su questa guida non viene spiegato né cos'è, nel dettaglio, nè come utilizzare il sistema di tunneling cifrato SSL, Secure Socket Layer: a tal fine si rimanda ad altre guide e fonti Internet.