Wat is LDAP Injection? Hoe het werkt en hoe het te stoppen

LDAP Injection manipuleert directory-queries via niet-gesaniteerde gebruikersinvoer. Leer hoe aanvallers authenticatie omzeilen, data extraheren en hoe u dit kunt voorkomen.

Wat is LDAP-injectie?

LDAP-injectie is een server-side aanval die misbruik maakt van webapplicaties die Lightweight Directory Access Protocol-query’s samenstellen op basis van niet-gesaniteerde gebruikersinvoer. Wanneer uw applicatie er niet in slaagt speciale tekens correct te neutraliseren voordat deze in LDAP-query’s worden opgenomen, kunnen aanvallers deze query’s manipuleren om authenticatie te omzeilen, gevoelige directorygegevens te extraheren of vermeldingen binnen de LDAP-boom te wijzigen.

LDAP-directory’s vormen het hart van de identiteitsinfrastructuur van ondernemingen. Ze slaan gebruikersreferenties, groepslidmaatschappen, toegangscontrollijsten, organisatiestructuren en serviceaccountgegevens op. Eén geslaagde LDAP-injectieaanval kan deze opslagplaats blootleggen en een aanvaller de sleutels tot uw authenticatie-infrastructuur geven.

MITRE classificeert deze kwetsbaarheid als MITRE CWE-90: Onjuiste neutralisatie van speciale elementen gebruikt in een LDAP-query. OWASP vermeldt het onder OWASP Injection en de bijgewerkte OWASP Injection-categorie. De kwetsbaarheid deelt zijn onderliggende oorzaak met SQL-injectie, maar richt zich op een fundamenteel ander en vaak ingrijpender systeem: de directoryservice die bepaalt wie toegang heeft tot wat binnen uw hele organisatie.

Begrijpen hoe LDAP-injectie werkt vereist kennis van de querysyntaxis die aanvallers uitbuiten.

Hoe werkt LDAP-injectie?

LDAP-zoekfilters volgen een specifieke grammatica gedefinieerd in LDAP-syntaxis. Filters gebruiken Poolse notatie (prefixnotatie), waarbij een eenvoudige authenticatiequery er als volgt uitziet:

De &-operator voert een Booleaanse AND uit. Haakjes groeperen voorwaarden. Het *-jokerteken komt overeen met elke waarde. Deze metatekens, samen met | (OR), ! (NOT), =, ~=, >=, <=, en () groepeeroperators, vormen het injectieoppervlak.

Wanneer een ontwikkelaar een filter samenstelt door gebruikersinvoer direct aan de querystring toe te voegen, worden die metatekens wapens. Als een inlogformulier de gebruikersnaam rechtstreeks invoegt in een filter zoals (&(uid=INPUT)(userPassword=HASH)), kan een aanvaller die samengestelde metatekens indient de logica van het filter volledig wijzigen: authenticatie omzeilen, alle directoryvermeldingen retourneren of gegevens teken voor teken extraheren.

De specifieke techniek die een aanvaller gebruikt, hangt af van het type LDAP-injectie.

Typen LDAP-injectie

LDAP-injectie kent verschillende vormen, elk gericht op een ander aspect van de interactie tussen applicaties en de directory. Het type dat een aanvaller gebruikt, hangt af van het gedrag van de applicatie, de context van de query en wat de aanvaller kan waarnemen in de respons.

Type	Techniek	Gevolg
Zoekfilterinjectie	Manipulatie van filter met jokerteken of OR	Volledige directory-enumeratie
Authenticatieomzeiling	Injectie van altijd-waar-filter	Ongeautoriseerde login als elke gebruiker
Blinde LDAP-injectie	Teken-voor-teken differentiële analyse	Stille data-extractie
DN-manipulatie	Verkeerde escapecontext toegepast op DN-velden	Injectie in niet-filterquerycomponenten

Zoekfilterinjectie

Bekijk deze kwetsbare Java-code:

Als een aanvaller user=* indient, wordt het resulterende filter (cn=*), wat overeenkomt met elk object in de directory met een cn-attribuut. Uw applicatie retourneert de volledige gebruikersdirectory in plaats van één record.

Authenticatieomzeiling

LDAP-authenticatiestromen vormen het doelwit met de hoogste impact voor injectie. Een kwetsbaar loginfilter zoals dit:

