Home / Knowledge hub / LDAP injection
Knowledge hub
LDAP injection
Input that alters a directory lookup, such as a sign-in or user search.
What it means
LDAP is a protocol for querying a directory of people and resources, and many companies use one for staff sign-in and address books. LDAP injection happens when user input is pasted into the search filter, so the input can change the filter itself and not just fill in a value.
It is close kin to SQL injection, with a different query language. The attacker adds filter characters such as brackets, asterisks and logical operators, and the directory answers a question the developer never wrote. The application is the one that asked it.
Why it matters
Directories hold usernames, email addresses, groups and sometimes sensitive attributes. A successful injection can let someone sign in without a valid password, list accounts they should not see, or find which groups an account belongs to. MITRE tracks the weakness as CWE-90.
Because directories sit behind sign-in and staff tools, the damage tends to be to identity. A forged match on a login filter is an authentication bypass, and a wildcard search may leak a full staff list that helps with later phishing.
How it shows up
You meet it in login forms backed by a directory, internal portals, user and group search boxes, and single sign-on integrations with a custom filter. The classic mistake is building a filter string like (uid=INPUT) by plain concatenation, so that input containing a closing bracket and an extra condition changes the meaning.
Escape special filter characters according to RFC 4515, or better, use an API that takes values as parameters. Validate input against an allowlist of expected characters, bind with a low-privilege account, and never use the directory's own errors in responses. Test with filter characters. See injection and input validation.
Questions people ask
LDAP injection, answered
Is LDAP injection the same as SQL injection?
It works on the same idea, input changing a query, but it targets a directory and uses a different syntax. The defences are alike: keep data separate from the query, and escape or parameterise.
Fixing one does not fix the other.
Which characters are dangerous in an LDAP filter?
The special characters in a filter are the asterisk, the opening and closing brackets, the backslash and the null character. RFC 4515 explains how to escape each one.
Distinguished names have their own, slightly different set of rules in RFC 4514.
Can LDAP injection bypass login?
Yes, when a sign-in check builds its filter from the typed username and password. A crafted value can make the filter match without a correct password.
Test your sign-in form with filter characters to find out.
Does using Active Directory make us immune?
No. Active Directory is one LDAP directory. If your own application builds a filter from user input, it can be injected.
The risk comes from the code that talks to the directory.
How do we test for LDAP injection?
Enter filter characters in sign-in and search fields and compare the responses to normal input. Different results, errors or extra records suggest the filter is being altered.
Confirm with a harmless query that returns data you should not see.
Related
Terms that sit next to this one
Injection
Input that ends up running as a command instead of being read as text.
SQL injection
Input a database ends up running as part of a query.
XPath injection
Input that changes an XPath query run against XML data.
Identity provider (IdP)
The service that signs people in and tells your app who they are.
Input validation
Checking that what arrives is the shape and range you expected.
Can a search box rewrite the filter?
Directory lookups behind sign-in and search are easy to forget. We test those inputs and report what changed in the response, with the request that shows it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.