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

Difference between revisions of "LDAP Injection Prevention Cheat Sheet"

Jump to: navigation, search
(Remove SQL and add LDAP TBA content)
m (Point to the official site)
(30 intermediate revisions by 3 users not shown)
Line 2: Line 2:
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
The Cheat Sheet Series project has been moved to [ GitHub]!
= Introduction  =
__TOC__{{TOC hidden}}
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:
Please visit [ LDAP Injection Prevention Cheat Sheet] to see the latest version of the cheat sheet.
# the lack of safer, parameterized LDAP query interfaces, and
# the widespread use of LDAP to authenticate users to systems.
Primary Defenses:
Additional Defenses:
=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:
* Michael Daw : "SQL Injection Cheat Sheet" - - Note: This link is dead so we disabled it, if it comes back, we'll relink it as it was a good article.
* Ferruh Mavituna : "SQL Injection Cheat Sheet" -
* RSnake : "SQL Injection Cheat Sheet-Esp: for filter evasion" -
'''Description of SQL Injection Vulnerabilities'''
* OWASP article on [[SQL Injection]] Vulnerabilities
* OWASP article on [[Blind_SQL_Injection]] Vulnerabilities
'''How to Avoid SQL Injection Vulnerabilities'''
* [[:Category:OWASP Guide Project|OWASP Developers Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities
* OWASP article on [[Preventing SQL Injection in Java]]
* OWASP Cheat Sheet that provides [[Query_Parameterization_Cheat_Sheet|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'''
* [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities
'''How to Test for SQL Injection Vulnerabilities'''
* [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities
= Authors and Primary Editors  =
[[User:wichers|Dave Wichers - dave.wichers]][at]<br/>
Jim Manico - jim[at]<br/>
Matt Seil - mseil[at] 
== Other Cheatsheets ==

Latest revision as of 14:16, 15 July 2019


The Cheat Sheet Series project has been moved to GitHub!

Please visit LDAP Injection Prevention Cheat Sheet to see the latest version of the cheat sheet.