Improper sanitization of LDAP queries
This lesson is available in Python
What is LDAP injection?
LDAP injection is, at heart, quite similar to SQL injection. LDAP is a look-up protocol for information stored about an organization. It also has an authentication system, as much of this information can be confidential or private. However, if not implemented correctly, LDAP authentication can be circumvented and/or cause some nasty information disclosure problems.
About this lesson
In this lesson, you will learn how LDAP injection works and how to prevent the unauthenticated from becoming illegitimately authenticated. We will first inspect a sample Python program that is vulnerable to an LDAP injection attack, then explore how this vulnerability arises, its mutations, and how to prevent it from happening in your codebase.
The syntax for LDAP is derived from a notation called “Polish notation”, where the operator prefixes the operands. For example, if the operation were addition, then we would traditionally write
2 + 3, however, in Polish notation, this would be written as
+ (2 3).
Hacking into EvilCorp
EvilCorp has come to the realization that even evil companies need to keep track of all their employees. Outsourcing is hard (harder when you’re evil), so they have resorted to developing an internal tool to store information about their employees for them — and it uses LDAP!
Ironically, evil things even happen to evil companies, and a disgruntled employee (you, specifically) found their application to be vulnerable to LDAP injection.
- STEP 1
- STEP 2
- STEP 3
- STEP 4
- STEP 5
Setting the stage
Sitting down for your morning coffee, you want to know how much data EvilCorp has about you. You know the endpoint, so you start investigating.
Let’s take a look at what went wrong with EvilCorp’s backend.
How are LDAP queries constructed?
LDAP is a hierarchical information lookup protocol where the query parameters filter out content. As mentioned in the fun fact earlier, these LDAP queries are formatted using “Polish notation”. Comparisons in LDAP queries are of the form:
If we wanted to query an LDAP server for all information relating to Jedi who were either a “master” or who fought in the clone wars and are still alive, we could query a server with:
Breaking this query down, the operator (
|, which means or) comes first, followed by its two arguments. The first argument compares the input (right), with the category (jediType). The second argument is another operator, which checks to filter for all subjects who fought in the clone wars and are still alive. Darth Vader could probably find a use case for this query…
The LDAP search filters are so important they get their own RFC! Check out the details here.
Where does the vulnerability come in?
LDAP injection is similar in spirit to SQL injection because they both come from the same error: missing input sanitization! When user input is passed straight into an LDAP query without proper sanitization, then the user can make their own modifications to the query being made, and introduce their own logic!
This function retrieves the URL parameter
jediType and directly substitutes it into the LDAP search query. If you make a curl request to get master Jedis (or interact with a website that does this for you), then your request might look something like:
Which would produce the LDAP query we saw earlier:
However, if we instead submitted something a little bit different:
Then the request would look like:
This would then be interpreted by the LDAP server as a request for everything that matches any type of jedi or had any relation to the clone wars! I’m sure Vader wouldn’t want his lowly stormtroopers having access to his personal database, so how would he stop them doing so?
Sanitizing user input
Lucky for us, the remedy for LDAP injection is fairly simple: don’t blindly accept user input! To prevent LDAP injection, we escape the characters which would permit a user to modify the request.