Che cos'è la Broken Authentication?
La broken authentication è una classe di vulnerabilità che consente agli attaccanti di compromettere le identità degli utenti sfruttando le debolezze nei meccanismi con cui le applicazioni verificano chi sei e mantengono quello stato verificato. Quando i meccanismi di login, la gestione delle sessioni o i processi di recupero delle credenziali presentano delle falle, gli attaccanti possono impersonare utenti legittimi, aumentare i privilegi e accedere ai sistemi senza autorizzazione.
Questa vulnerabilità è presente in ogni elenco OWASP sin dalle prime edizioni del progetto. OWASP ha rinominato e affinato la categoria nel tempo, riflettendo una copertura più ampia delle debolezze legate all'autenticazione piuttosto che una perdita di importanza.
L'ambito della broken authentication va ben oltre il semplice tentativo di indovinare le password. Comprende credential stuffing, session fixation, bypass MFA, falsificazione di token, credenziali hard-coded e assenza di autenticazione su funzioni critiche. Il CWE di riferimento per l'intera categoria è CWE-287, con un ampio insieme di CWE correlati mappati nella categoria nelle più recenti classificazioni OWASP.
Secondo il rapporto DBIR, l'abuso di credenziali rimane uno dei principali metodi di accesso iniziale nelle violazioni. Comprendere come funziona la broken authentication consente di contrastarla in modo più efficace.
.jpg)
Come funziona la Broken Authentication?
La broken authentication sfrutta vulnerabilità in due domini di fallimento distinti: autenticazione, che riguarda come le applicazioni verificano chi sei, e gestione della sessione, che riguarda come mantengono quell'identità verificata per tutta la durata della visita. Ogni dominio presenta diverse superfici di attacco, ma entrambi portano allo stesso risultato: accesso non autorizzato.
Fallimenti dell'autenticazione
Quando un'applicazione non verifica correttamente l'identità dell'utente, gli attaccanti ottengono l'accesso dalla porta principale. Un attacco di credential stuffing invia coppie di username e password rubate al tuo endpoint di login. Se l'applicazione non implementa limitazioni di frequenza o blocco dell'account, l'attaccante può testare le credenziali su larga scala finché non trova coppie valide.
Il flusso dell'attacco è semplice. L'attaccante ottiene dump di credenziali da precedenti violazioni. Inserisce queste coppie in strumenti automatizzati che prendono di mira la tua pagina di login. L'applicazione accetta ogni tentativo senza throttling, blocco o CAPTCHA. Quando una coppia valida corrisponde, l'attaccante ottiene pieno accesso all'account.
Brute force segue uno schema simile ma genera combinazioni di password invece di riprodurre credenziali note. Password spraying adotta l'approccio inverso: testa una password comune su molti account contemporaneamente per evitare le soglie di blocco per singolo account.
Fallimenti nella gestione della sessione
Anche dopo un'autenticazione corretta, falle nella gestione della sessione possono consegnare quello stato autenticato a un attaccante. In un attacco di session fixation (CWE-384), l'attaccante imposta un ID di sessione noto prima che tu effettui il login. Se l'applicazione non rigenera l'ID di sessione dopo l'autenticazione, l'attaccante usa l'ID preimpostato per accedere alla tua sessione autenticata.
L'esposizione del token di sessione crea un altro vettore. Quando gli ID di sessione compaiono negli URL, vengono registrati nei log di accesso del server, nella cronologia del browser e negli header HTTP referrer. Un attaccante che ottiene l'URL ottiene la sessione. L'insufficiente scadenza della sessione (CWE-613) aggrava il problema: se chiudi una scheda del browser senza effettuare il logout, qualcuno che usa lo stesso browser successivamente potrebbe trovare la tua sessione ancora attiva.
Bypass MFA
L'autenticazione a più fattori aggiunge un secondo livello di verifica, ma gli attaccanti hanno sviluppato tecniche affidabili di bypass. La MFA fatigue, talvolta chiamata prompt bombing, inonda il dispositivo dell'utente di notifiche push finché non ne approva una per interrompere le interruzioni. La violazione Uber è spesso citata come esempio di come credenziali rubate, ripetuti prompt MFA e social engineering possano essere concatenati per ottenere accesso ai sistemi interni.
Questi meccanismi funzionano perché la broken authentication raramente è una singola falla. È una catena di debolezze, da credenziali deboli a limiti di frequenza mancanti fino a una gestione della sessione inadeguata, che gli attaccanti sfruttano in sequenza.
Tipologie di Broken Authentication
La broken authentication non è una singola vulnerabilità ma una categoria che comprende sei diversi tipi di fallimento. Ognuno prende di mira un diverso livello dello stack di autenticazione e richiede controlli specifici per essere mitigato.
| Tipo | Cosa fallisce | Metodi di attacco comuni | CWE principali |
| Attacchi basati su credenziali | Policy password, rate limiting | Credential stuffing, brute force, password spraying | CWE-307, CWE-521 |
| Difetti nella gestione della sessione | Ciclo di vita e archiviazione dell'ID di sessione | Session fixation, session hijacking, furto di cookie | CWE-384, CWE-613 |
| Bypass MFA | Implementazione del secondo fattore | MFA fatigue, relay TOTP, SIM swapping | CWE-308 |
| Falsificazione di token | Protezione delle chiavi crittografiche | Falsificazione di asserzioni SAML, manipolazione JWT, furto di token OAuth | CWE-347, CWE-345 |
| Credenziali hard-coded | Gestione delle credenziali nel codice | Estrazione di credenziali statiche da file sorgente o di configurazione | CWE-798 |
| Assenza di autenticazione | Applicazione dell'autenticazione su funzioni critiche | Accesso diretto agli oggetti, bypass endpoint API, accesso tramite percorso alternativo | CWE-306, CWE-288 |
Comprendere quale tipo è presente in una determinata applicazione determina quali controlli applicare e quali evidenze forensi cercare. Il credential stuffing richiede rate limiting e MFA; l'assenza di autenticazione su un'API admin richiede una risposta fondamentalmente diversa.
Cause della Broken Authentication
La broken authentication non deriva da un singolo errore di progettazione. Emerge da debolezze che si sommano in quattro categorie che le linee guida OWASP identificano come interconnesse con altri rischi Top 10 tra cui broken access control, failure crittografiche e librerie obsolete.
Fallimenti della policy sulle credenziali
Consentire password deboli, di default o ben note rimane la causa più fondamentale. Quando l'applicazione accetta password di default comuni senza enforcement, si offre agli attaccanti un facile punto di ingresso (CWE-521). NIST 63B-4 richiede ai verificatori di controllare le nuove password rispetto a elenchi di password compromesse note, ma molte applicazioni saltano ancora questo passaggio.
Il riutilizzo delle password amplifica il problema. Il rapporto DBIR evidenzia che il riutilizzo delle password tra servizi è ancora comune, il che rende le credenziali rubate molto più utili agli attaccanti.
Fallimenti nella progettazione del flusso di autenticazione
L'assenza di MFA (CWE-308) lascia gli account protetti da un solo fattore che può essere rubato, indovinato o oggetto di phishing. Meccanismi di recupero delle credenziali deboli che si basano su risposte a domande di conoscenza creano un percorso di autenticazione parallelo facilmente indovinabile. L'assenza di rate limiting sui tentativi di login (CWE-307) consente agli attaccanti di testare un gran numero di combinazioni senza conseguenze.
Le credenziali hard-coded nel codice sorgente o nei file di configurazione (CWE-798) rappresentano un fallimento progettuale completo. Questa debolezza appare nelle recenti classifiche CWE Top 25 ed è stata confermata da un alert CISA nell'ambito di attacchi attivi ai sistemi di controllo industriale.
Fallimenti nella gestione del ciclo di vita della sessione
Tre fallimenti nel ciclo di vita della sessione creano percorsi di sfruttamento diretti:
- Non rigenerare l'ID di sessione dopo il login consente attacchi di session fixation
- Consentire alle sessioni di persistere senza timeout di inattività o assoluti estende la finestra per il session hijacking
- Incorporare i token di sessione negli URL invece che in cookie sicuri espone le credenziali tramite ogni sistema che registra o memorizza l'URL
Ciascuno di questi fallimenti aumenta il rischio in modo indipendente; combinati, offrono agli attaccanti molteplici opzioni per mantenere l'accesso non autorizzato.
Fallimenti crittografici e di trasporto
Archiviare le password in chiaro, usare cifratura reversibile o algoritmi di hashing deboli significa che qualsiasi violazione del database espone direttamente le credenziali. Fallimenti di trasporto come la validazione impropria dei certificati (CWE-295) consentono agli attaccanti di intercettare il traffico di autenticazione. Queste cause spesso si sovrappongono a OWASP A02:2021 Cryptographic Failures, dimostrando come la broken authentication si intersechi con altre categorie di vulnerabilità.
Queste quattro categorie raramente si presentano isolate. Una policy debole sulle credenziali rende possibile il credential stuffing; l'assenza di rate limit lo rende praticabile; una gestione della sessione inadeguata estende la finestra dell'attaccante una volta ottenuto l'accesso. Comprendere quali cause sono presenti nel sistema determina sia la gravità del rischio sia dove iniziare la remediation.
Impatto e rischio della Broken Authentication
Le conseguenze della broken authentication vanno dalla compromissione di singoli account a violazioni su scala organizzativa con ricadute normative, finanziarie e operative.
Prevalenza delle violazioni
I fallimenti dell'autenticazione sono tra i percorsi di accesso iniziale più sfruttati. Il rapporto DBIR conferma che l'abuso di credenziali rimane uno dei principali fattori di violazione. Negli attacchi di base alle applicazioni web, le credenziali rubate sono particolarmente diffuse nei servizi finanziari.
Conseguenze finanziarie
Il rapporto IBM ha rilevato che il costo medio globale di una violazione dei dati ha raggiunto i 4,88 milioni di dollari nel 2024, con un aumento del 10% rispetto all'anno precedente. Le organizzazioni dei servizi finanziari hanno registrato una media di 6,08 milioni di dollari per violazione, il 22% in più rispetto alla media globale. Oltre alle spese dirette, il 70% delle organizzazioni colpite ha riportato una significativa o moderata interruzione operativa.
Effetti a cascata sul business
La broken authentication raramente rimane circoscritta. Una credenziale compromessa diventa un punto di pivot per lateral movement, escalation dei privilegi, esfiltrazione dei dati e distribuzione di ransomware. Il DBIR di Verizon ha riscontrato una correlazione tra la vittimizzazione da ransomware e la presenza di domini delle vittime nei dump di credenziali, collegando direttamente la debolezza dell'autenticazione al rischio ransomware.
La broken authentication non è una preoccupazione astratta di sicurezza applicativa. È un meccanismo primario attraverso cui iniziano le violazioni.
Come gli attaccanti sfruttano la Broken Authentication
Gli attaccanti scelgono l'approccio in base alla specifica debolezza di autenticazione che scoprono. Ecco le principali tecniche di sfruttamento, mappate ai CWE di riferimento.
MFA Fatigue e Social Engineering
Quando la MFA blocca un tentativo di credential stuffing, gli attaccanti passano al social engineering. La MFA fatigue invia ripetute notifiche push all'utente legittimo finché non ne approva una. L'advisory CISA ha documentato una tecnica correlata: dopo aver forzato una password debole su un account dormiente, gli attaccanti hanno registrato un nuovo dispositivo MFA perché la configurazione predefinita di Duo consentiva la ri-registrazione per account inattivi, ottenendo così l'accesso alla rete.
Falsificazione di token SAML
Nella campagna SolarWinds/SUNBURST, gli attaccanti hanno estratto chiavi di cifratura private dai container Active Directory Federation Services, quindi hanno falsificato asserzioni SAML che risultavano valide per qualsiasi relying party. Secondo il report CISA, questa tecnica Golden SAML ha bypassato completamente l'autenticazione senza possedere credenziali legittime, consentendo l'accesso ad ambienti cloud di diverse agenzie federali statunitensi.
Session Hijacking tramite divulgazione di token
CVE-2023-4966, noto come Citrix Bleed, ha permesso agli attaccanti di estrarre token di sessione validi da appliance di accesso remoto. Con un token di sessione rubato, l'attaccante si spaccia per un utente già autenticato, bypassando sia la password che la MFA. CISA ha confermato lo sfruttamento attivo zero-day prima della disponibilità di una patch [cite-19].
Bypass dell'autenticazione tramite percorso alternativo
Alcune vulnerabilità eliminano del tutto i requisiti di autenticazione. Una falla in un'appliance di rete ha consentito l'accesso super-admin non autenticato tramite un websocket Node.js e ha ricevuto una valutazione di gravità critica [cite-20]. Un'altra falla nell'interfaccia di gestione ha permesso l'escalation dei privilegi admin senza autenticazione tramite l'interfaccia web di gestione. Il problema dell'interfaccia di gestione rappresenta CWE-306: assenza totale di autenticazione su una funzione critica, mentre il problema del websocket si mappa a CWE-288: bypass dell'autenticazione tramite percorso o canale alternativo.
Attacchi di Capture-Replay
Gli attaccanti intercettano token di autenticazione o credenziali in transito e li riproducono per ottenere l'accesso (CWE-294). Senza token vincolati al mittente come specificato in RFC 9700, le implementazioni OAuth rimangono vulnerabili a questa tecnica.
Ognuna di queste tecniche produce diverse firme forensi, che determinano come individuarle e rispondere.
Chi è colpito dalla Broken Authentication?
La broken authentication colpisce ogni organizzazione che si affida all'identità utente per il controllo degli accessi. Tuttavia, settori e tipologie di sistemi specifici presentano un rischio elevato.
Applicazioni web e API
Qualsiasi applicazione che gestisce la propria autenticazione è direttamente esposta. OWASP affronta esplicitamente la broken authentication specifica delle API nel progetto OWASP API Security, sottolineando che gli endpoint di autenticazione richiedono protezioni contro brute force più rigorose rispetto al normale rate limiting delle API.
Piattaforme cloud e SaaS
La campagna Snowflake/UNC5537 ha dimostrato che le piattaforme cloud con autenticazione a singolo fattore sono obiettivi di alto valore, con molte organizzazioni violate perché gli account interessati non avevano MFA. Le piattaforme cloud che delegano l'autenticazione agli identity provider ereditano le debolezze dell'IdP.
Servizi finanziari
Le istituzioni finanziarie affrontano un rischio sproporzionato. Il finance snapshot di Verizon ha rilevato che le credenziali rubate dominano le violazioni di base delle applicazioni web nei servizi finanziari. L'incidente di credential stuffing su PayPal ha portato a un accordo regolatorio e all'obbligo di MFA per gli account clienti statunitensi.
Infrastrutture critiche e appliance di rete
Gateway VPN, firewall e interfacce di gestione di rete sono obiettivi privilegiati. CVE-2019-11510, CVE-2024-55591 e CVE-2024-53704 rappresentano tutte vulnerabilità di bypass dell'autenticazione in dispositivi perimetrali che CISA ha aggiunto al proprio catalogo Known Exploited Vulnerabilities.
Sanità e pubblica amministrazione
Le organizzazioni che gestiscono dati personali sensibili affrontano sia rischi di violazione sia conseguenze normative, con CISA che documenta come l'autenticazione debole sia costantemente tra le principali criticità rilevate secondo il rapporto di valutazione dell'autenticazione per i sistemi Federal High Value Asset.
I seguenti incidenti mostrano come questi rischi si concretizzano nei diversi settori.
Esempi reali di Broken Authentication
Queste violazioni illustrano come la broken authentication si manifesti in diversi settori, tecniche di attacco e scale di impatto.
23andMe: Credential Stuffing e esposizione massiva di dati
Gli attaccanti hanno utilizzato il credential stuffing per accedere a un piccolo sottoinsieme di account utente 23andMe in cui le password corrispondevano a quelle di precedenti violazioni. Tramite la funzione DNA Relatives, quel punto d'appoggio si è ampliato a un set molto più ampio di dati di profilo esposti. Secondo le comunicazioni SEC di 23andMe, l'azienda ha sostenuto spese legate all'incidente. Al momento della violazione, la MFA non era obbligatoria.
Snowflake/UNC5537: Credenziali infostealer usate successivamente
L'attore UNC5537 ha utilizzato furto di credenziali tramite malware infostealer per violare organizzazioni attraverso account Snowflake cloud data warehouse. Secondo l'indagine Mandiant, nessuno degli account compromessi aveva la MFA abilitata. Le vittime includevano Ticketmaster, Santander Bank e Advance Auto Parts.
SolarWinds/SUNBURST: Falsificazione di token SAML
Attori statali russi hanno compromesso il processo di build di SolarWinds e utilizzato l'accesso risultante per rubare chiavi di cifratura private ADFS. Secondo il report CISA, hanno falsificato token di autenticazione SAML affidabili per accedere ad ambienti cloud di diverse agenzie governative statunitensi senza possedere credenziali legittime.
PayPal: Credential Stuffing con conseguenze regolatorie
Gli attaccanti hanno utilizzato il credential stuffing per accedere agli account dei clienti, esponendo dati altamente sensibili. Il DFS di New York ha imposto un accordo regolatorio e richiesto la MFA obbligatoria per gli account clienti statunitensi.
GoDaddy: Compromissione delle credenziali su più anni
Una password amministrativa compromessa ha consentito agli attaccanti di accedere all'ambiente Managed WordPress di GoDaddy, secondo il report di violazione GoDaddy. La violazione ha interessato un ampio insieme di clienti Managed WordPress attivi e inattivi, con credenziali admin WordPress, account FTP ed email rubati. Gli attaccanti hanno anche installato malware e ottenuto il codice sorgente.
Yahoo: Falsificazione di cookie su scala massiva
La violazione Yahoo ha infine interessato tutti e 3 i miliardi di account utente, secondo la copertura del New York Times. Gli attaccanti hanno utilizzato cookie di autenticazione falsificati per accedere agli account senza password. Una successiva violazione ha coinvolto spear-phishing per credenziali amministrative, con la falsificazione dei cookie collegata a un attore statale.
Questi incidenti fanno parte di un più ampio schema storico che si estende per due decenni.
Broken Authentication: una timeline
La storia della broken authentication segue l'evoluzione stessa della sicurezza web, dai primi difetti nella gestione delle sessioni agli attacchi odierni a livello di identità.
| Anno | Pietra miliare |
| 2004 | Prima pubblicazione OWASP Top 10; "Broken Authentication and Session Management" nominata come A3. |
| 2012 | Violazione LinkedIn espone un enorme set di credenziali tramite hashing SHA-1 senza salt. |
| 2013 | Violazione Yahoo colpisce tutti gli account utente; codice malevolo bypassa i controlli account. OWASP classifica la broken authentication come A2. |
| 2017 | OWASP Top 10 mantiene la broken authentication ad A2 e sottolinea la disponibilità di enormi raccolte di credenziali per stuffing. |
| 2019 | CVE-2019-11510, Pulse Connect Secure, viene aggiunto a CISA KEV. |
| 2020 | SolarWinds/SUNBURST: falsificazione di token SAML compromette agenzie federali USA. |
| 2021 | CISA documenta attori statali russi che bypassano Duo MFA tramite ri-registrazione di account dormienti. OWASP riclassifica la categoria come A07. |
| 2022 | Violazione Uber tramite MFA fatigue. Credential stuffing su PayPal porta a un accordo regolatorio. |
| 2023 | Credential stuffing su 23andMe espone milioni di profili. Citrix Bleed consente session hijacking. |
| 2024 | Campagna Snowflake/UNC5537 viola molte organizzazioni prive di MFA. |
| 2025 | OWASP Top 10:2025 amplia ulteriormente la categoria. CVE-2024-55591 riceve attenzione critica e il DBIR di Verizon conferma l'abuso di credenziali come principale vettore di accesso iniziale. |
La broken authentication è passata da una falla nelle applicazioni web a un problema di sicurezza dell'identità full-stack che coinvolge applicazioni, infrastrutture e ambienti cloud.
Come rilevare la Broken Authentication
Individuare la broken authentication richiede un approccio stratificato che copra difetti di progettazione applicativa, abuso di credenziali in fase di esecuzione e anomalie comportamentali post-autenticazione.
Analisi dei log e delle sessioni
La Authentication Cheat Sheet OWASP specifica che è necessario registrare e revisionare tutti i fallimenti di autenticazione, errori di password e blocchi account. Cercare pattern che indichino credential stuffing: volumi elevati di login falliti su diversi account dallo stesso intervallo IP, o login falliti su un singolo account da località geografiche diverse.
La Session Management Cheat Sheet OWASP identifica eventi di sessione che dovrebbero attivare sfide di riautenticazione: login da nuovi o sospetti indirizzi IP, tentativi di cambio password e completamento di flussi di recupero account. Distinguere tra gestione permissiva della sessione, che accetta qualsiasi ID di sessione impostato dall'utente ed è vulnerabile, e gestione rigorosa, che accetta solo ID generati dal server.
Dynamic application security testing (DAST)
L'OWASP Testing Guide definisce procedure di test specifiche per l'autenticazione nella serie WSTG-ATHN. Queste coprono test per credenziali di default, meccanismi di blocco deboli, bypass dello schema di autenticazione, flussi di reset password vulnerabili, domande di sicurezza deboli e difetti nell'implementazione MFA. Strumenti come scanner DAST e utility di test password eseguono questi test su applicazioni in esecuzione.
Analisi statica per credenziali hard-coded
Gli strumenti di static application security testing (SAST) analizzano il codice sorgente prima del deployment per individuare password hard-coded (CWE-798), implementazioni crittografiche deboli e logica di sessione insicura. Questo consente di rilevare difetti nella gestione delle credenziali che il DAST non può raggiungere perché presenti in percorsi di codice non esposti tramite l'interfaccia esterna dell'applicazione.
Identity threat identification and response (ITDR)
Gli attaccanti che utilizzano credenziali rubate valide eludono sia la sicurezza di rete sia quella endpoint perché il loro traffico appare legittimo e non coinvolge malware. I sistemi ITDR monitorano specificamente il livello identità, confrontando gli eventi di autenticazione con baseline comportamentali. Le deviazioni segnalate includono login da località geografiche insolite, lateral movement su dataset non correlati e richieste anomale di escalation dei privilegi. L'architettura XDR estende questo correlando anomalie di autenticazione con successivi lateral movement a livello di rete, rivelando l'intera catena d'attacco che strumenti isolati non rilevano.
Come prevenire la Broken Authentication
La prevenzione si mappa direttamente alle cause radice. Ogni controllo di seguito affronta specifici sottotipi di broken authentication con riferimenti agli standard di riferimento.
Implementare MFA resistente al phishing
Le linee guida CISA identificano FIDO2/WebAuthn e smart card PIV/CAC come gold standard per MFA resistente al phishing. La MFA push è vulnerabile a attacchi di fatigue e phishing in tempo reale che richiedono codici one-time. NIST SP 800-63B richiede MFA approvata a livelli di assurance più elevati.
Applicare policy moderne sulle credenziali
Allinearsi ai requisiti di NIST 63B-4: controllare le nuove password rispetto a elenchi di password compromesse note, consentire tutti i tipi di caratteri inclusi Unicode e spazi, imporre una lunghezza minima e non richiedere la rotazione periodica. L'Authentication Cheat Sheet OWASP raccomanda di includere un misuratore di robustezza password e di ruotare le credenziali solo in caso di confermata fuga di dati.
Per l'archiviazione, la password storage cheat sheet raccomanda Argon2id come algoritmo di hashing primario, con scrypt, bcrypt e PBKDF2 come alternative accettabili. Includere salting, peppering e configurazione del work factor adeguati con percorsi di upgrade per hash legacy.
Implementare rate limiting e blocco account
Applicare protezioni contro brute force sugli endpoint di autenticazione più rigorose del normale rate limiting API. Il progetto OWASP API Security 2023 specifica l'implementazione di blocco account, CAPTCHA e ritardi progressivi. L'OWASP Testing Guide descrive anche le soglie di blocco tipiche utilizzate nella pratica.
Dopo l'autenticazione dell'utente, la sessione stessa diventa la nuova superficie di attacco. Proteggere come quella sessione viene emessa, archiviata e scade è un controllo separato e altrettanto importante.
Gestione sicura della sessione
Utilizzare ID di sessione generati dal server con elevata entropia da un generatore di numeri casuali crittograficamente sicuro. Rigenerare l'ID di sessione dopo ogni login riuscito. Impostare timeout di inattività e assoluti. Non incorporare mai token di sessione negli URL. La Session Management Cheat Sheet OWASP raccomanda di utilizzare framework di gestione sessione integrati, J2EE, ASP.NET, PHP, invece di implementazioni custom.
Rafforzare enumerazione e recupero account
Utilizzare messaggi di risposta identici per tutti gli esiti di autenticazione in modo che gli attaccanti non possano distinguere tra username validi e non validi. La forgot password cheat sheet specifica che le domande di sicurezza non devono essere l'unico meccanismo di recupero e che gli endpoint di recupero credenziali richiedono le stesse protezioni brute force degli endpoint di login.
Eliminare le credenziali di default
OWASP A07 afferma direttamente: "Non distribuire o installare mai con credenziali di default, in particolare per gli utenti admin." Includere i controlli sulle credenziali di default nella checklist di deployment.
Per le applicazioni che utilizzano OAuth e OIDC, credenziali robuste e igiene della sessione non sono sufficienti da sole. I controlli a livello di token prevengono gli attacchi di replay e falsificazione che operano sopra il livello delle credenziali.
Applicare la sicurezza dei token per OAuth/OIDC
RFC 9700 richiede token di accesso vincolati al mittente, rotazione dei refresh token per client pubblici e Mutual TLS secondo RFC 8705 per prevenire attacchi di replay dei token.
L'implementazione di questi controlli richiede gli strumenti giusti su più livelli di sicurezza.
Strumenti per rilevamento e prevenzione
Contrastare la broken authentication richiede copertura su più categorie di strumenti perché nessuna categoria singola copre l'intera superficie di attacco.
| Categoria di strumento | Funzione primaria | Attacchi di autenticazione mitigati |
| Strumenti DAST | Test runtime dei flussi di autenticazione | Bypass, blocco debole, esposizione token di sessione, credenziali di default |
| Strumenti SAST | Analisi del codice sorgente pre-deployment | Credenziali hard-coded, crittografia debole, logica di sessione insicura |
| ITDR | Monitoraggio comportamentale livello identità | Credential stuffing, lateral movement post-compromissione, escalation privilegi |
| XDR con correlazione identità | Telemetria cross-layer: endpoint, rete, cloud, identità | Lateral movement post-autenticazione, impossible travel, ricostruzione completa della catena d'attacco |
| AI comportamentale / UEBA | Anomalia statistica su flussi di eventi di autenticazione | Abuso di credenziali, attività anomala di account di servizio |
Nessuno strumento copre da solo l'intera superficie di attacco. Una copertura efficace combina test pre-deployment, monitoraggio comportamentale runtime e correlazione a livello identità su tutte le fonti. Di seguito viene descritto come SentinelOne copre l'intero stack end-to-end.
Come può aiutare SentinelOne?
Quando gli attaccanti rubano credenziali, si muovono rapidamente. SentinelOne ti aiuta a individuare e bloccare attacchi basati sull'identità su tutto l'ambiente in tempo reale. Ecco come le nostre soluzioni lavorano insieme e ti aiutano.
Singularity™ AI SIEM: visibilità ampia sulle minacce
Inizia con Singularity™ AI SIEM. Raccoglie telemetria di autenticazione da endpoint, reti, servizi cloud e identity provider, quindi correla tutto in un unico punto. Le sue analisi comportamentali rilevano pattern di impossible travel (stesso token a New York e Tokyo a pochi minuti di distanza), anomalie di sessione concorrenti ed escalation privilegi tramite manipolazione di token. Nelle MITRE ATT&CK Evaluations 2024, la piattaforma Singularity ha rilevato il 100% dei passaggi d'attacco senza ritardi e con l'88% di alert in meno rispetto alla mediana—così il tuo team non viene sommerso dal rumore.
Singularity™ Identity: individua i punti deboli prima degli attaccanti
Singularity™ Identity offre rilevamento e risposta continua alle minacce identitarie (ITDR). Scansiona credenziali deboli, esposte o compromesse su Active Directory on-premises e identity provider cloud come Entra ID, Okta, Ping, Duo e SecureAuth. Visualizzi picchi insoliti di login falliti, accessi da località anomale e tentativi di Kerberosting su account di servizio. Include anche identity security posture management (ISPM), così ottieni valutazioni continue della postura di sicurezza identitaria, non solo audit una tantum.
Purple AI: domande in linguaggio naturale, risposte rapide
Quando scatta un alert, Purple AI accelera l'investigazione. Basta porre una domanda in italiano come “mostrami tutti i sistemi a cui questo account compromesso ha avuto accesso nelle ultime 72 ore.” Ricevi risultati correlati con il contesto delle tattiche MITRE ATT&CK. Secondo uno studio IDC Business Value, i team di sicurezza che usano Purple AI identificano le minacce il 63% più velocemente e le risolvono il 55% più rapidamente.
Usa Singularity™ Data Lake e Storyline™
Tutti i dati evento confluiscono nel Singularity™ Data Lake, normalizzati secondo l'Open Cybersecurity Schema Framework (OCSF). Le query sono fino a 100 volte più veloci rispetto ai SIEM legacy. La tecnologia Storyline ricostruisce poi l'intera catena d'attacco—collegando il furto iniziale di credenziali a ogni lateral move, escalation privilegi e accesso ai dati—così vedi l'intera timeline senza correlazione manuale.
Richiedi una demo SentinelOne per vedere Singularity AI SIEM e Singularity Identity in azione.
Ridurre il rischio di identità in tutta l'organizzazione
Rilevate e rispondete agli attacchi in tempo reale con soluzioni olistiche per Active Directory ed Entra ID.
Richiedi una demoVulnerabilità correlate
La broken authentication si interseca e abilita diverse altre classi di vulnerabilità:
- Broken Access Control (OWASP A01:2021): L'autenticazione verifica chi sei; il controllo accessi verifica cosa puoi fare. Una falla di autenticazione che concede accesso a un account valido eredita i permessi di quell'account, rendendo irrilevante il controllo accessi.
- Cryptographic Failures (OWASP A02:2021): Hashing password debole, archiviazione delle credenziali in chiaro e validazione impropria dei certificati sono failure crittografiche che abilitano direttamente la compromissione dell'autenticazione.
- Security Misconfiguration (OWASP A05:2021): Credenziali di default, impostazioni permissive di ri-registrazione MFA e timeout di sessione eccessivamente lunghi sono errori di configurazione che creano debolezze di autenticazione.
- Server-Side Request Forgery (SSRF): L'SSRF può essere combinato con il bypass dell'autenticazione per accedere a servizi interni che si fidano delle richieste provenienti dal server compromesso.
- Vulnerabilità di Injection: SQL injection contro le query di autenticazione può bypassare completamente la logica di login manipolando la query che valida le credenziali.
- Credential Theft (MITRE ATT&CK T1078 Valid Accounts): L'uso di account validi ottenuti tramite qualsiasi meccanismo di furto si mappa direttamente alla fase post-exploitation della broken authentication.
Affrontare la broken authentication non riduce solo il rischio identitario in isolamento. Policy più forti sulle credenziali, MFA obbligatoria e controlli di sessione rafforzati riducono la superficie di attacco condivisa da broken access control, failure crittografiche e misconfigurazioni.
CVE correlate
| ID CVE | Descrizione | Gravità | Prodotto interessato | Anno |
| Bypass autenticazione API in piattaforma di gestione dispositivi mobili consente accesso non autenticato a funzionalità riservate | ALTA | Ivanti Endpoint Manager Mobile | 2025 | |
| Assenza di autenticazione su endpoint di esecuzione codice consente iniezione remota di codice senza autenticazione | CRITICA | Langflow AI workflow platform | 2025 | |
| Assenza di autenticazione su interfaccia web di gestione consente accesso amministrativo remoto senza autenticazione | ALTA | Palo Alto PAN-OS | 2025 | |
| Autenticazione impropria nel componente SSLVPN consente agli attaccanti di dirottare sessioni VPN attive | ALTA | SonicWall SonicOS | 2024 | |
| Bypass autenticazione console admin consente ad attaccanti remoti non autenticati di ottenere pieno accesso amministrativo | CRITICA | Ivanti Cloud Services Appliance | 2024 | |
| Bypass autenticazione tramite percorso alternativo consente takeover completo non autenticato della piattaforma di supporto remoto | CRITICA | ConnectWise ScreenConnect | 2024 | |
| Divulgazione token di sessione dalla memoria consente agli attaccanti di dirottare sessioni autenticate e bypassare MFA (Citrix Bleed) | CRITICA | Citrix NetScaler ADC and Gateway | 2023 | |
| Bypass autenticazione su endpoint API critici porta a esecuzione remota di codice non autenticata su server CI/CD | CRITICA | JetBrains TeamCity | 2023 | |
| Bypass autenticazione API consente accesso non autenticato a endpoint riservati e dati sensibili | CRITICA | Ivanti Endpoint Manager Mobile | 2023 | |
| Bypass autenticazione SAML tramite libreria Apache xmlsec obsoleta consente esecuzione remota di codice senza autenticazione | CRITICA | Zoho ManageEngine (20+ prodotti) | 2022 | |
| Bypass autenticazione tramite percorso o canale alternativo consente ad attaccanti non autenticati di eseguire operazioni privilegiate | CRITICA | Fortinet FortiOS / FortiProxy / FortiSwitchManager | 2022 | |
| Assenza di autenticazione su API iControl REST consente ad attaccanti non autenticati di eseguire comandi di sistema arbitrari | CRITICA | F5 BIG-IP | 2022 | |
| Assenza di autenticazione sul componente OpenSSO Agent consente takeover completo del sistema via HTTP senza autenticazione | CRITICA | Oracle Access Manager (Fusion Middleware) | 2021 | |
| Vulnerabilità SSRF consente bypass pre-autenticazione ed esecuzione remota di codice senza autenticazione (ProxyLogon) | CRITICA | Microsoft Exchange Server | 2021 | |
| Bypass autenticazione tramite Windows File Share Browser e funzionalità Collaboration consente RCE non autenticata | CRITICA | Ivanti Connect Secure (Pulse Connect Secure) | 2021 | |
| Account hardcoded non documentato con password non modificabile concede pieno accesso admin via SSH e web UI senza autenticazione | CRITICA | Zyxel USG / ATP / VPN firmware | 2020 | |
| Assenza di autenticazione su API Experimental consente accesso remoto non autenticato ed esecuzione arbitraria di codice | CRITICA | Apache Airflow | 2020 | |
| Gestione impropria del case username consente agli attaccanti di bypassare la MFA su SSL VPN senza FortiToken | CRITICA | Fortinet FortiOS SSL VPN | 2020 | |
| Bypass autenticazione su endpoint wsdReadForm consente recupero e decrittazione di tutte le credenziali utente tramite chiave XOR hardcoded | MEDIA | eWON Firmware 12.2–13.0 | 2019 | |
| SQL injection su endpoint login bypassa completamente l'autenticazione, concedendo accesso non autenticato alla dashboard | CRITICA | E Learning Script 1.0 | 2019 | |
| SQL injection tramite parametro POST consente bypass autenticazione e accesso non autorizzato al database | ALTA | Simplejobscript | 2019 |
Conclusione
La broken authentication rimane uno dei percorsi di accesso iniziale più sfruttati nelle violazioni aziendali. Se i controlli di autenticazione falliscono, gli attaccanti possono trasformare password deboli, sessioni fragili, bypass MFA o controlli mancanti in una compromissione completa dell'account.
Riduci questo rischio con MFA resistente al phishing, policy moderne sulle credenziali, gestione sicura delle sessioni e visibilità a livello identità che mostra come vengono utilizzate le credenziali rubate.
Domande frequenti
La Broken Authentication è un fallimento nella fiducia dell'identità. Si verifica quando un'applicazione non è in grado di verificare in modo affidabile chi sia un utente o non può mantenere in modo sicuro tale identità dopo l'accesso.
Nella pratica, ciò include controlli deboli sulle credenziali, flussi di recupero fragili e difetti nella gestione delle sessioni che consentono agli attaccanti di agire come utenti legittimi.
Sì. OWASP ha incluso questa categoria sin dall'inizio della Top 10 nel 2004. I cambiamenti di denominazione sono significativi: il passaggio da "Broken Authentication" a "Identification and Authentication Failures" e poi "Authentication Failures" mostra che il rischio ora riguarda password, MFA, stato della sessione, federazione e percorsi di accesso alternativi.
Di solito sì. Il confine di fiducia spesso si trova su un accesso esposto a Internet, API, gateway VPN, account SaaS o interfaccia di gestione.
Gli attaccanti possono riutilizzare credenziali valide, abusare di percorsi di autenticazione esposti o dirottare sessioni, facendo sembrare l'attività un accesso normale piuttosto che un exploit tradizionale.
I sistemi a rischio più elevato sono quelli che prendono decisioni di identità per altri sistemi: web app, API, console cloud, servizi collegati SSO e appliance di perimetro.
Si applica una regola semplice: più ampiamente un account può muoversi dopo l'accesso, più dannosa diventa una falla di autenticazione.
Di solito combinano test e riutilizzo. I test rivelano blocchi deboli, difetti nei flussi di recupero, MFA o comportamento delle sessioni. Il riutilizzo applica credenziali rubate, token o CVE noti che funzionano già.
Ciò rende la scoperta relativamente poco costosa perché spesso gli attaccanti non hanno bisogno di un exploit nuovo per accedere.
I primi segnali sono solitamente pattern, non singoli avvisi. Indicatori comuni includono errori di accesso distribuiti, viaggi impossibili, attività di recupero insolite, richieste MFA ripetute e nuovi comportamenti di sessione dopo un accesso riuscito.
Il segnale chiave è una sequenza che attraversa eventi di autenticazione, sessione e privilegi.
È grave perché compromette il controllo che protegge tutti gli altri controlli. Quando l'autenticazione fallisce, un attaccante può ottenere accesso utente normale, privilegiato o fiducia federata verso sistemi a valle.
Questa maggiore superficie di attacco è il motivo per cui l'abuso di credenziali e i difetti di bypass dell'autenticazione sono legati a violazioni ad alto impatto.
Sì. Il fallimento dell'autenticazione è spesso il punto di ingresso, non lo stato finale. Una volta all'interno, gli attaccanti possono muoversi lateralmente, aumentare i privilegi, accedere a risorse cloud o persistere tramite canali di identità fidati.
Un singolo account compromesso può rapidamente diventare un problema di accesso a livello organizzativo.
Solo in parte. I test automatici sono utili per trovare blocchi deboli, difetti nei flussi di recupero, controlli mancanti e credenziali hard-coded. Sono meno efficaci quando gli attaccanti usano credenziali valide o token rubati, perché tali azioni possono sembrare legittime.
Per questo il monitoraggio delle identità e la correlazione tra livelli sono importanti.
I settori più esposti sono quelli in cui l'accesso autenticato porta direttamente a dati regolamentati, movimentazione di denaro, controllo amministrativo o operazioni critiche. Servizi finanziari, pubblica amministrazione, sanità, aziende cloud-intensive e operatori di infrastrutture rientrano in questo schema.
Il fattore di rischio condiviso è il valore e la portata di ciò che un account fidato può sbloccare.