Dit filter kan worden omzeild door )(uid=))(|(uid=* als gebruikersnaam te injecteren. Het resulterende filter evalueert altijd als waar, waardoor de aanvaller geauthenticeerde status krijgt als de eerste gebruiker in de LDAP-boom, vaak een beheerdersaccount. De testgids documenteert dit als het directe equivalent van SQL-injectie authenticatieomzeilingstechnieken.

Blinde LDAP-injectie

Wanneer applicaties geen queryresultaten direct tonen, gebruiken aanvallers differentiële responsen om gegevens te extraheren. Door filtervoorwaarden zoals (attribute=a*), (attribute=b*) te injecteren en te observeren of de applicatie een resultaat of een lege pagina retourneert, extraheren ze attribuutwaarden teken voor teken. Onderzoek gepresenteerd in de Black Hat-paper toonde aan dat client-side filters die weergegeven informatie beperken blinde injectietechnieken niet voorkomen.

Distinguished Name-manipulatie

LDAP kent verschillende escapecontexten, en verwarring hierover creëert injectievectoren. Zoekfilters vereisen escaping volgens RFC 4515 (*→\2a, (→\28, )→\29). Distinguished Names (DN’s) vereisen escaping volgens RFC 2253 (\, #, +, <, >, ,, ;, ", =). Het toepassen van de verkeerde escapecontext op het verkeerde veld laat uw applicatie kwetsbaar, zelfs als u denkt het probleem te hebben opgelost.

Deze aanvalstypen delen gemeenschappelijke oorzaken die dieper gaan dan syntaxis.

Oorzaken van LDAP-injectie

LDAP-injectie kwetsbaarheden ontstaan door een combinatie van programmeerpraktijken, beperkingen van bibliotheken en misconfiguraties in de infrastructuur. Elke oorzaak creëert een onafhankelijk pad naar uitbuiting.

• Directe stringconcatenatie. De directe oorzaak in bijna elke LDAP-injectie kwetsbaarheid is door de gebruiker gecontroleerde data die direct wordt samengevoegd in LDAP-filterstrings op applicatieniveau. LDAP-bibliotheken ontbeerden historisch ingebouwde ondersteuning voor geparametriseerde query’s, waardoor ontwikkelaars handmatige richtlijnen moesten volgen voor veilige queryconstructie. Geparametriseerde interfaces bestaan, maar vereisen bewuste implementatie.
• Onjuiste omgang met speciale tekens. Applicaties die inputvalidatie proberen te implementeren, gebruiken vaak onvolledige denylists die gevaarlijke tekens missen. Een denylist die * en ( blokkeert maar ) of NUL-bytes mist, laat nog steeds een uitbuitbare opening. MITRE CWE-90 identificeert LDAP-injectie als gevolg van dit falen, wat betekent dat de injectiekwetsbaarheid direct voortkomt uit het verkeerd omgaan met speciale tekens.
• Verwarring over escapecontext. De LDAP-cheatsheet documenteert dat het toepassen van zoekfilter-escaping op DN-velden, of DN-escaping op zoekfiltervelden, injectievectoren creëert door verkeerde contextselectie. Als uw ontwikkelaars weten dat ze moeten escapen maar de verkeerde functie kiezen, blijft uw applicatie kwetsbaar.
• Configuraties voor anonieme en niet-geauthenticeerde bind. LDAP-servers die anonieme bind toestaan, laten aanvallers bind-authenticatie volledig omzeilen.
• Wijdverbreid gebruik van LDAP voor authenticatie. LDAP’s rol als authenticatieruggengraat voor ondernemingen betekent dat injectie tegen loginflows het ernstigste gevolg heeft: geauthenticeerde toegang tot bedrijfsbrede resources. Het aanvalsoppervlak is bedrijfsbreed door architectonisch ontwerp.

Deze oorzaken samen creëren risico’s die veel verder gaan dan één gecompromitteerde query.

Impact en risico van LDAP-injectie

LDAP-injectieaanvallen kunnen verschillende categorieën van bedrijfsimpact veroorzaken, elk oplopend in ernst.

Authenticatieomzeiling

Een altijd-waar-filterinjectie verleent direct geauthenticeerde toegang. CVE-2023-4501 in OpenText Enterprise Server liet authenticatie slagen met elke geldige gebruikersnaam, ongeacht of het wachtwoord correct was, en kan ook slagen met een ongeldige gebruikersnaam en elk wachtwoord. Dit trof enterprise COBOL-ontwikkel- en runtimeomgevingen ingezet in financiële dienstverlening, verzekeringen en overheid.

Exfiltratie van gevoelige gegevens

LDAP-directory’s bevatten gebruikersreferenties, wachtwoordhashes, e-mailadressen, organisatiestructuren, groepslidmaatschappen, ACL’s, computeraccounts en security identifiers. Een CISA-advies documenteerde een enkele LDAP-query die informatie over gebruikers, computers, groepen, ACL’s, OU’s en GPO’s uit een bedrijfsdirectory ophaalde.

Privilege-escalatie

Geslaagde injectie kan rechten geven tot ongeautoriseerde query’s en het mogelijk maken om inhoud binnen de LDAP-boom te wijzigen. CVE-2026-31828 in Parse Server liet geauthenticeerde gebruikers met lage rechten escaleren naar elke beperkte groep via LDAP-filterinjectie.

Denial of Service

CVE-2025-12764 (pgAdmin) toonde aan dat LDAP-injectie kon worden gebruikt om de DC/LDAP-server en client te dwingen een ongebruikelijke hoeveelheid data te verwerken, wat leidde tot een denial of service tegen de directory-infrastructuur met cascaderende authenticatiefouten.

Mogelijkheid tot laterale beweging

LDAP-enumeratie voedt Active Directory-reconnaissance. Het CISA red team-advies documenteerde dat LDAP-data het mogelijk maakte om gebruikers, computers, groepen, ACL’s, OU’s en GPO’s in kaart te brengen, die allemaal dienen als input voor laterale beweging-planning. De beoordeelde onderneming had geen zicht op deze activiteit.

OWASP beoordeelt de exploitbaarheid van injectie als 3 (Eenvoudig) en de technische impact als 3 (Ernstig) in het OWASP-framework. LDAP-injectie heeft ook directe gevolgen voor compliance: PCI DSS 6.5.1 noemt LDAP-injectie expliciet naast SQL- en XPath-injectie als verplichte assessmentdoelstelling.

Het begrijpen van de impact helpt u prioriteit te geven aan verdediging, maar u moet ook precies weten hoe aanvallers deze kwetsbaarheden vinden en uitbuiten.

Hoe aanvallers LDAP-injectie uitbuiten

Aanvallers volgen een gestructureerde methodologie om LDAP-injectiekwetsbaarheden te vinden en uit te buiten, van verkenning tot volledige credential-extractie.

Stap 1: Identificeer LDAP-geïntegreerde toegangspunten

De aanvaller identificeert applicatiefuncties die waarschijnlijk een LDAP-backend bevragen. Volgens SANS LDAP-blog kan LDAP worden gebruikt voor beheer, authenticatie en het opvragen van objecten uit een directorydatabase. Inlogformulieren, gebruikerszoekpagina’s, wachtwoordresetflows, bedrijfsdirectory-opzoekingen en VPN-gatewayportalen zijn allemaal potentiële oppervlakken.

Stap 2: Test op injectiepunten

De OWASP LDAP-test instrueert testers om tekens (, |, &, * in te voeren om te controleren op verschillende responsen. Foutmeldingen, lege resultaatsets of gewijzigd applicatiegedrag bevestigen een kwetsbare parameter.

Stap 3: Leid de filterstructuur af

Zonder broncode leiden aanvallers de structuur van het LDAP-filter af via fuzzing. SANS merkt op: "Het is onwaarschijnlijk dat u tijdens een penetratietest de broncode heeft om deze statements te zien. In deze situaties moeten mogelijk fuzzing en reconnaissance worden toegepast."

Stap 4: Stel injectiepayloads samen

Veelvoorkomende payloads zijn onder andere:

• Jokertekeninjectie (*) om alle directoryvermeldingen op te halen
• Altijd-waar-filters ()(uid=))(|(uid=*) om authenticatie te omzeilen
• OR-gebaseerde attribuutinjectie ()(department=it)(|(cn=) om referenties over meerdere attributen te verzamelen
• Null object class-terminatie (*)(objectClass=*))(& (objectClass=void) om een betrouwbare Booleaanse orakel te creëren voor blinde extractie

De specifieke payload hangt af van de filterstructuur die de aanvaller tijdens de verkenning heeft afgeleid.

Stap 5: Escaleren via aanvalsketens

Een typische aanvalsketen, gedocumenteerd door OWASP en MITRE ATT&CK-bronnen, volgt deze progressie:

1. Login omzeilen met een altijd-waar-filter
2. Domeinreferenties extraheren via OR-gebaseerde injectie
3. Domeinaccounts aanmaken via ldapmodify (ATT&CK T1136.002)
4. NTDS.dit dumpen voor offline credential cracking (ATT&CK T1003.003)

Blinde LDAP-injectie maakt een parallelle keten mogelijk waarbij aanvallers schema-attributen enumereren met (attribute=*)-probes, en vervolgens waarden teken voor teken extraheren, inclusief wachtwoordhashes, groepslidmaatschappen en security identifiers.

Deze uitbuitingspatronen treffen een breed scala aan organisaties en applicatietypen.

Wie is kwetsbaar voor LDAP-injectie?

Elke organisatie die vertrouwt op LDAP-gebaseerde authenticatie loopt structureel risico op deze kwetsbaarheid. OWASP merkt op dat injectiekwetsbaarheden "zeer wijdverbreid zijn, vooral in legacy code."

Applicatietypen met de hoogste blootstelling zijn onder andere:

• Webapplicaties met LDAP-gebaseerde authenticatie (loginportalen, SSO-systemen)
• Legacy enterprise-applicaties die LDAP-query’s samenstellen via stringconcatenatie
• Selfservice-wachtwoordreset en medewerkersdirectoryportalen
• VPN-gateways en remote access-portalen
• Beheerplatforms voor industriële controlesystemen
• Desktopapplicaties (OWASP Desktop App Security Top 10 noemt LDAP-injectie onder DA1 Injections)

Sectoren met geconcentreerd risico zijn onder andere:

• Zorg: LDAP-gebaseerde EPD- en klinische systemen vallen onder HIPAA-handhaving voor niet-gepatchte kwetsbaarheden, waarbij HHS HHS-gegevenslekken documenteert in grote incidenten tussen 2018 en 2022.
• Financiële dienstverlening: Injectie blijft een relevant aanvalsoppervlak voor identiteitsgebonden bedrijfsapplicaties in deze sector.
• Overheid en kritieke infrastructuur: CISA heeft actieve uitbuiting gedocumenteerd in overheidsomgevingen en ICS-energieplatforms.
• Software en technologie: Open-source backends, databasetools en ontwikkelplatforms blijven nieuwe LDAP-injectie-CVE’s produceren.

LDAP-injectie treft een breed scala aan software, van enterprise COBOL-omgevingen, databasebeheertools, energieplatforms tot open-source backends. Dit zijn geen hypothetische risico’s; recente incidenten bevestigen ze.

Voorbeelden uit de praktijk van LDAP-injectie

De volgende gevallen illustreren hoe LDAP-injectie zich manifesteert in overheidsnetwerken, enterpriseplatforms en open-sourcetools.

CISA Red Team: Onderneming zonder LDAP-zichtbaarheid (2024)

Een CISA-assessment stelde vast dat de beoordeelde onderneming "geen monitoring had voor afwijkend LDAP-verkeer." Het team bevroeg LDAPS om informatie te verzamelen over gebruikers, computers, groepen, ACL’s, OU’s en GPO’s. CISA stelde expliciet dat een niet-bevoorrechte gebruiker die LDAP bevraagt vanaf een Linux-domeinhost "netwerkverdedigers had moeten alarmeren."

OpenText Enterprise Server: Volledige authenticatieomzeiling (CVE-2023-4501)

Deze kwetsbaarheid liet authenticatie slagen met elke geldige gebruikersnaam, ongeacht het wachtwoord, en kon ook slagen met een ongeldige gebruikersnaam. Het trof enterprise COBOL-ontwikkel- en runtimeomgevingen ingezet in financiële dienstverlening, verzekeringen en mainframe-integratie bij de overheid.

Ivanti EPMM: Dreigingsactoren dumpen LDAP-referenties (2025)

Na publicatie van een proof of concept in mei 2025 kregen dreigingsactoren toegang tot een Ivanti EPMM-server en dumpden LDAP-referenties. CISA voegde de onderliggende kwetsbaarheden toe aan de KEV-catalogus op 19 mei 2025.

Redash: LDAP-injectie maakt Password Spraying mogelijk (CVE-2020-36144)

GitHub Security Lab documenteerde dat het e-mailveld in Redash LDAP-authenticatie een LDAP-filterquerystring vormde zonder escaping, waardoor een niet-geauthenticeerde aanvaller alle gebruikerswachtwoorden met één verzoek kon brute-forcen.

Deze incidenten beslaan decennia van LDAP-beveiligingsuitdagingen.

LDAP-injectie: tijdlijn en geschiedenis

LDAP-injectie is al meer dan twintig jaar een bekende kwetsbaarheidsklasse, met formele classificatie en voortdurende CVE-meldingen vanaf eind jaren negentig tot nu.

• Protocoloorsprong. X.500 Directory Access Protocol (DAP) werd ontwikkeld door ITU-T. LDAP v1 verscheen in RFC 1487, v2 in RFC 1777 en v3 in RFC 2251, dat vandaag de dag nog steeds in ondernemingen wordt gebruikt.
• Eerste gedocumenteerde probleem. CVE-1999-0895 documenteerde een vroege LDAP-authenticatiekwetsbaarheid in Checkpoint FireWall-1 V4.0.
• Formele classificatie. OWASP documenteerde LDAP-injectie formeel als een aparte aanvalsklasse. De OWASP Top 10 van 2007 plaatste het onder A2, Injection Flaws.
• Onderzoek naar blinde injectie. Alonso et al. presenteerden systematisch onderzoek naar blinde LDAP op Black Hat Europe, waarmee teken-voor-teken data-extractie werd aangetoond.
• Piekprioriteit bij OWASP. OWASP Top 10 2017 rangschikte Injection als A1, het grootste webapplicatierisico, met expliciete vermelding van LDAP-injectie.
• ICS-doelwitten. CVE-2018-14805 (ABB eSOMS) bracht LDAP-injectie naar de ICS-ruimte in de energiesector.
• Enterpriseplatform-doelwitten. ForgeRock OpenAM, OpenLDAP en OpenText Enterprise Server toonden aanhoudende impact op ondernemingen.
• Recente meldingen. Nieuwe CVE’s in de afgelopen jaren treffen Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax en pgAdmin.

Nieuwe CVE’s blijven verschijnen, waardoor voortdurende monitoring een praktische vereiste is.

Hoe LDAP-injectie detecteren

U heeft gelaagde monitoring nodig over applicatie-, directory- en netwerkniveaus.

Indicatoren op applicatieniveau

Monitor gebruikersinvoervelden op LDAP-metatekens: *, (, ), \ en NUL-bytes in authenticatie- en zoekparameters. Let op abnormaal grote LDAP-resultaatsets die wijzen op jokertekeninjectie waarbij alle directoryvermeldingen worden geretourneerd. Authenticatiesucces direct na een onjuiste query duidt op een authenticatieomzeilingspatroon.

Indicatoren op LDAP-serverniveau

Let op filterstructuren met )( of |( sequenties, die wijzen op manipulatie van filtergroepen. Query’s die alle vermeldingen retourneren via (objectClass=*) of (cn=*) duiden op jokertekenenumeratie. Anonieme bind gevolgd door brede zoekopdrachten wijst op ongeauthenticeerde verkenningspogingen.

SIEM- en eventlogmonitoring

Voor Active Directory-omgevingen zijn twee Windows Event ID’s cruciaal:

• Event ID 4662: Bewerkingen uitgevoerd op AD-objecten. Monitor op Write Property, Control Access, DELETE, WRITE_DAC en WRITE_OWNER-acties.
• Event ID 1644: Dure of inefficiënte LDAP-query’s, die vaak door injectiepogingen worden veroorzaakt.

Volgens NCC Group-gids: "Zoek naar ongebruikelijke zoekfilters in de logs. Aanvallers gebruiken vaak specifieke filters om gebruikers, groepen en computers te enumereren."

Gedragsmatige correlatiepatronen

Correlatie over gegevensbronnen om injectiecampagnes te vinden:

• Hoge LDAP-queryvolumes vanaf één bron-IP (injectietooling)
• Sequentiële attribuutenumeratie: uid=a*, uid=b* (blinde injectie-extractie)
• Mislukt wachtwoord gevolgd door direct inlogsucces (bevestiging van authenticatieomzeiling)
• Niet-bevoorrechte Linux-domeinhost die bulk LDAP-query’s uitvoert (precies het patroon dat CISA als onopgemerkt documenteerde)

Het correleren van deze signalen over bronnen geeft een duidelijker beeld van actieve injectiecampagnes dan elk afzonderlijk signaal.

WAF-niveau monitoring

OWASP ModSecurity Core Rule Set bevat Rule ID 921200 in REQUEST-921-PROTOCOL-ATTACK.conf, die LDAP-injectie detecteert op ernst CRITICAL en Paranoia Level 1 (standaard ingeschakeld). De regel inspecteert request cookies, argumentnamen, argumentwaarden en XML-bodies op patronen van LDAP-filtermetatekens.

Het vinden van verdachte activiteit is onvoldoende zonder de juiste preventiemaatregelen.

Hoe LDAP-injectie voorkomen

Preventie vereist een defense-in-depth-benadering over code-, configuratie- en infrastructuurlagen.

Verdediging op codeniveau

• Gebruik geparametriseerde LDAP-query’s. De meest effectieve verdediging is gebruikersinvoer als parameters doorgeven in plaats van deze samen te voegen in filterstrings:

• Pas contextspecifieke escaping toe. Gebruik de juiste escapefunctie voor de juiste LDAP-context. Voor zoekfilters (RFC 4515): escape *→\2a, (→\28, )→\29, \→\5c, NUL→\00. Voor Distinguished Names (RFC 2253): escape \, #, +, <, >, ,, ;, ", = en leidende/afsluitende spaties.

Taal-specifieke implementaties zijn onder andere:

Taal	Zoekfilter escaping	DN escaping
Java	OWASP ESAPI encodeForLDAP()	OWASP ESAPI encodeForDN()
.NET	Encoder.LdapFilterEncode()	Encoder.LdapDistinguishedNameEncode()
Perl	Net::LDAP::Util::escape_filter_value()	Handmatig volgens RFC 2253

• Implementeer allowlist-validatie. Valideer invoer tegen verwachte patronen vóór elke LDAP-operatie. Weiger invoer met metatekens die niet in het veld verwacht worden. Normaliseer invoer (Unicode-canonisatie) vóór validatie volgens de OWASP-cheatsheet.

Infrastructuurverharding

• Schakel anonieme en niet-geauthenticeerde bind uit. Deze enkele actie elimineert de hoofdoorzaak van meerdere kritieke kwetsbaarheden.
• Gebruik LDAPS (poort 636). Schakel plaintext LDAP (poort 389) uit volgens NIST SP 1800-16.
• Pas least-privilege ACL’s toe op LDAP-bindserviceaccounts. Beperk ze tot alleen de benodigde bewerkingen en directorysubtrees.
• Segmenteer LDAP-infrastructuur van algemene netwerktoegang volgens NIST SP 1800-18B.

Deze maatregelen verkleinen het aanvalsoppervlak voor een aanvaller die uw LDAP-infrastructuur bereikt.

Integratie in CI/CD-pijplijn

Integreer statische analyse (SAST) en dynamische analyse (DAST) in uw ontwikkelpijplijn. De OWASP Top 10 raadt aan SAST-, DAST- en IAST-tools op te nemen om injectiekwetsbaarheden te identificeren vóór productie. Semgrep’s taint analysis-modus kan onbetrouwbare invoer van bron naar sink volgen zonder sanitisatie, met aangepaste regels gericht op LDAP-queryconstructie.

Deze preventiemaatregelen werken het beste met de juiste tooling.

Tools voor detectie en preventie

Effectieve verdediging tegen LDAP-injectie vereist een combinatie van scanning-, monitoring- en runtimeprotectietools.

• OWASP ZAP biedt actieve scanning op LDAP-injectie via ZAP Alert 40015 (CWE-90, WASC-29). Installeer via de ZAP Marketplace’s Alpha scan rules en configureer technologie targeting om Protocol / LDAP op te nemen voor applicaties met LDAP-integratie.
• OWASP ModSecurity CRS levert WAF-bescherming via CRS Rule 921200, die standaard op Paranoia Level 1 draait. De regel inspecteert cookies, argumenten en XML-payloads op LDAP-filtermanipulatiesignaturen. CRS-regressietestpayloads uit CRS Issue 276 bieden een kant-en-klare fuzzing-woordenlijst voor WAF-validatie.
• Semgrep ondersteunt statische taint-analyse via mode: taint-regels die onbetrouwbare data van invoerbronnen naar LDAP-query-sinks volgen en injectiepaden markeren vóór productie.
• SIEM-platforms met aangepaste identificatieregels kunnen Windows Event ID’s 4662 en 1644 monitoren, afwijkende LDAP-querypatronen correleren en waarschuwen op gedragsindicatoren zoals sequentiële attribuutenumeratie of bulkquery’s vanaf niet-bevoorrechte hosts.

Deze tools adresseren afzonderlijke lagen van het probleem. Een platformbenadering verbindt ze met elkaar.

Gerelateerde kwetsbaarheden

Verschillende kwetsbaarheidsklassen delen dit patroon met LDAP-injectie:

• SQL-injectie (CWE-89): Het dichtstbijzijnde equivalent. Beide maken misbruik van niet-gesaniteerde invoer in querytalen, en authenticatieomzeiling is mogelijk via vergelijkbare technieken. Syntaxis en doelsystemen verschillen aanzienlijk.
• OS Command-injectie (CWE-78): Deelt hetzelfde Software Fault Pattern (SFP24, "Tainted input to command") met CWE-90 volgens MITRE. Richt zich op het hostbesturingssysteem in plaats van directoryservices.
• XPath-injectie (CWE-643): De OWASP LDAP-test groepeert XPath-injectie expliciet samen met LDAP-injectie als analoge authenticatieomzeilingstechnieken gericht op XML-gebaseerde datastores.
• Onjuiste neutralisatie van speciale elementen (CWE-77): De bovenliggende zwakte van CWE-90 in de MITRE-hiërarchie. Alle injectietypen komen voort uit deze algemene mislukking om interpreter-significante tekens te neutraliseren.
• Onjuiste codering of escaping van output (CWE-116): Documenteert de directe keten van escaping-falen naar injectie. CVE-2021-41232 toont de CWE-116 → CWE-90-keten waarbij een escaping-fout in een Go-applicatie direct LDAP-injectie mogelijk maakte.
• Onjuiste inputvalidatie (CWE-20): De hoofdoorzaak wanneer applicaties het invoerformaat niet valideren voordat LDAP-query’s worden opgebouwd.

Het bekijken van deze gerelateerde zwaktes helpt u dezelfde verdedigingsprincipes toe te passen in uw hele codebase, niet alleen in LDAP-specifieke codepaden.

Gerelateerde CVE’s

CVE-ID	Beschrijving	Ernst	Getroffen product	Jaar
CVE-2026-33289	LDAP-injectie in SuiteCRM stelt niet-geauthenticeerde aanvallers in staat zoekfilters te manipuleren, waardoor authenticatieomzeiling of informatielek mogelijk is	Kritiek (9.8)	SalesAgility SuiteCRM <7.15.1 / 8.0.0–8.9.2	2026
CVE-2026-25560	WeKan verwerkt niet-gesaniteerde gebruikersnamen in LDAP-zoekfilters en DN-waarden, waardoor niet-geauthenticeerde externe aanvallers LDAP-query’s kunnen manipuleren tijdens authenticatie	Kritiek (9.8)	WeKan Project WeKan <8.19	2026
CVE-2026-31828	Parse Server verwerkt door de gebruiker aangeleverde authData.id direct in LDAP Distinguished Names en groepszoekfilters, waardoor privilege-escalatie mogelijk is	Hoog (8.8)	Parse Platform parse-server <8.6.26	2026
CVE-2026-1498	LDAP-injectie in WatchGuard Fireware OS stelt niet-geauthenticeerde externe aanvallers in staat gevoelige informatie op te halen uit een verbonden LDAP-server	Hoog (7.0)	WatchGuard Technologies Fireware OS 12.0–12.11.6 / 12.5–12.5.15	2026
CVE-2026-21880	Kanboard verwerkt niet-gesaniteerde gebruikersinvoer direct in LDAP-zoekfilters, waardoor niet-geauthenticeerde aanvallers LDAP-gebruikers kunnen enumereren en gevoelige attributen kunnen ontdekken	Medium (5.3)	Kanboard Kanboard ≤1.2.48	2026
CVE-2024-54852	Teedy’s LDAP-ingeschakelde loginformulier staat niet-geauthenticeerde LDAP-injectie toe via het gebruikersnaamveld, waardoor willekeurige accountaanmaak en password spraying mogelijk is	Kritiek (9.8)	Sismics Teedy 1.9–1.12	2025
CVE-2025-48208	LDAP-injectie in Apache HertzBeat stelt een geauthenticeerde aanvaller in staat commando’s samen te stellen die leiden tot willekeurige scriptexecutie	Hoog (8.8)	Apache Software Foundation Apache HertzBeat ≤1.7.2	2025
CVE-2025-12764	Het injecteren van speciale LDAP-tekens in het gebruikersnaamveld van pgAdmin 4 zorgt ervoor dat de LDAP-server en client buitensporig veel data verwerken, wat leidt tot denial of service	Hoog (7.5)	PostgreSQL Global Development Group pgAdmin 4 <9.10	2025
CVE-2023-51446	Het LDAP-authenticatieformulier van GLPI kan worden gebruikt voor LDAP-injectie door niet-geauthenticeerde aanvallers, opgelost in versie 10.0.12	Hoog (8.1)	GLPI Project GLPI 0.70–<10.0.12	2024
CVE-2023-29050	Bevoorrechte gebruikers kunnen LDAP-filterstrings injecteren in de optionele LDAP-contactprovider van OX App Suite, waardoor toegang tot directory-inhoud buiten de bedoelde hiërarchie mogelijk is	Hoog (~8.0)	Open-Xchange OX App Suite <7.10.6	2024
CVE-2023-31025	NVIDIA DGX A100 BMC bevat een LDAP-gebruikersinjectiekwetsbaarheid die kan worden uitgebuit door aangrenzende niet-geauthenticeerde aanvallers, wat leidt tot informatielek	Medium (~6.5)	NVIDIA DGX A100 BMC	2024
CVE-2023-28853	De LDAP-loginquery van Mastodon is onveilig, waardoor geauthenticeerde aanvallers willekeurige attributen uit de LDAP-directory kunnen lekken	Hoog (7.7)	Mastodon Mastodon 2.5.0–4.1.1	2023
CVE-2022-46337	Een samengestelde gebruikersnaam omzeilt LDAP-authenticatie in Apache Derby, wat mogelijk leidt tot schijfuitputting, malware-executie en ongeautoriseerde database-toegang	Kritiek (9.8)	Apache Software Foundation Apache Derby ≤10.16.1.1	2022
CVE-2022-4254	SSSD’s libsss_certmap ontsmet certificaatdata niet die in LDAP-filters wordt gebruikt, waardoor een geauthenticeerde aanvaller LDAP-queryelementen kan injecteren en ongeautoriseerde toegang kan verkrijgen	Hoog (8.8)	Red Hat / SSSD Project SSSD	2022
CVE-2022-45910	Apache ManifoldCF geeft gebruikersnamen en domeintekens door aan LDAP-zoekquery’s zonder validatie in zijn ActiveDirectory-authority connectors	Medium (5.3)	Apache Software Foundation Apache ManifoldCF 0–2.23	2022
CVE-2021-41232	Thunderdome Planning Poker escapt gebruikersnamen niet vóór LDAP-query’s wanneer LDAP-authenticatie is ingeschakeld, waardoor niet-geauthenticeerde LDAP-injectie mogelijk is	Kritiek (9.8)	Thunderdome Planning Poker <1.16.3	2021
CVE-2021-39031	IBM Open Liberty’s ldapRegistry-3.0-feature bevat een LDAP-injectiekwetsbaarheid	Hoog (7.5)	IBM Open Liberty ldapRegistry-3.0 (v17.0.0.3–22.0.0.1)	2021
CVE-2021-29156	ForgeRock OpenAM staat LDAP-injectie toe via het Webfinger-protocol, waardoor niet-geauthenticeerde teken-voor-teken extractie van wachtwoordhashes of sessietokens mogelijk is	Hoog (geschat)	ForgeRock OpenAM <13.5.1	2021

Conclusie

LDAP-injectie geeft aanvallers een manier om onbetrouwbare invoer om te zetten in controle over de directorysystemen waarop uw omgeving vertrouwt voor authenticatie en toegang. Voor u betekent dat het risico zelden beperkt blijft tot één query of één applicatie. 

Als u query’s veilig opbouwt, waarden in de juiste context escapt, bindrechten beperkt en LDAP-activiteit nauwlettend in de gaten houdt, verkleint u zowel de blootstelling als de bewegingsruimte voor aanvallers.

Veelgestelde vragen

Wat is een LDAP Injection-kwetsbaarheid?

LDAP injection is een fout in de verwerking van invoer in software die LDAP-queries opbouwt uit niet-vertrouwde data. Een aanvaller kan wijzigen hoe de directory een query interpreteert, waardoor een logincontrole altijd waar wordt, een gerichte zoekopdracht wordt uitgebreid naar volledige directory-opsomming, of misbruik wordt gemaakt van toevoeg- en wijzigbewerkingen binnen de LDAP-boom.

Valt LDAP Injection onder de OWASP Top 10?

Ja. LDAP injection valt onder de bredere Injectie-categorie van OWASP en staat niet als een aparte Top 10-invoer vermeld. In de praktijk betekent dit dat u LDAP-ondersteunde code met dezelfde zorgvuldigheid moet beoordelen als bij SQL-injectie, omdat beide kwetsbaarheden ontstaan door niet-vertrouwde invoer die een interpreter bereikt.

Kan LDAP Injection op afstand worden misbruikt?

Ja. Als uw webgerichte loginformulier, zoekpagina, portaal of beheerinterface gebruikersinvoer doorstuurt naar een LDAP-backend, kan een aanvaller de exploitatie via het netwerk starten. 

In veel gevallen zijn geen geldige inloggegevens nodig om te beginnen met het testen op filtermanipulatie.

Welke typen applicaties zijn het meest kwetsbaar voor LDAP Injection?

De applicaties met het hoogste risico zijn diegene die LDAP gebruiken voor identiteitsbeslissingen: loginportalen en SSO-systemen, tools voor wachtwoordherstel en directory-zoekopdrachten, VPN-gateways en remote access-portalen, en legacy bedrijfsapplicaties die LDAP-queries opbouwen door tekenreeksen samen te voegen.

Hoe ontdekken aanvallers doorgaans LDAP Injection?

Aanvallers beginnen meestal met eenvoudige probes. Ze voeren LDAP-metatekens in zoals (, |, & en *, en letten op gewijzigde reacties, fouten of ongebruikelijke aantallen resultaten. 

Zodra ze de filterstructuur begrijpen, schakelen ze over op wildcard-, OR-gebaseerde of blinde extractie-payloads.

Wat zijn de eerste tekenen van misbruik van LDAP injection?

Vroege signalen zijn vaak metatekens in authenticatie- of zoekvelden, ongewoon brede LDAP-resultaatsets, )( of |( patronen in filters, een mislukte login direct gevolgd door succes, en bulk LDAP-queries vanaf een niet-geprivilegieerde host.

Hoe ernstig is LDAP Injection vergeleken met andere kwetsbaarheden?

Het is ernstig omdat LDAP vaak authenticatie en autorisatie regelt buiten een enkele applicatie. Een geslaagde injectie kan directorygegevens blootleggen, logincontroles omzeilen of lateral movement plannen in de hele omgeving mogelijk maken. 

Dat bereik maakt de zakelijke impact groter dan veel alleen-applicatiekwetsbaarheden.

Kan LDAP Injection leiden tot volledige systeemcompromittering?

Ja, vooral als eerste stap in een grotere identiteitsaanvalsketen. Een aanvaller kan van loginbypass of directory-opsomming overgaan naar het verzamelen van inloggegevens, het aanmaken van accounts, NTDS.dit-dumping en blijvende toegang met geldige accounts. 

De injectie is vaak het toegangspunt, niet het uiteindelijke doel.

Is LDAP Injection eenvoudig te detecteren met geautomatiseerde tools?

Tools helpen, maar lossen het probleem niet alleen op. Scanners en WAF-regels kunnen duidelijke gevallen vinden, terwijl blinde injectie en zwakke LDAP-logging moeilijker te detecteren blijven. 

Als u geen zicht heeft op LDAP-verkeer en querygedrag, kunt u de activiteit missen, zelfs als de exploitatie al aan de gang is.

Welke sectoren lopen het meeste risico op LDAP injection?

Sectoren met een sterke afhankelijkheid van gecentraliseerde identiteit dragen het hoogste concentratierisico. Het artikel noemt gezondheidszorg, financiële dienstverlening, overheid, kritieke infrastructuur en softwareplatforms. 

Wat deze sectoren gemeen hebben is het vertrouwen op LDAP-ondersteunde authenticatie voor gebruikers met hoge waarde, systemen en administratieve workflows.