What is LDAP Injection?
LDAP injections allow threat actors to compromise the authentication process of certain websites. This vulnerability occurs in websites that use data provided by end users to construct lightweight directory access protocol (LDAP) statements.
LDAP directories are used to store access credentials in the form of objects. The information may be used by a wide range of entities, including users, roles, printers, and servers. When LDAP directories are used for website authentication purposes, threat actors can inject malicious code into user input fields. The actor can then gain unauthorized access to the LDAP directory, where the actor can view or modify usernames and passwords.
Impact of LDAP injection attacks
Successful LDAP injections can cause major security breaches, resulting in data loss, damage to the reputation of the organization, and financial losses. Attackers can leverage LDAP injection to steal data, perform session or browser hijacking, and deface of websites.
Additionally, attackers may use LDAP injection attacks to insert malicious software (malware), which enables them to view user credentials. Attackers may also use this malware to add their own user account to a group of administrators.
How Does an LDAP Injection Attack Work?
Applications that use LDAP interact with the LDAP server both on the front end and the back end. LDAP search filters are the LDAP queries which are submitted to the server from the front-end of the application. Filters are built using of prefix notation—for example, here is an LDAP search filter:
The notation of the prefix filter tells the query to locate an LDAP node with the given password and username. Let’s take a situation where this query is created by appending the password and username strings taken from an HTML form.
If these values are controlled by the user, are appended to the search filter of the LDAP, without any sanitization or validation. For example, a password and username value of “*” will change the intended interpretation of the query and will return a record of all users.
Other characters may also be used to construct malicious queries. For example, in the query below, the highlighted condition will evaluate as true every time. If this query is employed in an authentication flow, a hacker can bypass authentication measures, because the second part of the statement, requiring a password, will not be evaluated.
Examples of LDAP Injection Attacks
Here are common examples showing how attackers can perform LDAP injection against vulnerable systems.
Access Control Bypass
Consider an LDAP search filter that accepts two fields via a web form—USER and PASSWORD:
If the LDAP filter accepts the USER parameter as is, with no sanitization of control characters, an attacker can input a username followed by control characters that break authentication. For example, if the attacker provides this as the USER value:
The LDAP query is constructed as follows:
This causes the LDAP server to only process the first part of the query, indicated in bold. The password is not evaluted at all, meaning the attacker can provide any string for password, and gain access.
Elevation of Privileges
Consider an LDAP search filter that enforces privileges at the end of a query. For example, a query like the following can be used to display all files in a directory, which are allowed for “guest” level permission:
The user provides the value files for the directory parameter, and the system inputs guest as the value for the permission parameter. Similar to the previous example, the attacker can craft a value for the directory parameter that will render the second parameter ineffective.
Suppose the attacker provides this value for the directory parameter:
This will construct the following LDAP filter:
The LDAP server processes only the first part of the filter, indicated in bold. It sets the permission level to “*”, meaning that all files in the directory will be displayed, elevating the attacker’s privileges. The last part of the query, limiting permission to guest, is ignored.
Information Disclosure
Consider an LDAP filter that lists specific resources available in the system (for example, workstations or printers on a network). The query looks like this:
If the attacker adds the string uid = * to their query, they can trick the server into listing all the available resources. The attacker provides this value for the Resource1 parameter:
And any value for Resource2. This results in the following query:
The LDAP server applies the OR operator to the two statements indicated in bold, and returns a list of all workstations on the network.
Preventing LDAP Injection Attacks
LDAP injection vulnerabilities take place when there is insufficient input cleanup and validation, and queries are created from input that is untrustworthy.
Here are a few ways you can protect your organization from LDAP Injection vulnerabilities:
- Ensure adequate encoding—as is the case with different injection attacks, it is critical that there is adequate encoding at the application layer and rigorous login validation, to stop LDAP injection vulnerabilities.
- Sanitize inputs—each user input employed within LDAP queries has to be sanitized in keeping with application stipulations, and every LDAP special characters, including ( ) ! | & * have to be safely encoded.
- Avoid special characters—for maximum security, do not use special characters at all in your queries, and avoid combining LDAP filters.
- Use a whitelist—before you include an untrustworthy entry in LDAP queries, the entry should be validated in contrast to a whitelist of permitted characters or strings (for example, a user name should be examined against a list of known users). This verification must alway be carried out on the server side, even if the input has previously been authenticated on the client side.
- Escape all user input if possible—to avoid input strings controlled by the user, which may include control characters, escape all characters provided by a user. For instance, with a Java application, you can use backslashes as escape characters. This means that untrusted user entries are included in the search filter as literal string values, rather than logical LDAP statements.
- Use directory authorization—this technique strives to limit the impact of any attempts at injection by minimizing privileges. The LDAP account used for mounting an application directory should have the minimal privileges required from the application. This means that even if the application is compromised via injection, it will not grant the attacker unlimited access to the underlying host machine.
- Write test scripts—when creating software that includes LDAP queries, your team must ensure that LDAP injection does not affect them. Write LDAP injection test scripts as part of any application code that integrates with LDAP, and do not release a new version of the application until those tests pass.
LDAP Injection with Imperva
Imperva provides the industry-leading Web Application Firewall, which can prevent LDAP injection and many other attacks against your web applications.
Beyond LDAP injection protection, Imperva provides comprehensive protection for applications, APIs, and microservices:
Runtime Application Self-Protection (RASP) – Real-time attack detection and prevention from your application runtime environment goes wherever your applications go. Stop external attacks and injections and reduce your vulnerability backlog.
API Security – Automated API protection ensures your API endpoints are protected as they are published, shielding your applications from exploitation.
Advanced Bot Protection – Prevent business logic attacks from all access points – websites, mobile apps and APIs. Gain seamless visibility and control over bot traffic to stop online fraud through account takeover or competitive price scraping.
DDoS Protection – Block attack traffic at the edge to ensure business continuity with guaranteed uptime and no performance impact. Secure your on premises or cloud-based assets – whether you’re hosted in AWS, Microsoft Azure, or Google Public Cloud.
Attack Analytics – Ensures complete visibility with machine learning and domain expertise across the application security stack to reveal patterns in the noise and detect application attacks, enabling you to isolate and prevent attack campaigns.
Client-Side Protection – Gain visibility and control over third-party JavaScript code to reduce the risk of supply chain fraud, prevent data breaches, and client-side attacks.
