Cos'è la Session Fixation? Come gli attaccanti dirottano le sessioni utente

La session fixation consente agli attaccanti di dirottare account autenticati forzando un ID di sessione noto prima dell'accesso. La difesa principale: rigenerare gli ID di sessione a ogni accesso.

Che cos'è la Session Fixation?

La session fixation è una vulnerabilità delle applicazioni web che consente a un attaccante di dirottare una sessione utente valida sfruttando una gestione inadeguata degli identificatori di sessione. Il difetto principale è semplice: quando un utente si autentica, l'applicazione non assegna un nuovo ID di sessione. Questo significa che un attaccante che conosce o controlla l'identificatore di sessione pre-autenticazione può utilizzarlo per accedere alla sessione autenticata come se fosse l'utente legittimo.

MITRE CWE definisce formalmente la debolezza: "Autenticare un utente, o altrimenti stabilire una nuova sessione utente, senza invalidare alcun identificatore di sessione esistente offre a un attaccante l'opportunità di rubare sessioni autenticate." Per l'utente, il risultato è una quasi completa compromissione dell'account, spesso senza che la vittima si accorga di nulla.

La session fixation è distinta dal session hijacking, anche se spesso vengono confuse. OWASP traccia una linea netta: la session fixation inizia prima che la vittima effettui il login, mentre il session hijacking avviene dopo che esiste già una sessione autenticata attiva. In un attacco di fixation, l'attaccante conosce già l'ID di sessione perché lo ha impostato. In un attacco di hijacking, l'attaccante deve catturare o prevedere l'ID di sessione da una sessione attiva.

Attributo	Session Fixation	Session Hijacking
Tempistica dell'attacco	Prima che la vittima si autentichi	Dopo che la vittima si è autenticata
Conoscenza dell'ID di sessione	L'attaccante imposta o conosce l'ID in anticipo	L'attaccante deve catturare o prevedere l'ID
Contromisura principale	Rigenerazione dell'ID di sessione al login	Crittografia del token, trasmissione sicura

Questa distinzione è importante per i controlli di sicurezza. Se l'applicazione rigenera gli ID di sessione dopo il login, si prevengono gli attacchi di fixation. Se si limita solo a cifrare i token di sessione in transito, si affronta il hijacking ma si lascia la fixation completamente aperta. Comprendere il funzionamento tecnico dell'attacco spiega perché questa differenza è così critica.

Come funziona la Session Fixation?

La session fixation segue un flusso di attacco in quattro fasi, documentato sia da MITRE CWE che da OWASP WSTG.

• Fase 1: Acquisizione della sessione. L'attaccante visita l'applicazione target e riceve un ID di sessione valido pre-autenticazione. Ad esempio, il server potrebbe restituire JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1. In applicazioni che utilizzano un meccanismo permissivo di accettazione della sessione, l'attaccante può fornire un valore arbitrario di ID di sessione che l'applicazione accetterà senza verifiche.
• Fase 2: Consegna della sessione. L'attaccante consegna l'ID di sessione noto alla vittima. Questa consegna può avvenire tramite un URL appositamente creato, un payload di cross-site scripting, un tag META iniettato o HTTP response splitting. L'obiettivo è semplice: fare in modo che il browser della vittima invii l'ID di sessione controllato dall'attaccante quando accede all'applicazione target.
• Fase 3: Autenticazione della vittima. La vittima clicca sul link creato o accede all'applicazione tramite il meccanismo di consegna dell'attaccante ed effettua il login normalmente. L'applicazione valida le credenziali e concede l'accesso. Ma non rigenera l'ID di sessione dopo il login, continuando a operare con lo stesso identificatore già noto all'attaccante.
• Fase 4: Compromissione dell'account. L'attaccante invia richieste all'applicazione utilizzando l'ID di sessione noto. Il server tratta queste richieste come provenienti dalla vittima autenticata. MITRE osserva che ciò fornisce "accesso quasi illimitato all'account della vittima per tutta la durata della sessione."

Oltre alle quattro fasi principali, la session fixation può essere veicolata tramite diversi metodi distinti a seconda dell'accesso dell'attaccante e della configurazione dell'applicazione target.

Cinque principali vettori di attacco

1. Iniezione di parametri URL è il vettore più semplice. L'attaccante inserisce l'ID di sessione come parametro di query nell'URL e consegna il link tramite phishing o email: https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner classifica "Session token in URL" come CWE-384.
2. Iniezione di cookie tramite XSS utilizza JavaScript che viene eseguito nel browser della vittima per impostare il cookie di sessione: document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE conferma che il cross-site scripting è una delle due classi di tecniche più comuni per veicolare payload di session fixation.
3. Iniezione di tag META inserisce un tag HTML che istruisce il browser a impostare un cookie: <meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP osserva che questo approccio è più difficile da contrastare rispetto all'iniezione JavaScript perché "è impossibile disabilitare l'elaborazione di questi tag nei browser."
4. Iniezione di header di risposta HTTP sfrutta vulnerabilità di response splitting per iniettare un header Set-Cookie direttamente nella risposta del server, impostando l'ID di sessione controllato senza alcuno scripting lato client.
5. Session fixation cross-subdomain sfrutta architetture a dominio condiviso. MITRE documenta direttamente questo caso: se bank.example.com e recipes.example.com condividono lo stesso dominio di primo livello, una vulnerabilità nell'applicazione recipes può fissare un ID di sessione che verrà utilizzato su tutte le applicazioni di example.com. L'ampiezza dei vettori di consegna spiega perché la session fixation è ancora presente nei sistemi in produzione.

