Wat is LDAP Injection? | Bescherming tegen deze Gevaarlijke Webaanval
Bij LDAP injection verandert een aanvaller een zoekopdracht door speciale tekens via gebruikersinvoer mee te sturen. Daardoor kan een toepassing meer gegevens teruggeven dan bedoeld, of onder bepaalde voorwaarden een toegangscontrole omzeilen. LDAP (Lightweight Directory Access Protocol) helpt toepassingen gegevens in een directory te zoeken en te beheren. Denk aan gebruikersnamen, groepen en zakelijke contactgegevens. Het protocol zelf is niet de oorzaak: onveilige verwerking van invoer maakt de aanval mogelijk.
Wat is LDAP Injection?
LDAP injection ontstaat wanneer een toepassing gebruikersinvoer rechtstreeks in een LDAP-filter of directorynaam plakt. De toepassing behandelt die invoer dan niet uitsluitend als tekst. Haakjes en andere speciale tekens kunnen de betekenis van de opdracht veranderen. Zo beïnvloedt een aanvaller welke gegevens de directory selecteert. Gebrekkige invoercontrole en onveilige programmeerkeuzes vormen samen de belangrijkste oorzaak.
Voor een zakelijke lezer lijkt dit op een zoekformulier dat stiekem extra zoekregels accepteert. Je verwacht één medewerker, maar de toepassing zoekt ineens naar een grotere groep. De aanvaller verandert dus de vraag die jouw toepassing aan de directory stelt. De toegangsrechten van het gebruikte account bepalen vervolgens welke informatie de server kan teruggeven.
LDAP injection is niet hetzelfde als het uitvoeren van geïnjecteerde programmacode. Bij code-injectie interpreteert een toepassing onbetrouwbare invoer als code. Dat kan leiden tot uitvoering van willekeurige code. Een LDAP-aanval verandert daarentegen meestal een directoryopdracht. Uitvoering van systeemcommando’s volgt daar niet automatisch uit; daarvoor is een aanvullende kwetsbaarheid of onveilige koppeling nodig.
Hoe werkt injectie in een LDAP-query?
Een webapplicatie kan een LDAP-directory raadplegen vanuit een loginformulier, personeelszoeker of beheerportaal. Ook URL-parameters, API-verzoeken en geïmporteerde bestanden kunnen invoer aanleveren. Omdat een aanvaller zulke waarden kan beïnvloeden, verdient elke invoerroute aandacht. Een verborgen veld is bijvoorbeeld niet automatisch betrouwbaar. De server moet de gegevens zelf controleren.
Een aanval verloopt in stappen. Eerst ontvangt de toepassing een waarde, zoals een gebruikersnaam. Daarna voegt onveilige programmacode die waarde aan een filter toe. Vervolgens leest de LDAP-server het complete filter als zoekopdracht. Zodra de invoer de filterstructuur verandert, voert de server mogelijk een andere selectie uit. Ten slotte verwerkt de toepassing de resultaten, soms zonder aanvullende toegangscontrole.
Onderstaand filter illustreert een normale zoekopdracht naar één account. Het attribuut uid bevat hier de gebruikersnaam. De exacte attribuutnamen hangen echter af van de inrichting van de directory.
(&(objectClass=person)(uid=voorbeeldgebruiker))Wanneer onveilige code een sterretje als zoekwaarde overneemt, kan dit filter ontstaan:
(&(objectClass=person)(uid=*))De ster betekent hier dat het attribuut aanwezig moet zijn, in plaats van exact één gebruikersnaam te selecteren. Hierdoor kan de zoekopdracht meerdere accounts vinden. Dit eenvoudige voorbeeld van LDAP injection toont filtermanipulatie, geen volledige inbraak. Een veilige toepassing behandelt een ingevoerde ster als letterlijke tekst wanneer vrije zoekpatronen niet zijn toegestaan. Test dit uitsluitend in een eigen, afgeschermde testomgeving.
Risico’s van injectie in LDAP-zoekopdrachten
De gevolgen van LDAP injection hangen af van de toepassing, de directoryrechten en de verwerking van zoekresultaten. Een breed zoekresultaat geeft niet vanzelf beheerdersrechten. Toch kan een verkeerde aanname in de applicatie een beperkte fout ernstig maken. Let vooral op deze gevolgen:
- Aanvallers kunnen onbevoegd gegevens inzien, zoals namen, e-mailadressen en groepslidmaatschappen, als het directoryaccount die mag lezen.
- Een toepassing kan authenticatie verkeerd beoordelen wanneer zij een zoekresultaat als bewijs voor een geldig wachtwoord beschouwt.
- Onveilige schrijfbewerkingen kunnen directorygegevens veranderen, mits de toepassing zulke bewerkingen aanbiedt en het account voldoende rechten heeft.
- Onterecht toegekende toegang kan interne systemen blootstellen die op hetzelfde account of dezelfde groepsinformatie vertrouwen.
- Een incident kan bedrijfsprocessen verstoren en onderzoek naar datalekken vereisen, terwijl medewerkers tijdelijk geen toegang hebben.
Wachtwoorden uitlezen is geen standaardgevolg van LDAP injection. Directorydiensten geven wachtwoorden niet zomaar als leesbare zoekresultaten terug. Bovendien begrenzen toegangsrechten welke attributen beschikbaar zijn. Beoordeel het risico daarom aan de hand van de werkelijke inrichting, niet uitsluitend op basis van een foutmelding.
LDAP-query’s tegen injectie beschermen
De belangrijkste verdediging tegen LDAP injection is een duidelijke scheiding tussen invoer en querystructuur. Alleen verdachte tekens verwijderen is onvoldoende. Combineer veilige opbouw van opdrachten met beperkte rechten en gerichte tests. Controleer daarbij ook oudere onderdelen die dezelfde directory gebruiken.
1. Controleer invoer en escape per context
Leg vast welke tekens en lengtes bij elk veld passen. Een personeelsnummer vraagt immers om andere regels dan een volledige naam. Gebruik daarnaast de escapingfunctie van je LDAP-bibliotheek voor filterwaarden. Voor een distinguished name (DN), de naam van een directoryobject, gelden andere regels. Wissel deze functies niet uit. Simpelweg alle leestekens wissen kan geldige namen beschadigen en biedt geen betrouwbare bescherming.
2. Kies een veilige querybouwer
Gebruik een bibliotheek die LDAP-filters veilig opbouwt en waarden afzonderlijk verwerkt. Anders dan bij SQL biedt niet elke LDAP-bibliotheek voorbereide query’s met parameterbinding. Controleer dus welke garanties jouw hulpmiddel werkelijk geeft. Vermijd handmatig samenvoegen van strings. Voor authenticatie hoort de toepassing een passende bindprocedure te gebruiken, niet een wachtwoordvergelijking in een zoekfilter. Laat lege wachtwoorden expliciet afwijzen.
3. Beperk de toegang tot gevoelige gegevens
Geef het toepassingsaccount alleen de leesrechten die het nodig heeft. Sta schrijfrechten uitsluitend toe voor concrete beheertaken. Zo beperk je de schade wanneer LDAP injection toch mogelijk blijkt. Controleer tevens de toegang binnen de toepassing: een geldig zoekresultaat bewijst niet dat iemand alle gevonden gegevens mag bekijken. Lees meer over fouten in toegangscontrole als die scheiding ontbreekt.
4. Monitor en log verdachte activiteiten
Registreer mislukte zoekopdrachten, opvallend brede resultaten en afwijkende aanmeldpogingen. Koppel gebeurtenissen aan tijdstippen en verzoekkenmerken, zodat je patronen kunt onderzoeken. Neem geen wachtwoorden of volledige gevoelige zoekresultaten op in logs. Geef bezoekers een algemene foutmelding; bewaar technische details uitsluitend op een afgeschermde plek. Spreek ook af wie waarschuwingen beoordeelt en opvolgt.
5. Versleutel de verbinding
Gebruik TLS voor de verbinding met de directory, bijvoorbeeld via LDAPS of correct ingestelde StartTLS. Controleer daarbij het servercertificaat. LDAPS is geen nieuwere LDAP-versie, maar LDAP via een versleutelde verbinding. Versleuteling beschermt het transport; zij herstelt geen onveilig filter. Zelfs een perfect versleutelde verbinding kan een gemanipuleerde opdracht doorgeven.
Praktijkvoorbeelden van injectie via LDAP
Onderstaande situaties laten zien waar een ontwikkelaar gericht kan controleren. Het zijn mogelijke foutpatronen, geen bewijs dat elke directorytoepassing kwetsbaar is. Onderzoek bovendien de verwerking ná de zoekopdracht. Juist daar kan een onschuldige zoekafwijking omslaan in ongeoorloofde toegang.
- Een personeelszoeker verwacht één naam. Door ontbrekende escaping krijgt de gebruiker echter ook resultaten buiten die exacte zoekwaarde.
- Een loginformulier beschouwt ieder gevonden account als een geslaagde aanmelding. Daardoor kan filtermanipulatie de verkeerde authenticatielogica blootleggen.
- Een beheerportaal verwerkt een onbetrouwbare directorynaam. Als het serviceaccount ruime schrijfrechten heeft, kunnen onbedoelde wijzigingen volgen.
Maak voor een veilige ontwikkelreview een overzicht van alle plekken die LDAP aanspreken. Volg elke invoerwaarde tot aan het filter of de directorynaam. Controleer vervolgens de gebruikte escapingfunctie en de accountrechten. Test normale namen, speciale tekens, lege invoer en onverwachte lengtes met fictieve accounts. Leg het verwachte resultaat vooraf vast. Zo controleer je na een reparatie of de toepassing correct blijft werken.
Signalen van injectie in LDAP-query’s herkennen
LDAP injection kan opvallen door een combinatie van technische signalen en onverwacht gedrag. Eén vertraging bewijst niets, want ook een drukke server kan traag reageren. Vergelijk afwijkingen daarom met normale activiteit. Onderzoek vooral herhaalde patronen rond dezelfde invoervelden.
- Onverwachte filterfouten verschijnen kort na invoer met speciale tekens, terwijl gewone zoekwaarden wel werken.
- Opvallend grote zoekresultaten passen niet bij de ingevoerde naam of de bedoelde zoekfunctie.
- Afwijkende aanmeldingen vallen samen met ongebruikelijke zoekverzoeken of onverwachte wijzigingen in directorygegevens.
Vermoed je misbruik? Bewaar relevante logs en beperk zo nodig de getroffen functie of het toepassingsaccount. Laat een beheerder onderzoeken welke gegevens bereikbaar waren. Herstel daarna de invoerverwerking en test de toegangscontrole opnieuw. Verander betrokken inloggegevens wanneer het onderzoek daar aanleiding toe geeft. Alleen een foutmelding verbergen neemt de kwetsbaarheid niet weg.
Veelgestelde vragen
Deze antwoorden vatten de belangrijkste verschillen en beschermingsmaatregelen samen.
Is LDAP zelf onveilig?
LDAP is niet automatisch onveilig. Het probleem ontstaat wanneer een toepassing onbetrouwbare invoer onderdeel laat worden van een directoryopdracht. Veilige filteropbouw en passende toegangsrechten beperken dat risico. Daarnaast beschermt TLS de verbinding tegen afluisteren. Die maatregelen hebben verschillende doelen: versleuteling vervangt geen veilige invoerverwerking.
Beschermt LDAPS tegen gemanipuleerde zoekfilters?
Nee, LDAPS voorkomt LDAP injection niet. Het versleutelt de verbinding tussen toepassing en directoryserver, maar verandert de inhoud van een onveilig opgebouwd filter niet. De server kan nog steeds de gemanipuleerde opdracht ontvangen. Gebruik naast versleuteling geschikte escapingfuncties, veilige queryopbouw en een toepassingsaccount met beperkte rechten.
Kunnen aanvallers hiermee wachtwoorden uitlezen?
Dat volgt niet automatisch uit een gemanipuleerd zoekfilter. Welke gegevens beschikbaar zijn, hangt af van directoryrechten en de opgeslagen attributen. Wachtwoorden verschijnen niet zomaar als leesbare zoekresultaten. Wel kan een toepassing authenticatie verkeerd afhandelen, bijvoorbeeld wanneer zij ieder gevonden account als een geldige aanmelding beschouwt. Controleer die logica afzonderlijk.
Conclusie
LDAP injection ontstaat door onveilige verwerking van invoer, niet doordat LDAP op zichzelf onbruikbaar is. Houd zoekwaarden gescheiden van de filterstructuur en controleer rechten op directorygegevens. Combineer dit met versleutelde verbindingen en gerichte monitoring. Daarmee pak je zowel de oorzaak als mogelijke gevolgen aan.
Begin bij de formulieren en koppelingen die jouw directory raadplegen. Laat een ontwikkelaar de queryopbouw beoordelen en betrek de beheerder bij de accountrechten. Test reparaties met fictieve gegevens voordat je ze doorvoert.
Een veilig zoekfilter én beperkte rechten vormen samen de basis van een goed beschermde directory.
