Che cos'è l'LDAP Injection? Come funziona e come fermarla

L'LDAP Injection manipola le query di directory tramite input utente non sanificato. Scopri come gli attaccanti bypassano l'autenticazione, estraggono dati e come fermarli.

Che cos'è l'LDAP Injection?

L'LDAP injection è un attacco lato server che sfrutta applicazioni web che costruiscono query Lightweight Directory Access Protocol a partire da input utente non sanificati. Quando l'applicazione non neutralizza correttamente i caratteri speciali prima di incorporarli nelle query LDAP, gli attaccanti possono manipolare tali query per bypassare l'autenticazione, estrarre dati sensibili dalla directory o modificare voci all'interno dell'albero LDAP.

Le directory LDAP sono al centro dell'infrastruttura di identità aziendale. Memorizzano credenziali utente, appartenenze ai gruppi, liste di controllo degli accessi, strutture organizzative e dettagli degli account di servizio. Un singolo attacco LDAP injection riuscito può esporre questo repository, concedendo a un attaccante le chiavi della tua infrastruttura di autenticazione.

MITRE classifica questa vulnerabilità come MITRE CWE-90: Impropria neutralizzazione di elementi speciali utilizzati in una query LDAP. OWASP la elenca sotto OWASP Injection e la categoria aggiornata OWASP Injection. La vulnerabilità condivide la causa principale con la  SQL injection, ma prende di mira un sistema fondamentalmente diverso e spesso più critico: il servizio di directory che governa chi può accedere a cosa in tutta l'organizzazione.

Comprendere come funziona l'LDAP injection richiede la conoscenza della sintassi delle query sfruttata dagli attaccanti.

Come funziona l'LDAP Injection?

I filtri di ricerca LDAP seguono una grammatica specifica definita nella  sintassi LDAP. I filtri utilizzano la notazione polacca (notazione prefissa), dove una semplice query di autenticazione appare così:

L'operatore & esegue un AND booleano. Le parentesi raggruppano le condizioni. Il carattere jolly * corrisponde a qualsiasi valore. Questi metacaratteri, insieme agli operatori di raggruppamento | (OR), ! (NOT), =, ~=, >=, <=, e (), costituiscono la superficie di injection.

Quando uno sviluppatore costruisce un filtro concatenando direttamente l'input utente nella stringa di query, quei metacaratteri diventano armi. Se un form di login inserisce il nome utente direttamente in un filtro come (&(uid=INPUT)(userPassword=HASH)), un attaccante che invia metacaratteri appositamente creati può cambiare completamente la logica del filtro: bypassando l'autenticazione, restituendo tutte le voci della directory o estraendo dati un carattere alla volta.

La tecnica specifica utilizzata da un attaccante dipende dal tipo di LDAP injection.

Tipi di LDAP Injection

L'LDAP injection assume diverse forme distinte, ciascuna mirata a un diverso aspetto dell'interazione delle applicazioni con la directory. Il tipo utilizzato da un attaccante dipende dal comportamento dell'applicazione, dal contesto della query e da ciò che l'attaccante può osservare nella risposta.

Tipo	Tecnica	Conseguenza
Injection del filtro di ricerca	Manipolazione del filtro tramite wildcard o OR	Enumerazione completa della directory
Bypass dell'autenticazione	Injection di filtro sempre vero	Login non autorizzato come qualsiasi utente
Blind LDAP injection	Analisi differenziale carattere per carattere	Estrazione silenziosa di dati
Manipolazione del DN	Applicazione errata del contesto di escaping ai campi DN	Injection in componenti di query non filtro

Injection del filtro di ricerca

Considera questo codice Java vulnerabile:

Se un attaccante invia user=*, il filtro risultante diventa (cn=*), che corrisponde a ogni oggetto nella directory con un attributo cn. L'applicazione restituisce l'intera directory utenti invece di un singolo record.

Bypass dell'autenticazione

I flussi di autenticazione LDAP rappresentano il target di injection a maggiore impatto. Un filtro di login vulnerabile come questo:

Questo filtro può essere bypassato iniettando )(uid=))(|(uid=* come nome utente. Il filtro risultante viene valutato come sempre vero, concedendo all'attaccante lo stato autenticato come primo utente nell'albero LDAP, spesso un account amministratore. La  guida ai test documenta questo come l'analogo diretto delle tecniche di bypass dell'autenticazione tramite SQL injection.

Blind LDAP injection

Quando le applicazioni non mostrano direttamente i risultati delle query, gli attaccanti utilizzano risposte differenziali per estrarre dati. Iniettando condizioni di filtro come (attribute=a*), (attribute=b*) e osservando se l'applicazione restituisce un risultato o una pagina vuota, estraggono i valori degli attributi carattere per carattere. La ricerca presentata nel  paper Black Hat ha dimostrato che i filtri lato client che limitano le informazioni visualizzate non impediscono le tecniche di blind injection.

Manipolazione del Distinguished Name

LDAP ha contesti di escaping distinti e confonderli crea vettori di injection. I filtri di ricerca richiedono escaping secondo RFC 4515 (*→\2a, (→\28, )→\29). I Distinguished Name (DN) richiedono escaping secondo RFC 2253 (\, #, +, <, >, ,, ;, ", =). Applicare il contesto di escaping sbagliato al campo sbagliato lascia l'applicazione vulnerabile anche quando si pensa di aver risolto il problema.

Questi tipi di attacco condividono cause profonde comuni che vanno oltre la sintassi.

Cause dell'LDAP Injection

Le vulnerabilità LDAP injection derivano da una combinazione di pratiche di codifica, limitazioni delle librerie e configurazioni errate dell'infrastruttura. Ogni causa principale crea un percorso indipendente verso lo sfruttamento.

• Concatenazione diretta di stringhe. La causa prossima in quasi tutte le vulnerabilità LDAP injection è l'inserimento di dati controllati dall'utente direttamente nelle stringhe di filtro LDAP a livello applicativo. Le librerie LDAP storicamente non hanno supportato query parametrizzate integrate, richiedendo agli sviluppatori di seguire  linee guida manuali per la costruzione sicura delle query. Esistono interfacce parametrizzate ma richiedono un'adozione deliberata.
• Gestione errata dei caratteri speciali. Le applicazioni che tentano la validazione dell'input spesso implementano denylist incomplete che non bloccano tutti i caratteri pericolosi. Una denylist che blocca * e ( ma non ) o byte NUL lascia comunque una falla sfruttabile.  MITRE CWE-90 identifica l'LDAP injection come risultante da questo fallimento, cioè la vulnerabilità di injection deriva direttamente dalla gestione errata dei caratteri speciali.
• Confusione nel contesto di escaping. La  cheat sheet LDAP documenta che applicare l'escaping dei filtri di ricerca ai campi DN, o l'escaping DN ai campi filtro di ricerca, crea vettori di injection tramite selezione errata del contesto. Se gli sviluppatori sanno che devono eseguire l'escaping ma scelgono la funzione sbagliata, l'applicazione rimane vulnerabile.
• Configurazioni di bind anonimo e non autenticato. I server LDAP configurati per consentire il bind anonimo permettono agli attaccanti di bypassare completamente l'autenticazione bind.
• Uso diffuso di LDAP per l'autenticazione. Il ruolo di LDAP come backbone di autenticazione negli ambienti aziendali significa che l'injection contro i flussi di login produce l'impatto più grave: accesso autenticato a risorse aziendali. La superficie di attacco è aziendale per progettazione architetturale.

Queste cause si combinano per creare rischi che vanno ben oltre una singola query compromessa.

Impatto e rischio dell'LDAP Injection

Gli attacchi LDAP injection possono produrre diverse categorie di impatto aziendale, ciascuna con gravità crescente.

Bypass dell'autenticazione

Un'injection di filtro sempre vero concede accesso autenticato immediato. La CVE-2023-4501 in OpenText Enterprise Server consentiva l'autenticazione con qualsiasi nome utente valido indipendentemente dalla correttezza della password, e poteva anche riuscire con un nome utente non valido e qualsiasi password. Questo ha interessato ambienti di sviluppo e runtime COBOL aziendali distribuiti nei servizi finanziari, assicurativi e governativi.

Esfiltrazione di dati sensibili

Le directory LDAP contengono credenziali utente, hash delle password, indirizzi email, gerarchie organizzative, appartenenze ai gruppi, ACL, account computer e  security identifier. Un  avviso CISA ha documentato una singola query LDAP che recuperava informazioni su utenti, computer, gruppi, ACL, OU e GPO da una directory aziendale.

Escalation dei privilegi

Un'injection riuscita può concedere permessi a query non autorizzate e abilitare la modifica di contenuti all'interno dell'albero LDAP. La CVE-2026-31828 in Parse Server consentiva a utenti autenticati a basso privilegio di passare a qualsiasi gruppo ristretto tramite LDAP filter injection.

Denial of Service

CVE-2025-12764 (pgAdmin) ha dimostrato l'uso dell'LDAP injection per costringere il server e il client DC/LDAP a processare una quantità insolita di dati, causando un denial of service contro l'infrastruttura di directory con conseguenti fallimenti di autenticazione a cascata.

Abilitazione del movimento laterale

L'enumerazione LDAP alimenta la ricognizione Active Directory. L'avviso red team CISA ha documentato che i dati LDAP hanno permesso la mappatura di utenti, computer, gruppi, ACL, OU e GPO, tutti utilizzati come input per la  pianificazione del movimento laterale. L'azienda valutata non aveva alcuna visibilità su questa attività.

OWASP valuta la sfruttabilità dell'injection a 3 (Facile) e l'impatto tecnico a 3 (Grave) nel suo  framework OWASP. L'LDAP injection comporta anche conseguenze dirette di conformità:  PCI DSS 6.5.1 nomina esplicitamente l'LDAP injection insieme a SQL e XPath injection come target di valutazione obbligatorio.

Comprendere l'impatto ti aiuta a dare priorità alle difese, ma è anche necessario sapere esattamente come gli attaccanti individuano e sfruttano queste falle.

Come gli attaccanti sfruttano l'LDAP Injection

Gli attaccanti seguono una metodologia strutturata per individuare e sfruttare le vulnerabilità LDAP injection, passando dalla ricognizione all'estrazione completa delle credenziali.

Fase 1: Identificare i punti di ingresso integrati con LDAP

L'attaccante identifica le funzionalità applicative che probabilmente interrogano un backend LDAP. Secondo il  blog SANS LDAP, LDAP può essere utilizzato per la gestione, l'autenticazione e l'interrogazione di oggetti da un database di directory. Form di login, pagine di ricerca utenti, flussi di reset password, ricerche nella directory aziendale e portali VPN sono tutte superfici candidate.

Fase 2: Sondare i punti di injection

L' OWASP LDAP testing istruisce i tester a inserire caratteri (, |, &, * per verificare risposte differenziali. Messaggi di errore, set di risultati vuoti o cambiamenti nel comportamento dell'applicazione confermano un parametro vulnerabile.

Fase 3: Inferire la struttura del filtro

Senza il codice sorgente, gli attaccanti deducono la struttura del filtro LDAP tramite fuzzing. SANS osserva: "È improbabile durante un penetration test avere il codice sorgente per vedere queste istruzioni. In queste situazioni, potrebbero essere necessari fuzzing e ricognizione."

Fase 4: Creare payload di injection

I payload comuni includono:

• Injection con wildcard (*) per recuperare tutte le voci della directory
• Filtri sempre veri ()(uid=))(|(uid=*) per bypassare l'autenticazione
• Injection di attributi tramite OR ()(department=it)(|(cn=) per raccogliere credenziali su più attributi
• Terminazione con oggetto class nullo (*)(objectClass=*))(& (objectClass=void) per stabilire un oracolo booleano affidabile per l'estrazione cieca

Il payload specifico dipende dalla struttura del filtro che l'attaccante ha dedotto durante la ricognizione.

Fase 5: Escalation tramite catene di attacco

Una tipica catena di attacco documentata da OWASP e fonti MITRE ATT&CK segue questa progressione:

1. Bypassare il login usando un filtro sempre vero
2. Estrarre credenziali di dominio tramite injection OR
3. Creare account di dominio tramite ldapmodify (ATT&CK T1136.002)
4. Dump di NTDS.dit per cracking offline delle credenziali (ATT&CK T1003.003)

Il blind LDAP injection abilita una catena parallela in cui gli attaccanti enumerano gli attributi dello schema usando probe (attribute=*) ed estraggono i valori carattere per carattere, inclusi hash delle password, appartenenze ai gruppi e security identifier.

Questi pattern di sfruttamento colpiscono una vasta gamma di organizzazioni e tipologie applicative.

Chi è colpito dall'LDAP Injection?

Qualsiasi organizzazione che si affida all'autenticazione basata su LDAP è strutturalmente esposta a questa vulnerabilità. OWASP osserva che le vulnerabilità di injection sono "molto diffuse soprattutto nel  codice legacy."

Tipologie applicative a maggiore esposizione includono:

• Applicazioni web con autenticazione basata su LDAP (portali di login, sistemi SSO)
• Applicazioni aziendali legacy che utilizzano query LDAP concatenate come stringhe
• Portali self-service di reset password e directory dipendenti
• Gateway VPN e portali di accesso remoto
• Piattaforme di gestione di sistemi di controllo industriale
• Applicazioni desktop (OWASP Desktop App Security Top 10 elenca l'LDAP injection sotto  DA1 Injections)

Settori con rischio concentrato includono:

• Sanità: Sistemi EHR e clinici basati su LDAP soggetti a enforcement HIPAA per vulnerabilità non patchate, con HHS che documenta  dati di breach HHS in grandi violazioni tra il 2018 e il 2022.
• Servizi finanziari: L'injection rimane una superficie di attacco rilevante per i sistemi aziendali legati all'identità in questo settore.
• Governo e infrastrutture critiche: CISA ha documentato sfruttamento attivo in ambienti governativi e piattaforme ICS del settore energetico.
• Software e tecnologia: Backend open-source, strumenti database e piattaforme di sviluppo continuano a produrre nuove CVE di LDAP injection.

L'LDAP injection colpisce una vasta gamma di software, dagli ambienti COBOL aziendali agli strumenti di amministrazione database, piattaforme del settore energetico e backend open-source. Questi non sono rischi ipotetici; incidenti recenti li confermano.

Esempi reali di LDAP Injection

I seguenti casi illustrano come l'LDAP injection si manifesti su reti governative, piattaforme aziendali e strumenti open-source.

CISA Red Team: Azienda senza visibilità LDAP (2024)

Una  valutazione CISA ha rilevato che l'azienda valutata "non aveva monitoraggio per traffico LDAP anomalo." Il team ha interrogato LDAPS per raccogliere informazioni su utenti, computer, gruppi, ACL, OU e GPO. CISA ha dichiarato esplicitamente che un utente non privilegiato che interroga LDAP da un host di dominio Linux "avrebbe dovuto allertare i difensori di rete."

OpenText Enterprise Server: Bypass completo dell'autenticazione (CVE-2023-4501)

Questa vulnerabilità consentiva l'autenticazione con qualsiasi nome utente valido indipendentemente dalla password, e poteva riuscire anche con un nome utente non valido. Ha interessato ambienti di sviluppo e runtime COBOL aziendali distribuiti nei servizi finanziari, assicurativi e nell'integrazione mainframe governativa.

Ivanti EPMM: Attori minacciosi scaricano credenziali LDAP (2025)

Dopo la pubblicazione di una proof of concept a maggio 2025, attori minacciosi hanno ottenuto accesso a un server Ivanti EPMM e  scaricato credenziali LDAP. CISA ha aggiunto le vulnerabilità sottostanti al catalogo KEV il 19 maggio 2025.

Redash: LDAP Injection che abilita Password Spraying (CVE-2020-36144)

GitHub Security Lab ha documentato che il campo email nell'autenticazione LDAP di Redash formattava una stringa di query filtro LDAP senza escaping, consentendo a un attaccante non autenticato di forzare tutte le password degli utenti con una singola richiesta.

Questi incidenti coprono decenni di sfide di sicurezza LDAP.

Timeline e storia dell'LDAP Injection

L'LDAP injection è una classe di vulnerabilità nota da oltre vent'anni, con classificazione formale e disclosure CVE continue dalla fine degli anni '90 a oggi.

• Origini del protocollo. X.500 Directory Access Protocol (DAP) è stato sviluppato da ITU-T. LDAP v1 è apparso in RFC 1487, v2 in RFC 1777 e v3 in RFC 2251, che rimane la versione in uso aziendale oggi.
• Primo problema documentato. CVE-1999-0895 ha documentato un primo problema di sicurezza LDAP authentication in Checkpoint FireWall-1 V4.0.
• Classificazione formale. OWASP ha documentato formalmente l'LDAP injection come classe di attacco distinta. L'OWASP Top 10 del 2007 l'ha mappata sotto A2, Injection Flaws.
• Ricerca su blind injection. Alonso et al. hanno presentato una  ricerca sistematica sulla blind LDAP injection a Black Hat Europe, dimostrando l'estrazione dati carattere per carattere.
• Priorità massima OWASP. OWASP Top 10 2017 ha classificato l'Injection come A1, il rischio numero uno per le applicazioni web, nominando esplicitamente l'LDAP injection.
• Target ICS. CVE-2018-14805 (ABB eSOMS) ha portato l'LDAP injection nello spazio ICS del settore energetico.
• Target piattaforme aziendali. ForgeRock OpenAM, OpenLDAP e OpenText Enterprise Server hanno dimostrato impatti aziendali continui.
• Disclosure recenti. Nuove CVE negli ultimi anni hanno interessato Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax e pgAdmin.

Nuove CVE continuano ad apparire, rendendo il monitoraggio continuo un requisito pratico.

Come rilevare l'LDAP Injection

È necessario un monitoraggio stratificato su livelli applicativo, directory e di rete.

Indicatori a livello applicativo

Monitora i campi di input utente per metacaratteri LDAP: *, (, ), \ e byte NUL nei parametri di autenticazione e ricerca. Osserva set di risultati LDAP insolitamente grandi che suggeriscono injection con wildcard che restituisce tutte le voci della directory. Un successo di autenticazione immediatamente dopo una query malformata segnala un pattern di bypass dell'autenticazione.

Indicatori a livello server LDAP

Cerca strutture di filtro contenenti sequenze )( o |(, che indicano manipolazione di gruppi di filtri. Query che restituiscono tutte le voci tramite (objectClass=*) o (cn=*) suggeriscono enumerazione tramite wildcard. Bind anonimo seguito da operazioni di ricerca estese indica tentativi di ricognizione non autenticata.

Monitoraggio SIEM e dei log eventi

Per ambienti Active Directory, due Event ID di Windows sono critici:

• Event ID 4662: Operazioni eseguite su oggetti AD. Monitora per azioni Write Property, Control Access, DELETE, WRITE_DAC e WRITE_OWNER.
• Event ID 1644: Query LDAP costose o inefficienti, che spesso sono prodotte da tentativi di injection.

Secondo la  guida NCC Group: "Cerca filtri di ricerca insoliti nei log. Gli attaccanti spesso usano filtri specifici per enumerare utenti, gruppi e computer."

Pattern di correlazione comportamentale

Correla tra fonti dati per individuare campagne di injection:

• Alto volume di query LDAP da un singolo IP sorgente (tooling di injection)
• Enumerazione sequenziale di attributi: uid=a*, uid=b* (estrazione tramite blind injection)
• Password fallita seguita da successo di login immediato (conferma di bypass dell'autenticazione)
• Host di dominio Linux non privilegiato che esegue query LDAP massive (esattamente il pattern documentato da CISA come non rilevato)

Correlare questi segnali tra fonti offre una visione più chiara delle campagne di injection attive rispetto a qualsiasi singolo indicatore.

Monitoraggio a livello WAF

OWASP ModSecurity Core Rule Set include la regola ID 921200 in REQUEST-921-PROTOCOL-ATTACK.conf, che prende di mira l'LDAP injection con severità CRITICAL e Paranoia Level 1 (abilitato di default). La regola ispeziona cookie di richiesta, nomi e valori di argomenti e corpi XML per pattern di metacaratteri filtro LDAP.

Individuare attività sospette non è sufficiente senza adeguati controlli di prevenzione.

Come prevenire l'LDAP Injection

La prevenzione richiede un approccio defense-in-depth che coinvolga codice, configurazione e infrastruttura.

Difese a livello di codice

• Usa query LDAP parametrizzate. La difesa più efficace è passare l'input utente come parametro invece di concatenarlo nelle stringhe di filtro:

• Applica escaping appropriato al contesto. Usa la funzione di escaping corretta per il contesto LDAP corretto. Per i filtri di ricerca (RFC 4515), esegui escaping di *→\2a, (→\28, )→\29, \→\5c, NUL→\00. Per i Distinguished Name (RFC 2253), esegui escaping di \, #, +, <, >, ,, ;, ", = e spazi iniziali/finali.

Implementazioni specifiche per linguaggio includono:

Linguaggio	Escaping filtro di ricerca	Escaping DN
Java	OWASP ESAPI encodeForLDAP()	OWASP ESAPI encodeForDN()
.NET	Encoder.LdapFilterEncode()	Encoder.LdapDistinguishedNameEncode()
Perl	Net::LDAP::Util::escape_filter_value()	Manuale secondo RFC 2253

• Implementa validazione allowlist. Valida l'input rispetto ai pattern attesi prima di qualsiasi operazione LDAP. Rifiuta input contenenti metacaratteri non previsti nel campo. Normalizza l'input (canonicalizzazione Unicode) prima della validazione secondo la  cheat sheet OWASP.

Rafforzamento dell'infrastruttura

• Disabilita il bind anonimo e non autenticato. Questa singola azione elimina la causa principale di molte vulnerabilità critiche.
• Usa LDAPS (porta 636). Disabilita LDAP in chiaro (porta 389) secondo  NIST SP 1800-16.
• Applica ACL a privilegio minimo agli account di servizio LDAP. Limitane le operazioni e le sottodirectory solo a quelle necessarie.
• Segmenta l'infrastruttura LDAP dall'accesso di rete generale secondo  NIST SP 1800-18B.

Questi controlli riducono la superficie di attacco disponibile a un attaccante che raggiunge la tua infrastruttura LDAP.

Integrazione nella pipeline CI/CD

Integra analisi statica (SAST) e dinamica (DAST) nella pipeline di sviluppo. L' OWASP Top 10 raccomanda di includere strumenti SAST, DAST e IAST per identificare  vulnerabilità di injection prima del rilascio in produzione. La modalità taint analysis di Semgrep può tracciare input non attendibili dalle sorgenti ai sink senza sanificazione usando regole personalizzate mirate alla costruzione di query LDAP.

Queste misure di prevenzione funzionano meglio se supportate dagli strumenti giusti.

Strumenti per rilevamento e prevenzione

Una difesa efficace contro l'LDAP injection richiede una combinazione di strumenti di scansione, monitoraggio e protezione runtime.

• OWASP ZAP fornisce scansione attiva per LDAP injection tramite  ZAP Alert 40015 (CWE-90, WASC-29). Installa tramite Alpha scan rules del Marketplace ZAP e configura il targeting tecnologico per includere Protocol / LDAP per applicazioni con integrazione LDAP.
• OWASP ModSecurity CRS offre protezione a livello WAF tramite  CRS Rule 921200, attiva di default a Paranoia Level 1. La regola ispeziona cookie, argomenti e payload XML per firme di manipolazione dei filtri LDAP. I payload di regression test CRS da  CRS Issue 276 forniscono una wordlist pronta per il fuzzing di validazione WAF.
• Semgrep supporta l'analisi statica taint tramite regole mode: taint che tracciano dati non attendibili da  fonti di input a sink di query LDAP, segnalando i percorsi di injection prima che il codice raggiunga la produzione.
• Piattaforme SIEM con regole di identificazione personalizzate possono monitorare Windows Event ID 4662 e 1644, correlare pattern anomali di query LDAP e allertare su indicatori comportamentali come enumerazione sequenziale di attributi o query massive da host non privilegiati.

Questi strumenti affrontano singoli livelli del problema. Un approccio di piattaforma li integra tra loro.

Vulnerabilità correlate

Diverse classi di vulnerabilità condividono questo pattern con l'LDAP injection:

• SQL Injection (CWE-89): L'analogo più vicino. Entrambe sfruttano input non sanificati nei linguaggi di query e il bypass dell'autenticazione è ottenibile tramite tecniche simili. Sintassi e sistemi target differiscono significativamente.
• OS Command Injection (CWE-78): Condivide lo stesso Software Fault Pattern (SFP24, "Tainted input to command") con CWE-90 secondo MITRE. Prende di mira il sistema operativo host invece dei servizi di directory.
• XPath Injection (CWE-643): L' OWASP LDAP testing raggruppa esplicitamente XPath injection insieme a LDAP injection come tecniche analoghe di bypass dell'autenticazione che prendono di mira archivi dati basati su XML.
• Impropria neutralizzazione di elementi speciali (CWE-77): La debolezza padre di CWE-90 nella gerarchia MITRE. Tutti i tipi di injection discendono da questo fallimento generalizzato di neutralizzare caratteri significativi per l'interprete.
• Impropria codifica o escaping dell'output (CWE-116): Documenta la catena diretta dal fallimento dell'escaping all'injection. CVE-2021-41232 dimostra la catena CWE-116 → CWE-90 dove un fallimento di escaping in un'applicazione Go ha abilitato direttamente l'LDAP injection.
• Impropria validazione dell'input (CWE-20): La causa principale quando le applicazioni non validano il formato dell'input prima di costruire query LDAP.

Rivedere questi tipi di debolezza correlati aiuta ad applicare gli stessi principi difensivi su tutto il codice, non solo nei percorsi specifici LDAP.

CVE correlate

ID CVE	Descrizione	Gravità	Prodotto interessato	Anno
CVE-2026-33289	LDAP injection in SuiteCRM consente ad attaccanti non autenticati di manipolare i filtri di ricerca, abilitando bypass dell'autenticazione o divulgazione di informazioni	Critico (9.8)	SalesAgility SuiteCRM <7.15.1 / 8.0.0–8.9.2	2026
CVE-2026-25560	WeKan incorpora nomi utente non sanificati nei filtri di ricerca LDAP e nei valori DN, consentendo ad attaccanti remoti non autenticati di manipolare le query LDAP durante l'autenticazione	Critico (9.8)	WeKan Project WeKan <8.19	2026
CVE-2026-31828	Parse Server interpola authData.id fornito dall'utente direttamente nei Distinguished Name LDAP e nei filtri di ricerca dei gruppi, abilitando escalation dei privilegi	Alto (8.8)	Parse Platform parse-server <8.6.26	2026
CVE-2026-1498	LDAP injection in WatchGuard Fireware OS consente ad attaccanti remoti non autenticati di recuperare informazioni sensibili da un server LDAP connesso	Alto (7.0)	WatchGuard Technologies Fireware OS 12.0–12.11.6 / 12.5–12.5.15	2026
CVE-2026-21880	Kanboard sostituisce input utente non sanificato direttamente nei filtri di ricerca LDAP, consentendo ad attaccanti non autenticati di enumerare utenti LDAP e scoprire attributi sensibili	Medio (5.3)	Kanboard Kanboard ≤1.2.48	2026
CVE-2024-54852	Il form di login abilitato LDAP di Teedy consente l'LDAP injection non autenticata tramite il campo nome utente, permettendo la creazione arbitraria di account e password spraying	Critico (9.8)	Sismics Teedy 1.9–1.12	2025
CVE-2025-48208	LDAP injection in Apache HertzBeat consente a un attaccante autenticato di creare comandi che portano all'esecuzione arbitraria di script	Alto (8.8)	Apache Software Foundation Apache HertzBeat ≤1.7.2	2025
CVE-2025-12764	L'iniezione di caratteri speciali LDAP nel campo nome utente di pgAdmin 4 causa l'elaborazione di dati eccessivi da parte del server e client LDAP, risultando in denial of service	Alto (7.5)	PostgreSQL Global Development Group pgAdmin 4 <9.10	2025
CVE-2023-51446	Il form di autenticazione LDAP di GLPI può essere utilizzato per eseguire LDAP injection da parte di attaccanti non autenticati, risolto nella versione 10.0.12	Alto (8.1)	GLPI Project GLPI 0.70–<10.0.12	2024
CVE-2023-29050	Utenti privilegiati possono iniettare stringhe filtro LDAP nel provider opzionale di contatti LDAP di OX App Suite, accedendo a contenuti della directory fuori dalla gerarchia prevista	Alto (~8.0)	Open-Xchange OX App Suite <7.10.6	2024
CVE-2023-31025	NVIDIA DGX A100 BMC contiene una vulnerabilità di LDAP user injection sfruttabile da attaccanti non autenticati su rete adiacente, portando a divulgazione di informazioni	Medio (~6.5)	NVIDIA DGX A100 BMC	2024
CVE-2023-28853	La query di login LDAP di Mastodon è insicura, consentendo ad attaccanti autenticati di divulgare attributi arbitrari dalla directory LDAP	Alto (7.7)	Mastodon Mastodon 2.5.0–4.1.1	2023
CVE-2022-46337	Un nome utente appositamente creato bypassa l'autenticazione LDAP in Apache Derby, potenzialmente consentendo esaurimento disco, esecuzione di malware e accesso non autorizzato al database	Critico (9.8)	Apache Software Foundation Apache Derby ≤10.16.1.1	2022
CVE-2022-4254	libsss_certmap di SSSD non sanifica i dati del certificato usati nei filtri LDAP, consentendo a un attaccante autenticato di iniettare elementi di query LDAP e ottenere accesso non autorizzato	Alto (8.8)	Red Hat / SSSD Project SSSD	2022
CVE-2022-45910	Apache ManifoldCF passa nomi utente e stringhe di dominio alle query di ricerca LDAP senza validazione nei connettori ActiveDirectory authority	Medio (5.3)	Apache Software Foundation Apache ManifoldCF 0–2.23	2022
CVE-2021-41232	Thunderdome Planning Poker non esegue escaping dei nomi utente prima delle query LDAP quando l'autenticazione LDAP è abilitata, consentendo LDAP injection non autenticata	Critico (9.8)	Thunderdome Planning Poker <1.16.3	2021
CVE-2021-39031	La funzionalità ldapRegistry-3.0 di IBM Open Liberty contiene una vulnerabilità di LDAP injection	Alto (7.5)	IBM Open Liberty ldapRegistry-3.0 (v17.0.0.3–22.0.0.1)	2021
CVE-2021-29156	ForgeRock OpenAM consente LDAP injection tramite il protocollo Webfinger, abilitando il recupero carattere per carattere di hash password o token di sessione da parte di attaccanti non autenticati	Alto (stima)	ForgeRock OpenAM <13.5.1	2021

Conclusione

L'LDAP injection offre agli attaccanti un modo per trasformare input non attendibili in controllo sui sistemi di directory da cui dipende il tuo ambiente per autenticazione e accesso. Per te, ciò significa che il rischio raramente si limita a una sola query o applicazione. 

Se costruisci le query in modo sicuro, esegui l'escaping dei valori nel contesto corretto, limiti i permessi di bind e monitori attentamente l'attività LDAP, riduci sia l'esposizione sia lo spazio di manovra degli attaccanti.

Domande frequenti

Che cos'è una vulnerabilità di LDAP Injection?

L'LDAP injection è una vulnerabilità di gestione dell'input in software che costruisce query LDAP da dati non attendibili. Un attaccante può modificare il modo in cui la directory interpreta una query, trasformando un controllo di login in una condizione sempre vera, ampliando una ricerca ristretta in una enumerazione completa della directory o abusando delle operazioni di aggiunta e modifica all'interno dell'albero LDAP.

L'LDAP Injection fa parte dell'OWASP Top 10?

Sì. L'LDAP injection rientra nella categoria più ampia delle Injection di OWASP, piuttosto che essere una voce autonoma nella Top 10. In pratica, ciò significa che dovresti revisionare il codice che utilizza LDAP con la stessa attenzione che applichi alla SQL injection, poiché entrambe le vulnerabilità derivano da input non attendibili che raggiungono un interprete.

L'LDAP Injection può essere sfruttata da remoto?

Sì. Se il tuo modulo di login esposto sul web, pagina di ricerca, portale o interfaccia di gestione passa input utente a un backend LDAP, un attaccante può iniziare lo sfruttamento tramite la rete. 

In molti casi, non è necessario disporre di credenziali valide per iniziare a sondare la manipolazione dei filtri.

Quali tipi di applicazioni sono più vulnerabili all'LDAP Injection?

Le applicazioni a rischio più elevato sono quelle che utilizzano LDAP per decisioni di identità: portali di login e sistemi SSO, strumenti di reset password e ricerca directory, gateway VPN e portali di accesso remoto, e applicazioni aziendali legacy che costruiscono query LDAP tramite concatenazione di stringhe.

Come scoprono tipicamente gli attaccanti l'LDAP Injection?

Gli attaccanti di solito iniziano con semplici sonde. Inseriscono metacaratteri LDAP come (, |, & e *, quindi osservano risposte modificate, errori o conteggi di risultati insoliti. 

Una volta dedotta la struttura del filtro, passano a payload di estrazione wildcard, basati su OR o blind.

Quali sono i primi segnali di sfruttamento di LDAP injection?

I primi segnali includono spesso metacaratteri nei campi di autenticazione o ricerca, insiemi di risultati LDAP insolitamente ampi, pattern )( o |( nei filtri, un login fallito seguito immediatamente da un successo e query LDAP massive da un host non privilegiato.

Quanto è grave l'LDAP Injection rispetto ad altre vulnerabilità?

È grave perché LDAP spesso controlla autenticazione e autorizzazione oltre una singola applicazione. Un'injection riuscita può esporre dati di directory, bypassare i controlli di login o alimentare la lateral movement nell'ambiente. 

Questa portata rende l'impatto aziendale più ampio rispetto a molte vulnerabilità limitate alle sole applicazioni.

L'LDAP Injection può portare al compromesso completo del sistema?

Sì, soprattutto come fase iniziale in una catena di attacco all'identità più ampia. Un attaccante può passare dal bypass del login o enumerazione della directory al furto di credenziali, creazione di account, dumping di NTDS.dit e accesso persistente tramite account validi. 

L'injection è spesso il punto di ingresso, non l'obiettivo finale.

L'LDAP Injection è facile da rilevare con strumenti automatici?

Gli strumenti aiutano, ma non risolvono il problema da soli. Scanner e regole WAF possono individuare i casi più evidenti, mentre le injection blind e la scarsa registrazione LDAP restano più difficili da rilevare. 

Se manca visibilità sul traffico LDAP e sul comportamento delle query, puoi non rilevare l'attività anche quando lo sfruttamento è già in corso.

Quali settori sono più a rischio di LDAP injection?

I settori con dipendenza centralizzata dall'identità presentano la maggiore concentrazione di rischio. L'articolo evidenzia sanità, servizi finanziari, pubblica amministrazione, infrastrutture critiche e piattaforme software. 

Ciò che li accomuna è la dipendenza dall'autenticazione supportata da LDAP per utenti, sistemi e flussi amministrativi di alto valore.