Cause della Session Fixation

Le cause principali della session fixation sono ben documentate, e ognuna rappresenta una lacuna che tu e il tuo team di sviluppo potete colmare.

Mancata rigenerazione degli ID di sessione dopo l'autenticazione

Questa è la causa principale, citata da tutte le fonti autorevoli nell'articolo. La guida OWASP lo afferma direttamente: "Quando un'applicazione non rinnova il/i cookie di sessione dopo una autenticazione utente riuscita, potrebbe essere possibile riscontrare una vulnerabilità di session fixation."

La scheda OWASP specifica che la rigenerazione dell'ID di sessione è obbligatoria al login, al cambio password, ai cambi di permessi e alle transizioni di ruolo. Il record CVE-2022-24895 documenta che la strategia di migrazione NONE di Symfony mantiene la stessa sessione dopo l'autenticazione, abilitando attacchi di fixation, e ha una valutazione di gravità ALTA.

Accettazione permissiva degli ID di sessione

L'OWASP Session Management Cheat Sheet definisce due meccanismi per la gestione degli ID di sessione. Un meccanismo permissivo accetta qualsiasi valore di ID di sessione impostato dall'utente come valido e crea una nuova sessione per esso. Un meccanismo restrittivo accetta solo ID di sessione precedentemente generati dall'applicazione. Se l'applicazione utilizza il meccanismo permissivo, consente agli attaccanti di inserire valori arbitrari senza prima ottenere un ID emesso dal server.

Identificatori di sessione prevedibili

MITRE identifica gli identificatori di sessione prevedibili come condizione favorente, correlata a CWE-340 (Generazione di numeri o identificatori prevedibili). Quando gli ID di sessione seguono schemi o utilizzano una randomizzazione debole, gli attaccanti possono prevedere valori validi senza doverne acquisire uno dal server.

Ambito di dominio cookie permissivo

Impostare l'attributo cookie Domain su un dominio di primo livello, ad esempio Domain=example.com invece di Domain=app.example.com, fa sì che i cookie vengano trasmessi su tutti i sottodomini. Una vulnerabilità in un solo sottodominio diventa un punto di ingresso per la fixation su tutte le applicazioni di quel dominio.

Transizione da HTTP a HTTPS senza rigenerazione della sessione

OWASP WSTG-SESS-03 identifica questo scenario specifico: siti che emettono un identificatore di sessione su HTTP e poi reindirizzano a un form di login HTTPS, senza riemettere l'ID di sessione dopo l'autenticazione, espongono l'ID pre-autenticazione a intercettazioni a livello di rete. L'attaccante cattura l'ID sulla connessione insicura e attende che la vittima si autentichi. Queste cause raramente si presentano isolate, e comprendere come la comunità degli standard le classifica formalmente aiuta a comunicare e a dare priorità alla remediation.

Classificazione OWASP della Session Fixation

La session fixation è formalmente classificata in tre sistemi di standard autorevoli: MITRE Common Weakness Enumeration, OWASP Top 10 e OWASP Web Security Testing Guide. In OWASP A07, rientra nella categoria dei fallimenti di autenticazione insieme a debolezze correlate che condividono lo stesso ambito di remediation. Ogni classificazione serve un pubblico diverso e segnala una diversa azione.

CWE-384: Identificatore formale della debolezza

MITRE CWE-384 è la classificazione principale per la session fixation, definendo la debolezza come l'autenticazione di un utente senza invalidare l'identificatore di sessione esistente. Il suo profilo nella tassonomia MITRE:

• Tipo di debolezza: Debolezza di base nella categoria delle credenziali di sessione
• Conseguenze comuni: Ottenere privilegi o assumere l'identità della vittima; compromissione completa dell'account per la durata della sessione
• Probabilità di exploit: Media — richiede la consegna di un ID di sessione noto alla vittima prima del login
• Ambito della piattaforma: Indipendente dal linguaggio; si applica a prescindere dallo stack web o dal framework
• Status CWE Top 25: Entrato nella Top 25 nel 2019; rimane una debolezza attivamente monitorata nell'edizione 2023

Queste proprietà rendono CWE-384 un segnale coerente tra scanner di vulnerabilità e framework di assessment, dove si mappa direttamente a casi di test che mirano alla gestione del ciclo di vita della sessione.

OWASP Top 10 e standard di test

CWE-384 si mappa a A07:2025 — Authentication Failures nell'OWASP Top 10. Questa classificazione ha un'importante implicazione: la session fixation è trattata come un fallimento del controllo di autenticazione, non come una errata configurazione dei cookie. Questa distinzione la colloca direttamente nelle revisioni dei flussi di login e nel rafforzamento dell'autenticazione, non solo negli audit di configurazione dei cookie.

