La session fixation è un attacco alle sessioni web in cui l’attaccante non ruba una sessione esistente — la fissa prima che l’autenticazione avvenga. Il meccanismo sfrutta applicazioni che non rigenerano l’ID di sessione al momento del login: l’attaccante conosce l’ID di sessione prima del login, la vittima si autentica con quell’ID, e l’attaccante eredita la sessione autenticata.
Meccanismo
- L’attaccante ottiene un ID di sessione valido dall’applicazione (es. visitandola normalmente) — es.
SESSID=abc123. - Induce la vittima ad usare quell’ID di sessione. Tecniche comuni:
- Link con sessione nell’URL:
https://app.it/login?SESSID=abc123(se l’applicazione accetta il session ID come parametro GET). - Header Set-Cookie via XSS o subdomain: se l’attaccante controlla un sottodominio, può impostare un cookie di sessione per il dominio padre.
- Meta-refresh o redirect verso la pagina di login con sessione pre-impostata.
- Link con sessione nell’URL:
- La vittima visita il link e si autentica. L’applicazione associa le credenziali della vittima alla sessione
abc123— senza rigenerarla. - L’attaccante, che conosce
abc123, può ora accedere all’applicazione con la sessione autenticata della vittima.
Differenza con Session Hijacking
| Session Fixation | Session Hijacking | |
|---|---|---|
| Timing | Prima del login | Dopo il login |
| Come si ottiene la sessione | L’attaccante la impone | L’attaccante la ruba (sniffing, XSS, ecc.) |
| Conoscenza dell’ID | Già nota all’attaccante | Da acquisire |
Nella session fixation l’attaccante non ha bisogno di intercettare nulla — conosce già l’ID perché lo ha generato lui.
Varianti
Fixation tramite URL: le applicazioni legacy che passano il session ID nell’URL (?jsessionid=...) sono particolarmente vulnerabili: è sufficiente costruire un link con un ID noto.
Fixation tramite cookie da sottodominio: se l’applicazione usa Domain=.esempio.it per il cookie di sessione, un attaccante con controllo su blog.esempio.it può impostare un cookie SESSID per .esempio.it — che verrà inviato a www.esempio.it al login.
Fixation tramite risposta HTTP manipolata: in scenari con proxy intermedi vulnerabili, l’attaccante può iniettare header Set-Cookie in risposte HTTP non cifrate.
Contromisure
Rigenerazione dell’ID di sessione al login: è la difesa fondamentale. Immediatamente dopo l’autenticazione riuscita, il server deve emettere un nuovo ID di sessione e invalidare quello precedente:
# Django — rigenerazione automatica al login
from django.contrib.auth import login
login(request, user)
# Django rigenera automaticamente la sessione al login
# Flask — rigenerazione manuale
session.clear()
session['user_id'] = user.id
# L'ID di sessione viene rigenerato perché la sessione è stata svuotataNon accettare session ID dall’URL: i session ID devono transitare esclusivamente via cookie — mai come parametri GET o POST. Molti framework moderni non supportano più i session ID nell’URL per default.
Cookie con attributi di sicurezza: HttpOnly (impedisce lettura via JavaScript), Secure (solo HTTPS), SameSite=Strict o Lax (protegge da invio cross-site).
Timeout di sessione brevi: riduce la finestra utile per l’attaccante anche in caso di fixation riuscita.
Validazione dell’IP o User-Agent: legare la sessione all’IP o allo User-Agent del client originale — misura imperfetta (gli IP cambiano in reti mobili, i proxy aziendali aggregano IP) ma aumenta il costo dell’attacco.
Contesto storico
La session fixation fu documentata formalmente da Mitja Kolsek nel 2002 nel paper Session Fixation Vulnerability in Web-based Applications. Portò i framework web a introdurre la rigenerazione automatica del session ID al login come comportamento di default — funzionalità oggi presente in Rails, Django, Laravel, ASP.NET e la maggior parte dei framework maturi.
Relazione con altri argomenti
- Autenticazione — la session fixation colpisce il momento critico del passaggio da non-autenticato ad autenticato.
- Cross-Site Scripting (XSS) — XSS può essere usato per impostare cookie di sessione arbitrari, facilitando la fixation.
- OWASP Top 10 — A07 Identification and Authentication Failures.
- HSTS — protegge dal downgrade a HTTP, eliminando un vettore di manipolazione dei cookie.