This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

LDAP Injection Prevention Cheat Sheet

Revision as of 08:10, 28 May 2015 by Vanderaj (talk | contribs) (Remove SQL and add LDAP TBA content)

Jump to: navigation, search

Last revision (mm/dd/yy): 05/28/2015


This article is focused on providing clear, simple, actionable guidance for preventing LDAP Injection flaws in your applications. LDAP Injection attacks are somewhat common, and this is due to two factors:

  1. the lack of safer, parameterized LDAP query interfaces, and
  2. the widespread use of LDAP to authenticate users to systems.


Primary Defenses:

  • TBA

Additional Defenses:

  • TBA

Primary Defenses

Defense Option 1: TBA


Safe Java TBA Example


Safe C# .NET TBA Example


Defense Option 2: TBA


Safe Java TBA Example


Safe C# .NET TBA Example


Defense Option 3: Escaping All User Supplied Input


Additional Defenses

Beyond adopting one of the three primary defenses, we also recommend adopting all of these additional defenses in order to provide defense in depth. These additional defenses are:

  • Least Privilege
  • White List Input Validation

Least Privilege

To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.

If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts to directly execute their own queries, then restrict those accounts to only be able to execute the stored procedures they need. Don’t grant them any rights directly to the tables in the database.

SQL injection is not the only threat to your database data. Attackers can simply change the parameter values from one of the legal values they are presented with, to a value that is unauthorized for them, but the application itself might be authorized to access. As such, minimizing the privileges granted to your application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not trying to use SQL injection as part of their exploit.

While you are at it, you should minimize the privileges of the operating system account that the DBMS runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS account to something more appropriate, with restricted privileges.

White List Input Validation

Input validation can be used to detect unauthorized input before it is passed to the SQL query. For more information please see the Input Validation Cheat Sheet.

Related Articles

SQL Injection Attack Cheat Sheets

The following articles describe how to exploit different kinds of SQL Injection Vulnerabilities on various platforms that this article was created to help you avoid:

Description of SQL Injection Vulnerabilities

How to Avoid SQL Injection Vulnerabilities

How to Review Code for SQL Injection Vulnerabilities

How to Test for SQL Injection Vulnerabilities

Authors and Primary Editors

Dave Wichers - dave.wichers[at]
Jim Manico - jim[at]
Matt Seil - mseil[at]

Other Cheatsheets