Riferimento	Sistema	Scopo
CWE-384	MITRE CWE	Tracciamento formale delle debolezze; utilizzato da strumenti SAST/DAST e record CVE
A07:2025	OWASP Top 10	Segnale di prioritizzazione del rischio; delimita la revisione ai controlli di autenticazione
WSTG-SESS-03	OWASP WSTG	Procedura di test black-box autorevole e criteri di superamento/fallimento
Session Management Cheat Sheet	OWASP CheatSheets	Riferimento per sviluppatori per prevenzione su rigenerazione, ambito cookie e modalità restrittiva

Insieme, questi quattro riferimenti forniscono il vocabolario, i casi di test e le linee guida di remediation per affrontare la session fixation in qualsiasi programma di sicurezza esistente. Con il contesto di classificazione stabilito, vale la pena esaminare cosa accade realmente quando la vulnerabilità viene sfruttata con successo.

Impatto e rischio della Session Fixation

La session fixation consente la completa compromissione dell'account per tutta la durata della sessione compromessa. Una volta che un attaccante possiede un ID di sessione autenticato, opera con tutti i privilegi della vittima: lettura di dati sensibili, avvio di transazioni, modifica delle impostazioni dell'account ed escalation dei privilegi se la vittima ha diritti amministrativi.

Classificazione e gravità OWASP

CWE-384 rientra in OWASP A07. La categoria A07:2025 ha un punteggio medio ponderato di sfruttabilità di 7,69, mappato a 7.147 CVE totali tra le applicazioni testate. Il totale dei CVE mappati alla categoria A07 è aumentato tra le edizioni 2021 e 2025, riflettendo un'espansione e non una contrazione della superficie di attacco.

Intervallo di punteggio CVSS

I CVE confermati di session fixation spaziano da Media a Critica. I casi con punteggio più alto coinvolgono tipicamente scenari in cui la fixation consente la compromissione dell'account senza autenticazione in plugin o framework di autenticazione ampiamente diffusi. Un'importante sfumatura per chi opera nel settore: i CVE di session fixation mostrano frequentemente discrepanze di punteggio tra NIST NVD e vendor CNA. Ad esempio, CVE-2019-17563 (Apache Tomcat) ha ricevuto una valutazione CRITICA da NIST ma una valutazione "Low" da Apache, che ha descritto la finestra di exploit come "troppo stretta perché l'exploit sia praticabile."

Fattori di rischio composti

La session fixation raramente rappresenta un rischio isolato. CVE-2024-56529 (Mailcow) mostra che l'attacco ha successo specificamente quando HSTS è disabilitato sul browser della vittima. Un paper Microsoft Research presentato a IEEE S&P 2015 ha documentato che l'iniezione di cookie può bypassare le difese standard di rigenerazione della sessione su siti reali. Quando i controlli di defense-in-depth falliscono contemporaneamente, una vulnerabilità di session fixation può rapidamente aggravarsi. La questione di chi è vulnerabile va oltre le sole applicazioni web.

Come gli attaccanti sfruttano la Session Fixation

Gli attaccanti sfruttano la session fixation in scenari che vanno dal phishing mirato all'avvelenamento opportunistico della sessione.

Iniezione URL tramite phishing

L'attaccante crea un URL contenente un ID di sessione noto e lo consegna tramite phishing o social engineering. L'URL appare legittimo perché punta al dominio reale dell'applicazione. La vittima clicca sul link, effettua il login normalmente e, inconsapevolmente, autentica una sessione controllata dall'attaccante. Questo è lo scenario più comune per la trasmissione dell'ID di sessione tramite URL.

Sfruttamento di terminali pubblici

MITRE CWE-384 documenta uno scenario canonico: un attaccante crea una sessione da un terminale pubblico, registra l'identificatore di sessione, reimposta il browser sulla pagina di login e attende che il prossimo utente si autentichi. L'applicazione continua a utilizzare l'ID di sessione preesistente, dando all'attaccante "accesso quasi illimitato all'account della vittima per tutta la durata della sessione."

Avvelenamento di sessione non mirato

CVE-2022-30769 (ZoneMinder) ha dimostrato un attacco in cui un attaccante poteva "avvelenare un cookie di sessione per il prossimo utente che effettua il login." Non era necessario prendere di mira un individuo specifico. La sessione avvelenata veniva ereditata da chiunque si autenticava successivamente. In ambienti ad accesso condiviso come le piattaforme di videosorveglianza, questo schema è particolarmente pericoloso.

Sfruttamento di race condition

CVE-2013-2067 (Apache Tomcat) ha rivelato una race condition nell'autenticazione FORM. Inviando ripetutamente richieste per risorse autenticate mentre la vittima completava il form di login, un attaccante poteva iniettare una richiesta eseguita con le credenziali della vittima. Apache ha valutato questa vulnerabilità come di gravità "Important".

Attacchi cross-subdomain

In architetture multi-applicazione che condividono un dominio di primo livello, gli attaccanti sfruttano un'applicazione a bassa sicurezza per fissare un cookie di sessione con ambito al dominio principale. Tutte le altre applicazioni su quel dominio accettano quindi l'ID di sessione fissato. Questo scenario è comune negli ambienti enterprise che eseguono più strumenti interni su un dominio condiviso. Sapere chi è interessato aiuta a dare priorità alle verifiche di queste vulnerabilità.

Chi è interessato dalla Session Fixation?

