--- id: CP-048 slug: furto-cookie-sessione-token-bearer lang: it title: Furto di cookie di sessione e token bearer description: Un cookie di sessione rubato consente di spacciarsi per un dipendente senza password né secondo fattore. Meccanismo, caso reale e riflessi. canonical_url: https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/ markdown_url: https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, «Furto di cookie di sessione e token bearer», Cyberpedia, 2026. https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/ (CC BY 4.0) wing: 1 theme: master_passwords reflex: cr-023 schema: G3 updated: "2026-11-03" translations: it: https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/ fr: https://startbrain.io/cyberpedia/fr/articles/vol-cookies-session-jetons-porteurs/ en: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ de: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ es: https://startbrain.io/cyberpedia/es/articles/robo-cookies-sesion-tokens-portador/ nl: https://startbrain.io/cyberpedia/nl/articles/diefstal-sessiecookies-bearer-tokens/ sources: - "n": 1 title: Steal Web Session Cookie publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 2 title: "Use Alternate Authentication Material: Web Session Cookie" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/004/ accessed: "2026-11-03" - "n": 3 title: Session hijacking attack publisher: OWASP url: https://community.owasp.org/attacks/Session_hijacking_attack accessed: "2026-11-03" - "n": 4 title: Steal Application Access Token publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 5 title: NIST Special Publication 800-63B publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63b.html accessed: "2026-11-03" - "n": 6 title: "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud" publisher: Microsoft url: https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ published: "2022-07-12" accessed: "2026-11-03" - "n": 7 title: Session Management - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: Browser Session Hijacking publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1185/ accessed: "2026-11-03" --- # Furto di cookie di sessione e token bearer Quando un dipendente accede alla posta elettronica o a uno strumento online, il servizio gli consegna un piccolo elemento di identificazione, il più delle volte un cookie, che dimostra che è già autenticato. Se un attaccante si impossessa di questo elemento, può entrare al posto della vittima senza conoscerne la password [1]. Per il dipendente, di solito non si vede nulla: la sessione prosegue, e con essa il lavoro. Questa scheda spiega da dove nasce il furto, che uso ne fa un attaccante e che cosa può fare ciascuno per ridurre il rischio. ## In 30 secondi - Dove succede: sulla postazione di lavoro (malware), su un sito falso che inoltra la vera pagina di accesso [1], oppure in un browser compromesso [8]. - Che cosa vuole l'attaccante: riprendere una sessione già aperta, leggere i messaggi e agire a nome della vittima, aggirando alcuni secondi fattori [2]. - Il riflesso: uscire dai servizi quando si ha finito, revocare le proprie sessioni in caso di dubbio, chiudere regolarmente le sessioni del browser. - Se è già successo: avvisare subito il supporto informatico, perché la sessione rubata resta utilizzabile finché è attiva [2]. ## Domande dirette ### Che cos'è un cookie di sessione? Dopo un accesso riuscito, molte applicazioni web usano un cookie di sessione come prova di autenticazione [1]. Il protocollo web, di per sé, non ricorda chi è chi da una richiesta all'altra: il server invia quindi al browser un token, che il browser presenta a ogni scambio successivo [3]. ### Che cos'è un token di accesso e in che cosa differisce dal cookie? Un token di accesso serve a fare richieste autorizzate a nome di un utente o di un servizio. È comune nelle applicazioni online (SaaS) e nei servizi cloud [4]. I due oggetti hanno la stessa debolezza: chi li presenta viene accettato come la persona che li ha ottenuti. La SP 800-63B del NIST, versione sostituita dal 1° agosto 2025 dalla SP 800-63-4, precisava inoltre che la presenza di un token di accesso OAuth non deve essere interpretata come la presenza dell'utente in assenza di altri segnali, e che un token di questo tipo può restare valido a lungo dopo la fine della sessione di autenticazione [5]. ### Il mio secondo fattore non mi protegge? Protegge l'accesso, non la sessione che segue. MITRE indica che questa tecnica aggira alcuni protocolli di autenticazione a più fattori, poiché la sessione è già autenticata [2]. Microsoft precisa che non si tratta di una falla dell'autenticazione a più fattori: il cookie rubato autentica l'attaccante qualunque sia il metodo di accesso dell'utente [6]. ### Per quanto tempo un cookie rubato resta utilizzabile? I cookie restano spesso validi a lungo, anche se l'applicazione non viene usata attivamente [1]. L'attaccante può servirsene finché il cookie è attivo [2]. L'OWASP osserva inoltre che un timeout di inattività non limita un attaccante che ha preso la sessione: può generare attività per mantenerla aperta [7]. ## Nei panni dell'attaccante L'attaccante cerca un elemento riutilizzabile, non un segreto da indovinare. I cookie si trovano sul disco, nella memoria del browser e nel traffico di rete verso sistemi remoti. Anche altre applicazioni della postazione possono tenere in memoria cookie di autenticazione, per esempio quelle che si collegano a servizi cloud [1]. Ottenuto il cookie, l'attaccante lo importa in un browser che controlla. Usa allora il sito come l'utente, finché la sessione è attiva. Può consultare informazioni sensibili, leggere e-mail o fare ciò che l'account della vittima è autorizzato a fare [2]. Per il token di accesso, una via descritta è il phishing: l'attaccante registra un'applicazione trappola e invia un link per indurre la vittima a concederle l'accesso. Una volta concesso il token, l'applicazione può ottenere un accesso potenzialmente duraturo all'account [4]. I token di accesso hanno talvolta una durata limitata, ma l'attaccante può anche rubare un token di aggiornamento, che gli fornisce nuovi token di accesso senza chiedere nulla all'utente [4]. ## Cosa si vede sullo schermo Il dipendente non vede nulla: possono esistere avvisi lato amministratore (vedere più avanti). Nel caso di un sito falso che fa da relay (descritto più avanti), la pagina è identica alla vera: l'unica differenza visibile è l'indirizzo [6]. Dopo l'inserimento della password, la vittima viene reindirizzata alla pagina legittima e l'attacco prosegue in secondo piano [6]. Ecco un'illustrazione neutralizzata dell'indirizzo di un sito falso che fa da relay. È inventata per l'esempio. ```text Illustrazione (indirizzo fittizio, neutralizzato): hxxps://login[.]exemple-connexion[.]invalid/ [pagina identica alla vera pagina di accesso, cambia solo l'indirizzo] ``` Esistono alcuni segnali indiretti. Se l'attaccante accede mentre la vittima sta lavorando, lato amministratore possono comparire avvisi di «spostamento impossibile» [6]. Regole sconosciute nella posta in arrivo sono un altro segnale: nel caso descritto più avanti, l'attaccante ne ha creata una perché la vittima non vedesse le risposte del suo bersaglio [6]. ## Sotto il cofano Le fonti citate qui descrivono tre vie di furto. - Il malware ladro: software dannosi prendono di mira i cookie dei browser presenti sulla postazione [1]. Alcuni estraggono il cookie di sessione e lo inviano al server dell'attaccante [1]. - Il sito falso che fa da relay: nell'attacco detto dell'intermediario (adversary-in-the-middle), l'attaccante colloca un server proxy tra l'utente e il sito preso di mira. In questo modo cattura la password e il cookie di sessione [6]. Strumenti liberi come Evilginx2, Modlishka e Muraena automatizzano questo procedimento [6]. - Il browser compromesso: un attaccante può iniettare software in un browser per ereditare i cookie, le sessioni HTTP e i certificati client dell'utente, e usarli poi per entrare in una intranet autenticata [8]. Questa tecnica può aggirare anche l'autenticazione a due fattori [8]. Può richiedere privilegi particolari sulla postazione [8]. Perché il replay funziona? Il cookie è la prova dell'accesso: il server non riverifica la password a ogni pagina [6]. La SP 800-63B del NIST ammette altri metodi per identificare in modo sicuro il dispositivo, tra cui il TLS reciproco e il token binding [5]. L'OWASP raccomanda di legare l'identificativo di sessione ad altre proprietà del client, come l'indirizzo IP o lo User-Agent. Riconosce tuttavia che un attaccante abile può aggirare questo controllo, per esempio condividendo la stessa rete della vittima o copiando lo User-Agent [7]. Quanto alle durate, l'OWASP cita timeout di inattività comuni da 2 a 5 minuti per le applicazioni di alto valore e da 15 a 30 minuti per quelle a basso rischio. Per un impiegato che usa un'applicazione tutto il giorno, cita un timeout assoluto da 4 a 8 ore [7]. La SP 800-63B del NIST, sostituita dal 1° agosto 2025 dalla SP 800-63-4, richiedeva che i segreti di sessione venissero cancellati o invalidati alla disconnessione [5]. ## Autopsie ### Campagna di phishing con sito relay contro Microsoft 365 (documentata il 12 luglio 2022) Il 12 luglio 2022 Microsoft pubblica l'analisi di una campagna su larga scala. Secondo i suoi dati, ha tentato di colpire più di 10.000 organizzazioni a partire da settembre 2021 [6]. Gli attaccanti hanno usato siti relay per rubare le password e dirottare la sessione della vittima, anche con l'autenticazione a più fattori attivata [6]. In una delle ondate osservate, un'e-mail con un allegato HTML annunciava un messaggio vocale. L'allegato mostrava una falsa barra di download, poi reindirizzava a un sito relay costruito con Evilginx2, che riproduceva la pagina di accesso dell'organizzazione [6]. La vittima inseriva le credenziali, veniva reindirizzata alla pagina legittima office.com, e l'attaccante risultava autenticato a suo nome [6]. Il seguito mirava alla frode sui pagamenti. Secondo Microsoft, a volte sono bastati cinque minuti tra il furto e l'inizio della frode. L'attaccante usava il cookie rubato per entrare nella posta online, talvolta con un cookie che portava già l'indicazione di autenticazione a più fattori [6]. Cercava poi scambi legati ai pagamenti, eliminava l'e-mail di phishing iniziale e creava una regola della posta in arrivo che archiviava e segnava come lette le risposte del suo bersaglio, perché la vittima non notasse nulla [6]. Infine eliminava le proprie risposte dalle cartelle della posta inviata e degli elementi eliminati [6]. Microsoft raccomanda autenticazioni resistenti al phishing (FIDO 2.0 o certificati) e politiche di accesso condizionale, che valutano ogni tentativo di uso di un cookie rubato [6]. ## Cosa fare Questi gesti derivano dalle fonti citate qui. Il loro effetto è ridurre la durata o la portata di una sessione rubata, non garantire che non venga rubata. - Uscire esplicitamente dai servizi quando si ha finito. L'OWASP indica che la chiusura del browser non forza in modo affidabile la disconnessione e consiglia una disconnessione esplicita, con timeout lato server [7]. - Revocare le proprie sessioni se sorge un dubbio (postazione infetta, pagina di accesso sospetta). Le fonti citate qui non dettagliano la procedura: la indica il supporto informatico dell'azienda. - Chiudere regolarmente le sessioni aperte nel browser. MITRE raccomanda di chiudere regolarmente tutte le sessioni del browser [8]. - Controllare l'indirizzo prima di inserire la password: l'indirizzo è l'unica differenza visibile tra un sito relay falso e quello vero [6]. - Segnalare ogni dubbio al supporto informatico, senza attendere: finché la sessione è attiva, l'attaccante può usarla [2]. Sul versante aziendale, MITRE cita la configurazione dei browser per eliminare regolarmente i cookie persistenti [2]. ## Fonti 1. MITRE ATT&CK, «Steal Web Session Cookie». https://attack.mitre.org/techniques/T1539/ (consultato il 3 novembre 2026) 2. MITRE ATT&CK, «Use Alternate Authentication Material: Web Session Cookie». https://attack.mitre.org/techniques/T1550/004/ (consultato il 3 novembre 2026) 3. OWASP, «Session hijacking attack». https://community.owasp.org/attacks/Session_hijacking_attack (consultato il 3 novembre 2026) 4. MITRE ATT&CK, «Steal Application Access Token». https://attack.mitre.org/techniques/T1528/ (consultato il 3 novembre 2026) 5. NIST, «NIST Special Publication 800-63B». https://pages.nist.gov/800-63-3/sp800-63b.html (consultato il 3 novembre 2026) 6. Microsoft, «From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud», 12 luglio 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (consultato il 3 novembre 2026) 7. OWASP, «Session Management - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consultato il 3 novembre 2026) 8. MITRE ATT&CK, «Browser Session Hijacking». https://attack.mitre.org/techniques/T1185/ (consultato il 3 novembre 2026) --- Fonte originale: Cyberpedia, l'enciclopedia pubblica di cybersicurezza e IA pubblicata da Brain. Versione canonica: https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/ Puoi riutilizzare liberamente questo testo con licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), a condizione di citare «Brain, Cyberpedia» con un link all'indirizzo qui sopra.