This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
LDAP Injection Prevention Cheat Sheet
Last revision (mm/dd/yy): 05/28/2015
Introduction
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:
- the lack of safer, parameterized LDAP query interfaces, and
- the widespread use of LDAP to authenticate users to systems.
TBA
Primary Defenses:
- TBA
Additional Defenses:
- TBA
Primary Defenses
Defense Option 1: TBA
TBA
- Safe Java TBA Example
TBA
- Safe C# .NET TBA Example
TBA
Defense Option 2: TBA
TBA
- Safe Java TBA Example
TBA
- Safe C# .NET TBA Example
TBA
Defense Option 3: Escaping All User Supplied Input
TBA
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:
- Ferruh Mavituna : "SQL Injection Cheat Sheet" - http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
- RSnake : "SQL Injection Cheat Sheet-Esp: for filter evasion" - http://ha.ckers.org/sqlinjection/
Description of SQL Injection Vulnerabilities
- OWASP article on SQL Injection Vulnerabilities
- OWASP article on Blind_SQL_Injection Vulnerabilities
How to Avoid SQL Injection Vulnerabilities
- OWASP Developers Guide article on how to Avoid SQL Injection Vulnerabilities
- OWASP article on Preventing SQL Injection in Java
- OWASP Cheat Sheet that provides numerous language specific examples of parameterized queries using both Prepared Statements and Stored Procedures
- The Bobby Tables site (inspired by the XKCD webcomic) has numerous examples in different languages of parameterized Prepared Statements and Stored Procedures
How to Review Code for SQL Injection Vulnerabilities
- OWASP Code Review Guide article on how to Review Code for SQL Injection Vulnerabilities
How to Test for SQL Injection Vulnerabilities
- OWASP Testing Guide article on how to Test for SQL Injection Vulnerabilities
Authors and Primary Editors
Dave Wichers - dave.wichers[at]owasp.org
Jim Manico - jim[at]owasp.org
Matt Seil - mseil[at]acm.org