La session fixation interessa qualsiasi applicazione che gestisce sessioni utente tramite identificatori e non li rigenera dopo l'autenticazione. I record CVE e la documentazione MITRE indicano diverse categorie strutturalmente ad alto rischio.

• Applicazioni web che utilizzano identificatori di sessione basati su URL sono le più esposte. La trasmissione della sessione tramite URL consente agli attaccanti di fornire un ID di sessione controllato tramite un link appositamente creato senza necessità di ulteriori vulnerabilità.
• Ecosistemi CMS e plugin di autenticazione sono ripetutamente colpiti. CVE-2024-13279 (Drupal TFA, secondo CISA), CVE-2010-1434 (Joomla!), CVE-2012-5391 (MediaWiki) e CVE-2019-8116 (Magento) dimostrano che i moduli di autenticazione integrati nei CMS introducono rischi critici di session fixation quando la rigenerazione della sessione non è applicata.
• Applicazioni J2EE/Java EE hanno una delle serie di CVE più estese documentate. Apache Tomcat da solo conta CVE dal 2013 al 2025, inclusi CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563 e CVE-2025-55668.
• Architetture multi-applicazione a dominio condiviso sono vulnerabili per design. Le piattaforme SaaS con sottodomini tenant e i portafogli applicativi enterprise che condividono un dominio di primo livello sono esposti al rischio di fixation cross-subdomain, come documentato da MITRE.
• Piattaforme ICS/SCADA rappresentano una superficie di rischio emergente. CVE-2025-70973 (ScadaBR 1.12.4, divulgato marzo 2026) mostra la session fixation in piattaforme di controllo industriale, coerente con i mapping ICS di CWE-384 verso CWE-1364 (ICS Communications: Zone Boundary Failures) e CWE-1366 (ICS Communications: Frail Security in Protocols).
• Piattaforme di workflow enterprise presentano anch'esse esposizione documentata. CVE-2022-38369 (Apache IoTDB) e CVE-2022-38054 (Apache Airflow) dimostrano che anche gli strumenti di automazione dei workflow non sono immuni. L'ampiezza delle categorie colpite rende utili i casi di studio reali per comprendere come queste vulnerabilità si manifestano nella pratica.

Esempi reali di Session Fixation

La session fixation è stata confermata su un'ampia gamma di sistemi in produzione, dai framework Java enterprise alle piattaforme di controllo industriale. Gli esempi seguenti illustrano come lo stesso difetto di base si manifesti in modo diverso a seconda dell'ambiente.

Race condition nell'autenticazione FORM di Apache Tomcat (CVE-2013-2067)

Questo rimane il CVE di session fixation più impattante per Tomcat, valutato "Important" da Apache. Ha interessato Tomcat 6.0.21 fino a 6.0.36 e 7.0.0 fino a 7.0.32, sfruttando una race condition nell'autenticazione FORM. Un attaccante poteva inviare ripetutamente richieste per risorse autenticate mentre la vittima completava il form di login, iniettando una richiesta eseguita con le credenziali della vittima. L'ironia è che l'opzione per cambiare l'ID di sessione all'autenticazione era stata introdotta proprio in Tomcat 6.0.21. Questo CVE rappresentava un bug nella stessa protezione dalla fixation di Tomcat.

Bypass del token CSRF nel framework Symfony (CVE-2022-24895)

Le versioni di Symfony dalla 2.0.0 alla 6.2.5 sono state colpite da una vulnerabilità di gravità ALTA. Il framework rigenerava l'ID di sessione al login ma manteneva gli altri attributi di sessione, inclusi i token CSRF. Questa rigenerazione parziale consentiva ad attaccanti same-site di bypassare la protezione CSRF tramite una variante di session fixation. La lezione è chiara: rigenerare solo l'ID di sessione non basta. È necessaria l'invalidazione e la riemissione completa della sessione.

Sistema di controllo industriale ScadaBR (CVE-2025-70973)

Divulgata a marzo 2026, questa vulnerabilità in ScadaBR 1.12.4 segue il pattern canonico della session fixation. L'applicazione assegna un cookie di sessione JSESSIONID agli utenti non autenticati e non rigenera l'identificatore di sessione dopo l'autenticazione. Una sessione creata prima del login diventa autenticata una volta che la vittima effettua il login. Questo CVE è rilevante perché mostra un rischio attivo di session fixation in ambienti ICS/SCADA.

Avvelenamento di sessione non mirato in ZoneMinder (CVE-2022-30769)

ZoneMinder 1.36.12 e versioni precedenti consentivano a un attaccante di avvelenare un cookie di sessione che sarebbe stato ereditato dal prossimo utente che si autenticava. Non era necessario prendere di mira una vittima specifica, rendendo la vulnerabilità particolarmente pericolosa in ambienti di videosorveglianza ad accesso condiviso dove più operatori utilizzano la stessa piattaforma.

Adoption di sessione PHP (CVE-2011-4718)

Il modulo di sessione di PHP era "adottivo", cioè accettava ID di sessione da fonti esterne. La RFC PHP affermava che "l'uso di session_regenerate_id() NON PUÒ prevenire l'adoption/fixation della sessione" senza abilitare anche session.use_strict_mode. PHP 5.5.2 ha introdotto session.use_strict_mode come correzione, ma anche con la modalità restrittiva abilitata, i gestori di salvataggio personalizzati potevano rimanere vulnerabili. Il record storico completo di questi incidenti mostra quanto a lungo questa classe di vulnerabilità sia persistita.

