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 modulo 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 | Accesso non autorizzato come qualsiasi utente |
| Blind LDAP injection | Analisi differenziale carattere per carattere | Estrazione silenziosa di dati |
| Manipolazione del DN | Applicazione errata dell'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 bersaglio 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 radicate 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 immediata in quasi tutte le vulnerabilità LDAP injection è l'inserimento di dati controllati dall'utente direttamente nelle stringhe di filtro LDAP a livello applicativo. Storicamente, le librerie LDAP non hanno fornito il supporto integrato per query parametrizzate, richiedendo agli sviluppatori di seguire la guida manuale 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 errore, cioè la vulnerabilità nasce 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 viceversa, 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 resta 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 di bind.
- Uso diffuso di LDAP per l'autenticazione. Il ruolo di LDAP come backbone di autenticazione negli ambienti enterprise significa che l'injection sui 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. CVE-2023-4501 in OpenText Enterprise Server consentiva l'autenticazione con qualsiasi nome utente valido indipendentemente dalla correttezza della password, e poteva riuscire anche 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. CVE-2026-31828 in Parse Server consentiva a utenti autenticati a basso privilegio di ottenere l'accesso 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 DC/LDAP e il client 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. Moduli 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 i 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 della classe oggetto nulla
(*)(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 MITRE ATT&CK segue questa progressione:
- Bypassare il login usando un filtro sempre vero
- Estrarre credenziali di dominio tramite injection OR
- Creare account di dominio tramite ldapmodify (ATT&CK T1136.002)
- 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 con maggiore esposizione includono:
- Applicazioni web con autenticazione basata su LDAP (portali di login, sistemi SSO)
- Applicazioni enterprise 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à: i sistemi EHR e clinici basati su LDAP sono 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 resta una superficie di attacco rilevante per i sistemi enterprise 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 enterprise, agli strumenti di amministrazione database, alle piattaforme del settore energetico e backend open-source. Non si tratta di 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 enterprise e strumenti open-source.
CISA Red Team: Enterprise 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 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 resta la versione in uso enterprise 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 a Black Hat Europe, dimostrando l'estrazione dati carattere per carattere.
- Priorità massima OWASP. OWASP Top 10 2017 ha classificato 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 nel settore ICS energetico.
- Target piattaforme enterprise. ForgeRock OpenAM, OpenLDAP e OpenText Enterprise Server hanno dimostrato impatti enterprise 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 (abilitata di default). La regola ispeziona cookie di richiesta, nomi e valori di argomenti e corpi XML per pattern di metacaratteri dei filtri 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 l'escaping di *→
\2a, (→\28, )→\29, \→\5c, NUL→\00. Per i Distinguished Name (RFC 2253), esegui l'escaping di\, #, +, <, >, ,, ;, ", =e degli 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 la validazione tramite allowlist. Valida l'input rispetto ai pattern attesi prima di qualsiasi operazione LDAP. Rifiuta input che contengono metacaratteri non previsti nel campo. Normalizza l'input (canonica 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 privilegi minimi agli account di servizio LDAP. Limitane le operazioni e le sottostrutture della directory 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 fonti 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 le regole Alpha dello ZAP Marketplace e configura il targeting tecnologico per includere Protocol / LDAP per applicazioni con integrazione LDAP.
- OWASP ModSecurity CRS offre protezione a livello WAF tramite la regola CRS 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 di fuzzing pronta per la 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 coprono singoli livelli del problema. Un approccio di piattaforma li integra tra loro.
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
Diverse classi di vulnerabilità condividono questo pattern con l'LDAP injection:
- SQL Injection (CWE-89): L'analogo più vicino. Entrambe sfruttano input non sanificato 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 su data store XML-based.
- 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 neutralizzazione dei 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 errore 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 |
| LDAP injection in SuiteCRM consente ad attaccanti non autenticati di manipolare i filtri di ricerca, abilitando bypass dell'autenticazione o divulgazione di informazioni | Critica (9.8) | SalesAgility SuiteCRM <7.15.1 / 8.0.0–8.9.2 | 2026 | |
| 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 | Critica (9.8) | WeKan Project WeKan <8.19 | 2026 | |
| Parse Server interpola authData.id fornito dall'utente direttamente nei Distinguished Name LDAP e nei filtri di ricerca dei gruppi, abilitando escalation dei privilegi | Alta (8.8) | Parse Platform parse-server <8.6.26 | 2026 | |
| LDAP injection in WatchGuard Fireware OS consente ad attaccanti remoti non autenticati di recuperare informazioni sensibili da un server LDAP connesso | Alta (7.0) | WatchGuard Technologies Fireware OS 12.0–12.11.6 / 12.5–12.5.15 | 2026 | |
| 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 | Media (5.3) | Kanboard Kanboard ≤1.2.48 | 2026 | |
| Il modulo 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 | Critica (9.8) | Sismics Teedy 1.9–1.12 | 2025 | |
| LDAP injection in Apache HertzBeat consente a un attaccante autenticato di creare comandi che portano all'esecuzione arbitraria di script | Alta (8.8) | Apache Software Foundation Apache HertzBeat ≤1.7.2 | 2025 | |
| 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 | Alta (7.5) | PostgreSQL Global Development Group pgAdmin 4 <9.10 | 2025 | |
| Il modulo di autenticazione LDAP di GLPI può essere utilizzato per eseguire LDAP injection da parte di attaccanti non autenticati, risolto nella versione 10.0.12 | Alta (8.1) | GLPI Project GLPI 0.70–<10.0.12 | 2024 | |
| Utenti privilegiati possono iniettare stringhe di filtro LDAP nel provider opzionale di contatti LDAP di OX App Suite, accedendo a contenuti della directory fuori dalla gerarchia prevista | Alta (~8.0) | Open-Xchange OX App Suite <7.10.6 | 2024 | |
| NVIDIA DGX A100 BMC contiene una vulnerabilità di LDAP user injection sfruttabile da attaccanti non autenticati su rete adiacente, portando a divulgazione di informazioni | Media (~6.5) | NVIDIA DGX A100 BMC | 2024 | |
| La query di login LDAP di Mastodon è insicura, consentendo ad attaccanti autenticati di divulgare attributi arbitrari dalla directory LDAP | Alta (7.7) | Mastodon Mastodon 2.5.0–4.1.1 | 2023 | |
| 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 | Critica (9.8) | Apache Software Foundation Apache Derby ≤10.16.1.1 | 2022 | |
| La libsss_certmap di SSSD non sanifica i dati dei certificati usati nei filtri LDAP, consentendo a un attaccante autenticato di iniettare elementi di query LDAP e ottenere accesso non autorizzato | Alta (8.8) | Red Hat / SSSD Project SSSD | 2022 | |
| Apache ManifoldCF passa nomi utente e stringhe di dominio alle query di ricerca LDAP senza validazione nei connettori ActiveDirectory authority | Media (5.3) | Apache Software Foundation Apache ManifoldCF 0–2.23 | 2022 | |
| Thunderdome Planning Poker non esegue l'escaping dei nomi utente prima delle query LDAP quando l'autenticazione LDAP è abilitata, consentendo LDAP injection non autenticata | Critica (9.8) | Thunderdome Planning Poker <1.16.3 | 2021 | |
| La funzionalità ldapRegistry-3.0 di IBM Open Liberty contiene una vulnerabilità di LDAP injection | Alta (7.5) | IBM Open Liberty ldapRegistry-3.0 (v17.0.0.3–22.0.0.1) | 2021 | |
| ForgeRock OpenAM consente LDAP injection tramite il protocollo Webfinger, abilitando il recupero non autenticato carattere per carattere di hash password o token di sessione | Alta (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 query o a un'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
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.
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.
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 rete.
In molti casi, non sono necessarie credenziali valide per iniziare a sondare la manipolazione dei filtri.
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.
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.
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.
È 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.
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.
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 accorgerti dell'attività anche quando lo sfruttamento è già in corso.
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 basata su LDAP per utenti, sistemi e flussi amministrativi di alto valore.
