LDAP Injection: How to Test Authentication and Directory Bugs
LDAP injection happens when untrusted input is concatenated into LDAP search filters or bind DNs. Metacharacters like *, (, ), and \ can change filter logic — sometimes bypassing authentication or exposing directory entries.
You still see it in corporate portals, VPN frontends, and older “employee lookup” tools.
Spot LDAP-backed features
- Login that talks to Active Directory / OpenLDAP
- People search, group membership pickers
- “Forgot password” that looks up corporate email
- Error messages mentioning LDAP, DN, or SamAccountName
Safe testing ideas
- On a search box, submit
*oradmin*)(|(password=*style probes only against systems you are authorized to test. - Watch for different result counts, timing, or error text.
- On login, try injecting filter OR logic carefully on your own account — never brute-force other employees’ passwords.
Blind LDAP injection can use boolean conditions and timing; keep volume low and stay in scope.
Impact ladder
- Search filter reveals extra entries you should not see
- Authentication bypass on a test account
- Attribute disclosure (email, groups) for users in a lab OU
Report tips
Show the raw filter shape (as inferred), the injected characters, and the directory data exposed for accounts you control. Recommend parameterized LDAP APIs and escaping per RFC 4515.
Defensive checklist
- Use LDAP APIs that bind parameters instead of string concatenation.
- Escape filter special characters.
- Least-privilege service accounts for directory binds.
- Separate customer auth from corporate LDAP where possible.
- Log and rate-limit directory queries.
LDAP injection is specialized — but when the directory is the source of truth for login, filter bugs become account bugs.
Original Bugflare guide informed by OWASP LDAP injection guidance.