Which method uses user-controlled values to influence LDAP statements and access directory data?

Which method uses user-controlled values to influence LDAP statements and access directory data?

• A. LDAP Directory Services
• B. LDAP Injection
• C. Server-side Template Injection
• D. HTML Embedding

Answer: (B)

LDAP injection happens when user-supplied values are inserted into LDAP search filters without proper validation, allowing the input to influence the LDAP statements and the data that is accessed. LDAP queries rely on filters to determine which directory entries to return, so if input is not sanitized, an attacker can break out of the intended filter and append additional conditions that change the query’s logic. This can lead to bypassing authentication or exposing sensitive directory data. For example, if an application builds a filter like (&(objectClass=person)(uid={user})), a malicious input could effectively modify the filter to introduce an always-true condition or reveal more entries, causing broader access than intended. This vulnerability is specifically about manipulating LDAP queries, not just using LDAP in general, which is why LDAP injection is the correct concept. Other options refer to broader LDAP services, templating weaknesses, or HTML content embedding, which don’t capture the specific risk of altering LDAP statements through attacker-controlled input. To prevent this, validate and escape user input for LDAP, use parameterized queries or safe query builders, and apply principle of least privilege.

LDAP injection happens when user-supplied values are inserted into LDAP search filters without proper validation, allowing the input to influence the LDAP statements and the data that is accessed. LDAP queries rely on filters to determine which directory entries to return, so if input is not sanitized, an attacker can break out of the intended filter and append additional conditions that change the query’s logic. This can lead to bypassing authentication or exposing sensitive directory data.

For example, if an application builds a filter like (&(objectClass=person)(uid={user})), a malicious input could effectively modify the filter to introduce an always-true condition or reveal more entries, causing broader access than intended. This vulnerability is specifically about manipulating LDAP queries, not just using LDAP in general, which is why LDAP injection is the correct concept.

Other options refer to broader LDAP services, templating weaknesses, or HTML content embedding, which don’t capture the specific risk of altering LDAP statements through attacker-controlled input. To prevent this, validate and escape user input for LDAP, use parameterized queries or safe query builders, and apply principle of least privilege.