Timeline e storia della Session Fixation

La session fixation è documentata formalmente dal 2002, e i record CVE mostrano che rimane attiva sia su codebase nuove che legacy. La timeline seguente traccia gli eventi chiave di disclosure e le risposte a livello di framework.

Anno	Evento
Dic 2002	Mitja Kolšek (ACROS Security) pubblica "Session Fixation Vulnerability in Web-based Applications", nominando formalmente la session fixation come quarta classe di attacco contro gli identificatori di sessione
2006	CVE-2006-1228 (Drupal 4.5.x/4.6.x): fixation dell'ID di sessione via URL
Lug 2006	MITRE aggiunge CWE-384 alla Common Weakness Enumeration (Draft 3)
Feb 2008	Advisory Oracle/BEA WebLogic Server BEA08-196.00: session fixation che abilita l'escalation dei privilegi
2009	CVE-2009-1580 (SquirrelMail); Black Hat USA documenta CWE-384 nelle community di tracker BitTorrent
2010	CVE-2010-1434 (Joomla! 1.5.0 fino a 1.5.15): CVSS 7.5 ALTO
Dic 2011	CVE-2011-4718 (adoption di sessione PHP): interessa PHP 5.0.0 fino a 5.5.1
Mag 2013	CVE-2013-2067 (Apache Tomcat 6.x, 7.x): race condition FORM auth, gravità "Important" per Apache
2015	Microsoft Research (IEEE S&P) documenta l'iniezione di cookie che bypassa le difese di rigenerazione della sessione ampiamente adottate
2019	CWE-384 entra nella Top 25
Dic 2019	CVE-2019-17563 (Apache Tomcat): NIST 9.8 CRITICO vs. Apache "Low"
2022	CVE-2022-24895 (Symfony): bypass tramite rigenerazione parziale
Gen 2025	CVE-2024-56529 (Mailcow): session fixation quando HSTS è disabilitato
Ago 2025	CVE-2025-55668 (Apache Tomcat 9.x/10.x/11.x): CVSS 6.5 MODERATO
Mar 2026	CVE-2025-70973 (ScadaBR 1.12.4) e CVE-2026-25101 (Bludit): nuovi CVE confermano che la classe di vulnerabilità è ancora attiva

La timeline copre oltre due decenni senza segni di rallentamento. La session fixation non è una vulnerabilità storica. Continua ad apparire sia su codebase nuove che legacy, dai framework enterprise alle piattaforme ICS. Se sai come revisionare le tue applicazioni, puoi passare allo step successivo.

Come rilevare la Session Fixation

La session fixation è una delle vulnerabilità più semplici da confermare: il test principale richiede solo di catturare un identificatore di sessione prima del login, autenticarsi e confrontare il valore dopo. Gli approcci seguenti coprono verifica manuale, ispezione degli attributi dei cookie, scansione automatizzata e identificazione a livello WAF.

Penetration test manuale (OWASP WSTG-SESS-03)

La procedura di test autorevole proviene dalla OWASP WSTG. Per l'utente, il test black-box è diretto.

1. Cattura l'ID di sessione pre-autenticazione. Visita l'applicazione e registra il valore del cookie di sessione (es. JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1).
2. Autenticati presentando l'ID di sessione catturato. Invia credenziali valide con il cookie di sessione originale allegato.
3. Confronta i valori dell'ID di sessione. Se il server restituisce lo stesso ID di sessione dopo l'autenticazione, l'applicazione è vulnerabile.

Per applicazioni senza piena adozione di HSTS, WSTG-SESS-03 descrive una seconda strategia: forza tutti i cookie non appena emessi dopo il login nel browser della vittima da una macchina separata, quindi verifica se quei cookie consentono l'accesso alla sessione della vittima dopo l'autenticazione.

Verifica degli attributi dei cookie

Verifica la presenza di indicatori di hardening nei cookie di sessione. Il prefisso __Host- fornisce integrità contro la session fixation a livello di rete. Il prefisso __Secure- indica un hardening parziale. Esegui WSTG-SESS-03 per verificare che gli attributi HttpOnly, Secure e SameSite siano configurati correttamente.

Scansione DAST

OWASP ZAP offre modalità di scansione attiva e passiva con supporto alla gestione delle sessioni, inclusa la gestione di cookie, token e altri meccanismi. L'analisi di ZAP sulla gestione della sessione e l'applicazione dell'autenticazione aiuta a individuare autenticazione compromessa e bug di session fixation. Burp Suite Professional copre i workflow di test della gestione della sessione, funzionando come scanner dinamico di vulnerabilità web applicabile ai test di gestione della sessione.

Identificazione a livello WAF

La scheda OWASP identifica ModSecurity combinato con l'OWASP Core Rule Set come contromisura contro gli attacchi di session fixation. Questo approccio a livello WAF è raccomandato quando il codice sorgente non è disponibile, non può essere modificato o quando l'implementazione di correzioni a livello applicativo richiederebbe una riprogettazione estesa. Una revisione efficace dovrebbe portare direttamente alla prevenzione, e i controlli necessari sono ben definiti.

