Che cos'è l'iniezione LDAP? Come funziona e come bloccarla

Che cos'è l'iniezione LDAP?

L'iniezione LDAP è un attacco lato server che sfrutta le applicazioni web che costruiscono query LDAP (Lightweight Directory Access Protocol) a partire da input utente non sanitizzati. Se la vostra applicazione non neutralizza correttamente i caratteri speciali prima di inserirli nelle query LDAP, gli attaccanti possono manipolare le query per aggirare l'autenticazione, estrarre dati sensibili dalla directory o modificare le voci nell'albero LDAP.

Le directory LDAP sono al centro dell'infrastruttura di identità aziendale. Custodiscono credenziali degli utenti, appartenenze ai gruppi, liste di controllo degli accessi, strutture organizzative e dettagli dei service account. Un solo attacco di iniezione LDAP riuscito può esporre questo archivio e consegnare a un attaccante le chiavi della vostra infrastruttura di autenticazione.

MITRE classifica questa vulnerabilità come MITRE CWE-90: neutralizzazione inadeguata degli elementi speciali utilizzati in una query LDAP. OWASP la include in OWASP Injection e nella categoria OWASP Injection aggiornata. La vulnerabilità ha la stessa causa alla base della SQL injection, ma colpisce un sistema fondamentalmente diverso e spesso con conseguenze più gravi: il servizio di directory che governa gli accessi in tutta la vostra organizzazione.

Per capire come funziona l'iniezione LDAP, occorre conoscere la sintassi delle query sfruttata dagli attaccanti.

Come funziona l'iniezione LDAP?

I filtri di ricerca LDAP seguono una grammatica specifica definita nella sintassi LDAP. I filtri usano la notazione polacca (notazione prefissa). Una semplice query di autenticazione si presenta così:

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

Quando uno sviluppatore costruisce un filtro concatenando direttamente l'input utente alla stringa della query, quei metacaratteri diventano armi. Se un modulo di accesso inserisce il nome utente direttamente in un filtro come (&(uid=INPUT)(userPassword=HASH)), un attaccante può inviare metacaratteri appositamente costruiti e cambiare completamente la logica del filtro: aggirare l'autenticazione, ottenere tutte le voci della directory o estrarre i dati un carattere alla volta.

La tecnica usata dall'attaccante dipende dal tipo di iniezione LDAP.

Tipi di iniezione LDAP

L'iniezione LDAP assume diverse forme, ciascuna rivolta a un aspetto dell'interazione tra applicazioni e directory. La scelta dipende dal comportamento dell'applicazione, dal contesto della query e da ciò che l'attaccante può osservare nella risposta.

Iniezione nei filtri di ricerca

Considerate questo codice Java vulnerabile:

Se un attaccante invia user=*, il filtro risultante diventa (cn=*), che corrisponde a ogni oggetto della directory con un attributo cn. La vostra applicazione restituisce l'intera directory degli utenti anziché un singolo record.

Aggiramento dell'autenticazione

I flussi di autenticazione LDAP sono il bersaglio di iniezione dalle conseguenze più gravi. Considerate un filtro di accesso vulnerabile come questo:

