Spacciarsi per qualcun altro: session fixation

Perché faticare a rubare dati di sessione quando questa sessione può crearla lo stesso cracker e poi farla usare all'utente?  In un attacco di tipo session fixation il cracker "fissa" un SID che farà poi usare all'utente attaccato. Vediamo come.

I passi per un attacco di tale tipo sono essenzialmente riportati di seguito.

• Il cracker si autentica sul sito hackerato (Sito_A) ed ottiene un SID valido. Il cracker stesso deve ovviamente avere un login valido sul Sito_A.

• Il cracker deve a questo punto far utilizzare all'utente attaccato (utente_A) tale SID, di modo che questi si autentichi a Sito_A, inserendo nome utente e password, ma usando nel contempo la sessione già iniziata dal cracker anziché crearne una nuova. Si presentano più strade per ottenere questo risultato.

Il cracker passa all'utente_A un link col SID in query string:

facendo in modo che l'utente (poco esperto) segua il link e si autentichi (inserendo i suoi corretti username e password). PHP (dipendentemente da com'è scritto il codice del programma e dalle direttive fornitegli) non creerà alcuna nuova sessione, ma continuerà ad usare quella puntata da PHPSESSID, che appunto è quella "fissata" dal cracker.

Il cracker fa sfruttare all'utente una falla XSS, come visto per il session hijacking, con la differenza che questa volta il comando JavaScript da eseguire sarà document.cookie, il quale imposterà un cookie di sessione (proveniente appunto dal dominio sotto attacco) sulla macchina di utente_A. Segue quanto detto per il passo 1.

Nei passi 1 e 2 il cracker deve mantenere "in vita" la sessione, onde evitare che scada prima che utente_A la utilizzi (generalmente si ha un limite di durata per il tempo di vita delle sessioni, che non deve essere né troppo lungo né troppo breve, per non premiare i cracker da un lato ma non penalizzare troppo gli utenti dall'altro. La direttiva PHP che definisce questo lifetime è impostata nel php.ini).

• Se l'utente appena autenticato ha un più alto profilo di privilegi rispetto al cracker, la sessione eredita questi privilegi (cioè i dati salvati nella sessione verranno modificati con questi ultimi, più "preziosi") e il cracker è divenuto - possibilmente - amministratore di sistema.

Conclusione: "tagliamo la testa al toro"

Modificare spesso l'indentificatore della sessione per eviarne i furti

session_regenerate_id()

Al di là delle necessarie protezioni - che si evincono direttamente dalle descrizioni degli exploit possibili (attenzione dell'utente, programmazione, sistema e rete sicuri) - il "furto di identità" è realmente pericoloso quando l'utente attaccato abbia privilegi elevati o meglio quando stia operando in area amministrativa. In questi casi è opportuno modificare spesso l'ID di sessione tramite il comando standard PHP session_regenerate_id().

Sicuramente è necessario farlo ancora prima che avvenga il login - poniamo nella stessa pagina di autenticazione, prima di inviare i dati del form Web al server - e prima di una qualsivoglia ipotetica nuova richiesta di login, ad esempio per passare da utente ad amministratore di sistema o comunque innalzare i propri privilegi.