Come prevenire la Session Fixation

La prevenzione si basa su un requisito non negoziabile: l'applicazione deve emettere un nuovo ID di sessione a ogni evento di autenticazione e rifiutare qualsiasi identificatore di sessione non generato dal server stesso. I controlli seguenti rispondono a questo requisito a livello applicativo, di framework, di configurazione dei cookie e di architettura di rete.

Controlli a livello applicativo

• Rigenera gli ID di sessione dopo l'autenticazione. Questo è il controllo più importante. OWASP WSTG-SESS-03 afferma chiaramente il requisito: "l'applicazione dovrebbe sempre prima invalidare l'ID di sessione esistente prima di autenticare un utente e, se l'autenticazione ha successo, fornire un altro ID di sessione." La rigenerazione è obbligatoria a ogni cambio di livello di privilegio, incluso login, cambio password, cambi di permesso e transizioni di ruolo.
• Utilizza una gestione restrittiva della sessione. Configura l'applicazione per accettare solo ID di sessione generati dal server. Rifiuta valori arbitrari di ID di sessione inviati dai client. PHP ha introdotto session.use_strict_mode nella versione 5.5.2 proprio per questo scopo.
• Invalidare completamente le sessioni. CVE-2022-24895 (Symfony) ha dimostrato che la rigenerazione parziale della sessione non è sufficiente. Rigenerare l'ID di sessione mantenendo altri attributi di sessione come i token CSRF crea una vulnerabilità residua. È necessaria l'invalidazione e la riemissione completa della sessione.

Implementazione specifica per framework

Framework	Invalidare la sessione esistente	Creare una nuova sessione
J2EE	HttpSession.invalidate()	request.getSession(true)
ASP.NET	Session.Abandon()	Response.Cookies.Add(new HttpCookie(...))
PHP	session_start()	session_regenerate_id(true)

Spring Security protegge automaticamente dalla session fixation creando una nuova sessione o cambiando l'ID di sessione quando un utente effettua il login. Sono disponibili quattro strategie configurabili: changeSessionId() (raccomandata), migrateSession(), newSession(), e none() (non raccomandata).

Configurazione della sicurezza dei cookie

Segui i requisiti di NIST SP 800-63B:

• Flag Secure: DEVE essere impostato (cookie trasmessi solo su HTTPS)
• Domain e Path: DEVONO essere limitati all'ambito minimo pratico
• Flag HttpOnly: DOVREBBE essere impostato (impedisce l'accesso da JavaScript)
• SameSite=Lax o Strict: DOVREBBE essere impostato (secondo NIST SP 800-63B v4 draft)
• Prefisso __Host con Path=/: DOVREBBE essere impostato (secondo NIST SP 800-63B v4 draft)

L'applicazione combinata di questi flag previene gli scenari di fixation più comuni a livello di rete e cross-site e aumenta significativamente la difficoltà per qualsiasi attaccante che tenti l'iniezione di cookie.

Controlli a livello di architettura

Non mescolare applicazioni con livelli di sicurezza diversi sullo stesso dominio. Implementa HSTS completo inclusi i sottodomini per contrastare la fixation a livello di rete. Distribuisci ModSecurity con l'OWASP Core Rule Set per la protezione a livello WAF quando le modifiche a livello applicativo non sono immediatamente possibili. Prevenzione e revisione funzionano meglio se supportate dagli strumenti giusti.

Strumenti per rilevamento e prevenzione

Identificare e bloccare la session fixation richiede strumenti su tre livelli: scanner dinamici che simulano condizioni di attacco reali, protezioni native dei framework che applicano impostazioni sicure a livello di codice e analisi comportamentale che rileva intrusioni basate su fixation che raggiungono la sessione autenticata. Gli strumenti seguenti coprono tutti e tre i livelli.

Strumenti DAST e di penetration testing

• OWASP ZAP è uno strumento gratuito e open-source di dynamic application security testing. Secondo la documentazione ufficiale, ZAP utilizza modalità di scansione attiva e passiva per individuare difetti nella gestione della sessione, inclusa la session fixation.
• Burp Suite Professional offre workflow di test della sessione e regole di scansione per identificare vulnerabilità nella gestione dei token di sessione. Le sue capacità di test manuale consentono di seguire la procedura WSTG-SESS-03 con piena visibilità delle richieste/risposte.
• ModSecurity con OWASP Core Rule Set fornisce contromisure a livello WAF contro la session fixation, inclusa l'identificazione e l'applicazione degli attributi di sicurezza dei cookie, il tracciamento delle sessioni sticky e il rinnovo dell'ID di sessione quando vengono osservati cambi di privilegio.

Funzionalità di sicurezza dei framework

La protezione integrata di Spring Security contro la session fixation, session.use_strict_mode e session_regenerate_id() di PHP, e Session.Abandon() di ASP.NET forniscono tutte prevenzione nativa per il linguaggio. È necessario verificare che queste funzionalità siano abilitate e configurate correttamente nei propri deployment invece di affidarsi alle impostazioni di default.

Vulnerabilità correlate

La session fixation non opera in isolamento. Diverse debolezze strettamente correlate condividono meccanismi di consegna, condizioni di exploit o fattori di rischio con CWE-384. Comprenderle come gruppo produce un ambito di remediation più solido rispetto a trattare la session fixation da sola.

• Cross-Site Scripting (CWE-79) funge da meccanismo di consegna per la session fixation. XSS riflesso può iniettare JavaScript che imposta un cookie di sessione controllato nel browser della vittima. Affrontare XSS chiude uno dei principali canali di consegna della fixation.
• Cross-Site Request Forgery (CWE-352) viene spesso confuso con la session fixation, ma la meccanica è diversa. CSRF sfrutta la trasmissione automatica dei cookie da parte del browser per forgiare richieste da una sessione autenticata. Non richiede che l'attaccante conosca o controlli l'ID di sessione. CWE-352 si è classificato #9 nella CWE Top 25 del 2023.
• Improper Authentication (CWE-287) è strettamente correlata alla session fixation, rientrando nella stessa categoria OWASP A07 dei fallimenti di autenticazione. CWE-287 copre tutte le forme di autenticazione compromessa e si è classificata #13 nella CWE Top 25 del 2023 con 10 voci nel catalogo CISA Known Exploited Vulnerabilities.
• Insufficient Session Expiration (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) amplifica il rischio di session fixation estendendo la finestra durante la quale un ID di sessione fissato rimane valido. Timeout di sessione lunghi danno agli attaccanti più tempo per sfruttare una sessione fissata.
• Generation of Predictable Numbers (CWE-340) può precedere la session fixation tramite una relazione CanFollow nella tassonomia MITRE. Identificatori di sessione prevedibili abbassano la barriera per gli attacchi di fixation rendendo possibile indovinare valori validi di ID di sessione. Affrontare la session fixation isolatamente raramente copre tutta la superficie di rischio; revisionare queste debolezze correlate nello stesso ciclo chiude le lacune che la fixation sfrutta per ottenere il suo punto d'appoggio iniziale.

CVE correlati

ID CVE	Descrizione	Gravità	Prodotto interessato	Anno
CVE-2026-23796	L'identificatore di sessione non viene rigenerato dopo il login; l'attaccante imposta l'ID di sessione della vittima prima dell'autenticazione e dirotta la sessione post-login	In attesa	OpenSolution: Quick.Cart	2026
CVE-2026-23624	Session fixation attivata quando l'autenticazione remota utilizza variabili SSO; l'attaccante può rubare la sessione precedentemente aperta da un altro utente sulla stessa macchina	In attesa	GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5)	2026
CVE-2025-55266	Session fixation (CWE-384) consente all'attaccante di prendere il controllo della sessione utente ed eseguire transazioni non autorizzate per conto della vittima	MEDIA (6.5)	HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0)	2025
CVE-2025-1723	Gestione errata della sessione (CWE-287) in ManageEngine ADSelfService Plus; utente autenticato a basso privilegio sfrutta una gestione impropria della sessione per prendere il controllo di altri account utente	ALTA (9.3)	Zohocorp ManageEngine ADSelfService Plus (≤ build 6510)	2025
CVE-2024-38513	Session fixation (CWE-384) nel middleware di sessione GoFiber; accetta valori session_id forniti dall'utente, dando all'attaccante il controllo della chiave di sessione autenticata	CRITICA (9.8)	GoFiber: Fiber (< 2.52.5)	2024
CVE-2024-22250	Session hijacking (CWE-384) nel plug-in VMware Enhanced Authentication deprecato; attaccante locale non privilegiato dirotta la sessione EAP autenticata di un utente di dominio privilegiato	ALTA (7.8)	VMware: Enhanced Authentication Plug-in (deprecato)	2024
CVE-2024-22245	Relay di autenticazione e session hijacking nel plug-in VMware EAP deprecato; attore malevolo induce l'utente di dominio a inoltrare ticket di servizio Kerberos per SPN Active Directory arbitrari	CRITICA (9.6)	VMware: Enhanced Authentication Plug-in (deprecato)	2024
CVE-2023-27524	SECRET_KEY di default in Apache Superset utilizzata per firmare i cookie di sessione; attaccante a conoscenza del valore di default può forgiare cookie di sessione validi e autenticarsi come qualsiasi utente, inclusi gli admin; CISA KEV	CRITICA (9.8)	Apache Superset (≤ 2.0.1)	2023
CVE-2021-34428	L'ID di sessione rimane valido nel session ID manager quando viene generata un'eccezione da SessionListener#sessionDestroyed() (CWE-613); la sessione dell'utente precedente è accessibile dopo il logout su computer condivisi	BASSA (3.5)	Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3)	2021
CVE-2020-17526	I token di sessione firmati con la chiave segreta di default sono accettati tra diverse installazioni Airflow; utente autenticato su un'istanza può accedere a un'altra senza ri-autenticazione	ALTA (8.8)	Apache Airflow Webserver (< 1.10.14)	2020

Conclusione

La session fixation sfrutta un singolo errore ben compreso: l'applicazione non rigenera l'ID di sessione dopo l'autenticazione. Formalmente classificata come CWE-384 e mappata su OWASP Top 10 2025 A07, continua ad apparire su piattaforme CMS, framework Java, applicazioni PHP e sistemi ICS/SCADA. 

