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

Difference between revisions of "LDAP Injection Prevention Cheat Sheet"

From OWASP
Jump to: navigation, search
(Remove SQL and add LDAP TBA content)
(Least Privilege)
Line 58: Line 58:
 
== Least Privilege ==
 
== 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.
+
To minimize the potential damage of a successful LDAP injection attack, you should minimize the privileges assigned to the LDAP binding account in your environment.  
  
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.
+
TBA
 
 
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 ==
 
== White List Input Validation ==

Revision as of 08:12, 28 May 2015

Cheatsheets-header.jpg

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:

  1. the lack of safer, parameterized LDAP query interfaces, and
  2. 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 LDAP injection attack, you should minimize the privileges assigned to the LDAP binding account in your environment.

TBA

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]owasp.org
Jim Manico - jim[at]owasp.org
Matt Seil - mseil[at]acm.org

Other Cheatsheets