Questo filtro può essere aggirato inserendo )(uid=))(|(uid=* come nome utente. Il filtro risultante risulta sempre vero e concede all'attaccante l'accesso autenticato come primo utente nell'albero LDAP, spesso un account amministratore. Il guida ai test documenta questa tecnica come l'equivalente diretto delle tecniche di bypass dell'autenticazione tramite SQL injection.

LDAP injection blind

Quando le applicazioni non mostrano direttamente i risultati delle query, gli aggressori usano le differenze nelle risposte per estrarre dati. Inseriscono condizioni nei filtri come (attribute=a*), (attribute=b*) e osservano se l'applicazione restituisce un risultato o una pagina vuota. Così estraggono i valori degli attributi carattere per carattere. Una ricerca presentata nel paper di Black Hat ha dimostrato che i filtri lato client che limitano le informazioni visualizzate non impediscono le tecniche di blind injection.

Manipolazione dei Distinguished Name

LDAP prevede contesti di escape distinti. Confonderli crea vettori di injection. I filtri di ricerca richiedono l'escape secondo RFC 4515 (*→\2a, (→\28, )→\29). I Distinguished Name (DN) richiedono l'escape secondo RFC 2253 (\, #, +, <, >, ,, ;, ", =). Applicare le regole di escape di un contesto al campo sbagliato lascia vulnerabile la vostra applicazione, anche quando pensate di aver risolto il problema.

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

Cause della LDAP injection

Le vulnerabilità di LDAP injection derivano dalla combinazione di pratiche di sviluppo, limiti delle librerie e configurazioni errate dell'infrastruttura. Ogni causa apre una via indipendente allo sfruttamento.

• Concatenazione diretta di stringhe. La causa immediata di quasi tutte le vulnerabilità di LDAP injection è la concatenazione diretta, a livello applicativo, di dati controllati dall'utente nelle stringhe dei filtri LDAP. Storicamente, le librerie LDAP non hanno offerto un supporto integrato per le query parametrizzate, costringendo gli sviluppatori a seguire indicazioni manuali per costruire query sicure. Esistono interfacce parametrizzate, ma occorre scegliere di adottarle.
• Gestione errata dei caratteri speciali. Le applicazioni che convalidano gli input spesso usano elenchi di esclusione incompleti, che non intercettano tutti i caratteri pericolosi. Un elenco che blocca * e ( ma non ) o i byte NUL lascia comunque una falla sfruttabile. MITRE CWE-90 identifica la LDAP injection come conseguenza di questa mancanza: la vulnerabilità nasce direttamente dalla gestione errata dei caratteri speciali.
• Confusione tra contesti di escape. La guida rapida a LDAP documenta che applicare le regole di escape dei filtri di ricerca ai campi DN, o viceversa, crea vettori di injection per la scelta del contesto errato. Se i vostri sviluppatori sanno che occorre applicare l'escape ma scelgono la funzione sbagliata, la vostra applicazione resta vulnerabile.
• Configurazioni di bind anonimo e senza autenticazione. I server LDAP configurati per accettare il bind anonimo lasciano agli aggressori la possibilità di aggirare completamente l'autenticazione del bind.
• Uso diffuso di LDAP per l'autenticazione. LDAP è alla base dell'autenticazione negli ambienti aziendali. Un'injection nei flussi di accesso può quindi avere la conseguenza più grave: l'accesso autenticato alle risorse dell'intera azienda. La superficie di attacco si estende a tutta l'azienda per scelta architetturale.

Queste cause si combinano e creano rischi che vanno ben oltre una singola query compromessa.

Impatto e rischi della LDAP injection

Gli attacchi di LDAP injection possono avere diverse conseguenze per l'azienda, ciascuna di gravità crescente.

Bypass dell'autenticazione

L'injection di un filtro sempre vero concede accesso autenticato immediato. CVE-2023-4501 in OpenText Enterprise Server permetteva di autenticarsi con qualsiasi nome utente valido, anche con una password errata. L'autenticazione poteva riuscire anche con un nome utente non valido e qualsiasi password. La vulnerabilità interessava ambienti aziendali di sviluppo ed esecuzione COBOL nei settori finanziario e assicurativo e nella pubblica amministrazione.

Esfiltrazione di dati sensibili

Le directory LDAP contengono credenziali degli utenti, hash delle password, indirizzi email, gerarchie organizzative, appartenenze ai gruppi, ACL, account dei computer e identificatori di sicurezza. Un avviso della CISA ha documentato una singola query LDAP capace di recuperare informazioni su utenti, computer, gruppi, ACL, OU e GPO da una directory aziendale.

Escalation dei privilegi

Un'injection riuscita può concedere autorizzazioni a query non autorizzate e consentire la modifica dei contenuti nell'albero LDAP. CVE-2026-31828 in Parse Server permetteva agli utenti autenticati con privilegi limitati di ottenere l'accesso a qualsiasi gruppo riservato tramite LDAP filter injection.

Negazione del servizio

CVE-2025-12764 (pgAdmin) ha dimostrato che l'iniezione LDAP può costringere il server DC/LDAP e il client a elaborare una quantità insolita di dati, causando un'interruzione del servizio nell'infrastruttura di directory e fallimenti a catena dell'autenticazione.

Preparazione degli spostamenti laterali

L'enumerazione LDAP alimenta la ricognizione di Active Directory. Un avviso del red team di CISA ha documentato che i dati LDAP hanno permesso di mappare utenti, computer, gruppi, ACL, OU e GPO, tutti elementi utili alla pianificazione degli spostamenti laterali. L'azienda esaminata non aveva alcuna visibilità su questa attività.

OWASP assegna all'iniezione un punteggio di 3 (Facile) per la sfruttabilità e di 3 (Grave) per l'impatto tecnico nel suo framework OWASP. L'iniezione LDAP ha anche conseguenze dirette sulla conformità: PCI DSS 6.5.1 indica esplicitamente l'iniezione LDAP, insieme alle iniezioni SQL e XPath, tra gli aspetti da valutare obbligatoriamente.

Comprendere l'impatto vi aiuta a dare priorità alle difese, ma dovete anche sapere esattamente come gli attaccanti individuano e sfruttano queste vulnerabilità.

Come gli attaccanti sfruttano l'iniezione LDAP

Gli attaccanti seguono un metodo strutturato per individuare e sfruttare le vulnerabilità di iniezione LDAP, dalla ricognizione fino all'estrazione completa delle credenziali.

Passaggio 1: individuare i punti di ingresso integrati con LDAP

L'attaccante individua le funzionalità dell'applicazione che probabilmente interrogano un backend LDAP. Secondo il blog di SANS su LDAP, LDAP può essere usato per la gestione, l'autenticazione e l'interrogazione degli oggetti in un database di directory. Moduli di accesso, pagine di ricerca degli utenti, procedure di reimpostazione delle password, ricerche nella directory aziendale e VPN sono tutte possibili superfici di attacco.

Passaggio 2: cercare punti di iniezione

La guida OWASP ai test LDAP indica di inserire i caratteri (, |, &, * per verificare se le risposte cambiano. Messaggi di errore, risultati vuoti o cambiamenti nel comportamento dell'applicazione confermano che un parametro è vulnerabile.

Passaggio 3: dedurre la struttura del filtro

Senza il codice sorgente, gli attaccanti deducono la struttura del filtro LDAP tramite fuzzing. SANS osserva: "È improbabile che durante un test di penetrazione abbiate accesso al codice sorgente per esaminare queste istruzioni. In questi casi, potrebbe essere necessario ricorrere al fuzzing e alla ricognizione."

Passaggio 4: creare payload di iniezione

Tra i payload più comuni:

• Iniezione di caratteri jolly (*) per recuperare tutte le voci della directoryper recuperare tutte le voci della directory
• Filtri sempre veri ()(uid=))(|(uid=*) per aggirare l'autenticazione
• Iniezione di attributi basata su OR ()(department=it)(|(cn=) per acquisire credenziali da più attributi
• Terminazione con classe di oggetti nulla (*)(objectClass=*))(& (objectClass=void) per stabilire un oracolo booleano affidabile per l'estrazione alla cieca

Il payload specifico dipende dalla struttura del filtro dedotta dall'attaccante durante la ricognizione.

Passaggio 5: proseguire attraverso catene di attacco

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

1. Aggirare l'accesso con un filtro sempre vero
2. Estrarre le credenziali di dominio tramite iniezione basata su OR
3. Creare account di dominio tramite ldapmodify (ATT&CK T1136.002)
4. Estrarre NTDS.dit per craccare le credenziali offline (ATT&CK T1003.003)

L'iniezione LDAP blind apre una catena di attacco parallela: gli attaccanti enumerano gli attributi dello schema con query (attribute=*), poi ne estraggono i valori carattere per carattere, inclusi hash delle password, appartenenze ai gruppi e identificatori di sicurezza.

Queste modalità di sfruttamento interessano un'ampia gamma di organizzazioni e applicazioni.

Chi è esposto all'iniezione LDAP?

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

Le tipologie di applicazioni più esposte includono:

• Applicazioni web con autenticazione basata su LDAP (portali di accesso, sistemi SSO)
• Applicazioni aziendali legacy che costruiscono query LDAP concatenando stringhe
• Portali per il ripristino autonomo delle password e directory dei dipendenti
• Gateway VPN e portali di accesso remoto
• Piattaforme di gestione dei sistemi di controllo industriale
• Applicazioni desktop (OWASP Desktop App Security Top 10 elenca l'iniezione LDAP alla voce DA1 Injections)

I settori in cui il rischio è più concentrato includono:

• Sanità: i sistemi EHR e clinici basati su LDAP sono soggetti alle disposizioni HIPAA in caso di vulnerabilità non corrette. HHS ha documentato dati HHS sulle violazioni in violazioni di vasta portata tra il 2018 e il 2022.
• Servizi finanziari: L'iniezione resta una superficie di attacco rilevante per i sistemi aziendali legati all'identità in questo settore.
• Pubblica amministrazione e infrastrutture critiche: CISA ha documentato lo sfruttamento attivo in ambienti governativi e piattaforme ICS del settore energetico.
• Software e tecnologia: backend open source, strumenti per database e piattaforme di sviluppo continuano a presentare nuove CVE relative all'iniezione LDAP.

L'iniezione LDAP interessa un'ampia gamma di software: ambienti COBOL aziendali, strumenti di amministrazione dei database, piattaforme del settore energetico e backend open source. Non sono rischi ipotetici: incidenti recenti lo confermano.

Esempi reali di iniezione LDAP

I casi seguenti mostrano come si manifesta l'iniezione LDAP nelle reti governative, nelle piattaforme aziendali e negli strumenti open source.

CISA Red Team: un'azienda senza alcuna visibilità sul traffico LDAP (2024)

Una valutazione CISA ha rilevato che l'azienda esaminata "non monitorava il traffico LDAP anomalo." Il team ha interrogato LDAPS per raccogliere informazioni su utenti, computer, gruppi, ACL, OU e GPO. CISA ha dichiarato esplicitamente che le query LDAP di un utente senza privilegi da un host Linux del dominio "avrebbero dovuto allertare i difensori della rete."

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

Questa vulnerabilità rendeva possibile autenticarsi con qualsiasi nome utente valido, indipendentemente dalla password, e persino con un nome utente non valido. Interessava gli ambienti aziendali di sviluppo ed esecuzione COBOL impiegati nei servizi finanziari, nelle assicurazioni e nell'integrazione con i mainframe della pubblica amministrazione.

Ivanti EPMM: attori delle minacce estraggono credenziali LDAP (2025)

Dopo la pubblicazione di una proof of concept nel maggio 2025, gli attori delle minacce hanno ottenuto accesso a un server Ivanti EPMM e hanno estratto credenziali LDAP. CISA ha aggiunto le vulnerabilità alla base dell'attacco al catalogo KEV il 19 maggio 2025.

Redash: iniezione LDAP che facilita il password spraying (CVE-2020-36144)

GitHub Security Lab ha documentato che il campo email nell'autenticazione LDAP di Redash costruiva la stringa di una query di filtro LDAP senza eseguire l'escape dei caratteri, consentendo a un attaccante non autenticato di forzare le password di tutti gli utenti con una sola richiesta.

Questi incidenti riflettono decenni di problemi di sicurezza legati a LDAP.

Cronologia e storia dell'iniezione LDAP

L'iniezione LDAP è una classe di vulnerabilità nota da oltre vent'anni. La sua classificazione formale e la pubblicazione continua di CVE risalgono alla fine degli anni Novanta e proseguono tuttora.

• Origini del protocollo. X.500 Directory Access Protocol (DAP) è stato sviluppato da ITU-T. LDAP v1 è apparso nella RFC 1487, v2 nella RFC 1777 e v3 nella RFC 2251, versione tuttora utilizzata nelle aziende.
• Primo problema documentato. CVE-1999-0895 ha documentato uno dei primi problemi di sicurezza dell'autenticazione LDAP in Checkpoint FireWall-1 V4.0.
• Classificazione formale. OWASP ha documentato formalmente l'iniezione LDAP come classe di attacco distinta. La OWASP Top 10 del 2007 l'ha classificata nella categoria A2, vulnerabilità di iniezione.
• Ricerca sull'iniezione alla cieca. Alonso e colleghi hanno presentato una ricerca sistematica sull'iniezione LDAP alla cieca a Black Hat Europe, dimostrando l'estrazione dei dati carattere per carattere.
• Massima priorità nella OWASP Top 10. La OWASP Top 10 del 2017 ha classificato l'iniezione come A1, il principale rischio per le applicazioni web, citando esplicitamente l'iniezione LDAP.
• Attacchi ai sistemi ICS. CVE-2018-14805 (ABB eSOMS) ha portato l'iniezione LDAP nell'ambito dei sistemi ICS del settore energetico.
• Attacchi alle piattaforme aziendali. ForgeRock OpenAM, OpenLDAP e OpenText Enterprise Server hanno dimostrato che l'impatto sulle aziende persiste.
• Divulgazioni recenti. Nuove CVE emerse negli ultimi anni riguardano Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax e pgAdmin.

Continuano a emergere nuove CVE, rendendo il monitoraggio continuo una necessità concreta.

Come rilevare l'iniezione LDAP

Monitorate più livelli: applicazione, directory e rete.

Indicatori a livello applicativo

Monitorate i campi di input degli utenti per individuare i metacaratteri LDAP: *, (, ), \ e i byte NUL nei parametri di autenticazione e ricerca. Cercate insiemi di risultati LDAP insolitamente grandi, che suggeriscono un'iniezione di caratteri jolly capace di restituire tutte le voci della directory. Un'autenticazione riuscita subito dopo una query malformata segnala un possibile bypass dell'autenticazione.

Indicatori a livello del server LDAP

Cercate strutture di filtro contenenti le sequenze )( o |(, che indicano la manipolazione dei gruppi di filtri. Le query che restituiscono tutte le voci tramite (objectClass=*) o (cn=*) suggeriscono un'enumerazione tramite caratteri jolly. Un bind anonimo seguito da ricerche estese indica tentativi di ricognizione senza autenticazione.

Monitoraggio SIEM e dei log degli eventi

Negli ambienti Active Directory, due ID evento di Windows sono fondamentali:

• ID evento 4662: Operazioni eseguite sugli oggetti AD. Monitorate le azioni Write Property, Control Access, DELETE, WRITE_DAC e WRITE_OWNER.
• ID evento 1644: Query LDAP costose o inefficienti, spesso generate dai tentativi di iniezione.

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

Schemi di correlazione comportamentale

Correlate diverse fonti di dati per individuare le campagne di iniezione:

• Volume elevato di query LDAP da un singolo indirizzo IP di origine (strumenti di iniezione)
• Enumerazione sequenziale degli attributi: uid=a*, uid=b* (estrazione tramite iniezione alla cieca)
• Password errata seguita da un accesso riuscito immediato (conferma del bypass dell'autenticazione)
• Host Linux di dominio senza privilegi che esegue query LDAP in massa (lo stesso schema che CISA ha documentato come non rilevato)

Correlando questi segnali tra più fonti, ottenete un quadro delle campagne di iniezione attive più chiaro di quello fornito da un singolo indicatore.

Monitoraggio a livello WAF

OWASP ModSecurity Core Rule Set include la regola con ID 921200 in REQUEST-921-PROTOCOL-ATTACK.conf, che rileva la LDAP injection con severità CRITICAL e livello di paranoia 1 (attivata per impostazione predefinita). La regola esamina i cookie delle richieste, i nomi e i valori degli argomenti e i corpi XML alla ricerca di sequenze di metacaratteri dei filtri LDAP.

Individuare attività sospette non basta senza adeguati controlli di prevenzione.

Come prevenire la LDAP injection

La prevenzione richiede una difesa a più livelli che copra codice, configurazione e infrastruttura.

Difese a livello di codice

• Usate query LDAP parametrizzate. La difesa più efficace consiste nel passare l'input dell'utente come parametro anziché concatenarlo alle stringhe dei filtri:

• Applicate l'escaping appropriato al contesto. Usate la funzione di escaping corretta per ciascun contesto LDAP. Per i filtri di ricerca (RFC 4515), eseguite l'escaping di *→\2a, (→\28, )→\29, \→\5c, NUL→\00. Per i nomi distinti (RFC 2253), eseguite l'escaping di \, #, +, <, >, ,, ;, ", = e degli spazi iniziali e finali.

Le implementazioni specifiche per linguaggio includono:

• Implementate la convalida tramite allowlist. Convalidate l'input rispetto ai formati previsti prima di qualsiasi operazione LDAP. Rifiutate gli input contenenti metacaratteri non previsti nel campo. Normalizzate l'input (canonicalizzazione Unicode) prima della convalida, secondo la guida pratica di OWASP.

Rafforzamento dell'infrastruttura

• Disabilitate i bind anonimi e non autenticati. Questa singola misura elimina la causa alla radice di diverse vulnerabilità critiche.
• Usate LDAPS (porta 636). Disabilitate LDAP in chiaro (porta 389) secondo NIST SP 1800-16.
• Applicate ACL basate sul principio del privilegio minimo agli account di servizio usati per i bind LDAP. Limitateli alle sole operazioni e porzioni dell'albero delle directory necessarie.
• Segmentate l'infrastruttura LDAP per separarla dall'accesso generale alla rete, secondo NIST SP 1800-18B.

Questi controlli riducono la superficie di attacco a disposizione di chi raggiunge la vostra infrastruttura LDAP.

Integrazione nella pipeline CI/CD

Integrate l'analisi statica (SAST) e l'analisi dinamica (DAST) nella vostra pipeline di sviluppo. La OWASP Top 10 raccomanda di includere strumenti SAST, DAST e IAST per individuare le vulnerabilità di injection prima della distribuzione in produzione. La modalità di taint analysis di Semgrep può tracciare l'input non attendibile dalle sorgenti ai punti in cui viene utilizzato senza sanitizzazione, mediante regole personalizzate per la costruzione delle query LDAP.

Queste misure preventive sono più efficaci se supportate dagli strumenti giusti.

Strumenti di rilevamento e prevenzione

Una difesa efficace contro le LDAP injection richiede strumenti di scansione, monitoraggio e protezione in fase di esecuzione.

• OWASP ZAP esegue scansioni attive per rilevare le LDAP injection tramite ZAP Alert 40015 (CWE-90, WASC-29). Installate le regole di scansione Alpha tramite ZAP Marketplace e configurate le tecnologie di destinazione includendo Protocol / LDAP per le applicazioni integrate con LDAP.
• OWASP ModSecurity CRS offre protezione WAF tramite CRS Rule 921200, che per impostazione predefinita opera al Paranoia Level 1. La regola esamina cookie, argomenti e payload XML alla ricerca di segnali di manipolazione dei filtri LDAP. I payload dei test di regressione CRS tratti da CRS Issue 276 forniscono una lista di input per il fuzzing pronta all'uso per verificare il WAF.
• Semgrep supporta la taint analysis statica tramite regole mode: taint che tracciano i dati non attendibili dalle sorgenti di input ai punti in cui vengono utilizzati nelle query LDAP, segnalando i percorsi di injection prima che il codice raggiunga la produzione.
• Le piattaforme SIEM con regole di identificazione personalizzate possono monitorare gli ID evento Windows 4662 e 1644, correlare schemi anomali nelle query LDAP e generare avvisi su indicatori comportamentali come l'enumerazione sequenziale degli attributi o le query in blocco da host senza privilegi.

Questi strumenti affrontano singoli aspetti del problema. Un approccio basato su una piattaforma li unifica.

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 demo

Vulnerabilità correlate

Diverse classi di vulnerabilità condividono questo schema con le LDAP injection:

• SQL injection (CWE-89): È l'analogia più diretta. Entrambe sfruttano input non sanitizzati nei linguaggi di query e possono aggirare l'autenticazione con tecniche simili. La sintassi e i sistemi presi di mira differiscono notevolmente.
• OS command injection (CWE-78): Secondo MITRE, condivide con CWE-90 lo stesso Software Fault Pattern (SFP24, "Tainted input to command"). Prende di mira il sistema operativo dell'host anziché i servizi di directory.
• XPath injection (CWE-643): La guida OWASP LDAP testing raggruppa esplicitamente le XPath injection e le LDAP injection come tecniche analoghe per aggirare l'autenticazione nei sistemi di archiviazione dati basati su XML.
• Neutralizzazione impropria di elementi speciali (CWE-77): È la vulnerabilità principale da cui deriva CWE-90 nella gerarchia MITRE. Tutti i tipi di injection derivano da questa mancata neutralizzazione dei caratteri significativi per l'interprete.
• Codifica o escaping impropri dell'output (CWE-116): Documenta il nesso diretto tra un errore di escaping e l'injection. CVE-2021-41232 dimostra la catena CWE-116 → CWE-90: un errore di escaping in un'applicazione Go ha reso direttamente possibile una LDAP injection.
• Validazione impropria dell'input (CWE-20): È la causa principale quando le applicazioni non convalidano il formato dell'input prima di costruire le query LDAP.

Esaminare queste vulnerabilità correlate vi aiuta ad applicare gli stessi principi di difesa a tutto il codice, non solo ai percorsi specifici di LDAP.

CVE correlate

Conclusioni

L'iniezione LDAP permette agli aggressori di trasformare input non attendibili in controllo sui sistemi di directory da cui il vostro ambiente dipende per l'autenticazione e l'accesso. Per voi, questo significa che il rischio raramente si limita a una sola query o applicazione. 

Create query sicure, eseguite l'escape dei valori nel contesto corretto, limitate le autorizzazioni di bind e monitorate attentamente l'attività LDAP. Così riducete l'esposizione e lo spazio di manovra degli aggressori.