Riduci il rischio ruotando gli ID di sessione a ogni cambio di privilegio, applicando l'accettazione restrittiva della sessione, rafforzando l'ambito dei cookie e revisionando l'attività post-autenticazione per individuare abusi.

Domande frequenti

Cos'è la vulnerabilità di Session Fixation?

La session fixation si verifica quando un'applicazione mantiene lo stesso ID di sessione prima e dopo l'accesso. Un attaccante fa prima utilizzare alla vittima un ID di sessione noto, poi attende che la vittima si autentichi. 

Se l'applicazione non emette un nuovo ID, l'attaccante può utilizzare quella stessa sessione autenticata. La difesa chiave è semplice: invalidare la vecchia sessione e crearne una nuova dopo l'accesso e altri cambi di privilegi.

La session fixation fa parte dell'OWASP Top 10?

Sì. CWE-384 è incluso nell'OWASP Top 10 2025 A07: Authentication Failures. Per chi difende, conta meno come etichetta e più come segnale di priorità: la session fixation è trattata come un errore di autenticazione, non solo come una errata configurazione dei cookie. 

Va considerata nelle revisioni dei flussi di login, nei test di gestione delle sessioni e nelle attività di rafforzamento dell'autenticazione.

La session fixation può essere sfruttata da remoto?

Sì. La consegna remota è comune perché l'attaccante di solito ha solo bisogno di un modo per far utilizzare alla vittima un ID di sessione scelto. Questo può avvenire tramite un URL creato ad hoc, uno script lato browser, una risposta malevola o un'applicazione più debole sullo stesso dominio principale. 

L'accesso fisico è richiesto solo in scenari come terminali condivisi o pubblici.

Quali tipi di applicazioni sono più vulnerabili alla session fixation?

Le applicazioni a rischio più elevato sono quelle che accettano ID di sessione forniti dall'utente o che non li ruotano dopo l'autenticazione. Gli esempi comuni nell'articolo includono schemi di sessione basati su URL, moduli di autenticazione CMS, stack di applicazioni Java, ambienti a dominio condiviso, piattaforme di workflow e interfacce web ICS/SCADA. 

Il modello condiviso è una gestione debole del ciclo di vita della sessione, non un singolo linguaggio o settore.

Come scoprono tipicamente gli attaccanti la session fixation?

Testano se una sessione sopravvive all'accesso senza cambiamenti. Un metodo semplice è catturare un ID di sessione pre-autenticazione, autenticarsi con esso e confrontare il valore dopo. 

Se lo stesso ID è ancora valido, la vulnerabilità è presente. Gli strumenti di scansione possono aiutare, ma spesso è necessario il test manuale per casi limite come la rigenerazione parziale o il comportamento dei cookie tra sottodomini.

Quali sono i primi segnali di sfruttamento della session fixation?

Verificare se una sessione si comporta come se fosse posseduta da due utenti. Segnali pratici includono la stessa sessione che appare da indirizzi IP diversi, cambiamenti improvvisi di dispositivo o posizione, o pattern di accesso che cambiano immediatamente dopo il login. 

Richieste che trasportano identificatori di sessione negli URL verso endpoint di autenticazione possono anche indicare tentativi di fixation piuttosto che normale navigazione.

Quanto è grave la session fixation rispetto ad altre vulnerabilità?

La gravità dipende da cosa può fare l'account compromesso. In contesti a basso valore, può essere classificata come media. Nei sistemi ad alto valore, la stessa vulnerabilità può consentire la completa compromissione dell'account e abusi amministrativi. 

Gli esempi di CVE nell'articolo vanno da 4.6 a 9.8, il che dimostra che la session fixation non è intrinsecamente minore; l'impatto è determinato da privilegi, esposizione e controlli circostanti.

La session fixation può portare alla compromissione completa del sistema?

Può portare direttamente alla compromissione completa dell'account preso di mira, e ciò può diventare una compromissione più ampia se la vittima è un amministratore. Una volta che l'attaccante eredita privilegi elevati, può modificare impostazioni, accedere a dati sensibili o eseguire azioni che influenzano l'intero ambiente. 

La vulnerabilità in sé prende di mira le sessioni, ma l'impatto aziendale può estendersi ben oltre un singolo accesso.

La session fixation è facile da individuare con gli strumenti di sicurezza?

La forma più semplice è relativamente facile da individuare perché gli strumenti possono confrontare gli ID di sessione prima e dopo l'autenticazione. I casi più complessi riguardano la rigenerazione parziale, i cookie ereditati tra sottodomini o condizioni legate al trasporto e al comportamento del browser. 

In pratica, la scansione è utile per la copertura, ma il test manuale mirato resta importante per confermare la reale sfruttabilità.

Quali settori sono più a rischio per la session fixation?

Qualsiasi settore che gestisce applicazioni web autenticate è esposto, soprattutto dove gli utenti trattano dati o transazioni sensibili. L'articolo evidenzia e-commerce, piattaforme enterprise, ambienti a dominio condiviso, sistemi regolamentati in stile sanitario e deployment ICS/SCADA. 

Il rischio aumenta quando le organizzazioni si affidano a plugin, gestione delle sessioni legacy o più applicazioni che condividono un dominio principale.