Projects/OWASP Framework Security Project/Secure LDAP API Standard

This standard is designed to describe the properties that secure LDAP client APIs exhibit. APIs with these properties help developers, regardless of their skill or experience with LDAP, avoid the most common and serious vulnerabilities associated with developing LDAP client software.

Version: 0.1

Maintainer: Timothy D. Morgan

Properties of Safe LDAP Client APIs

Documents the Security Risks of LDAP Filter Injection

The API documentation should include a warning about the risks of LDAP filter injection. The warning should occur on pages associated with LDAP filters functionality so that it is hard for any programmer to miss. The warning maybe short (as little as one sentence), but should reference documentation that describes the risk of injections. Consider using LDAP injection or LDAP Injection Prevention Cheat Sheet as a reference.

Documents LDAP Bind Authentication Without Filter Queries

Many developers (perhaps the majority) using LDAP client libraries are trying to accomplish a simple task: authenticate users to their application by leveraging the directory server's password store. An effective way to do this can be to simply attempt an LDAP bind as the user that is trying to authenticate, using the password provided by the user. This process often does not require the use of LDAP filter expressions and avoids the risk of search filter injection. For this reason, API documentation should include a mention of this approach to help guide developers down a less error-prone path.

Provides an LDAP Filter Escape Function

Escaping special characters in LDAP filter expressions is well described in section 3 of RFC 4515. The API should provide a function which accepts a string (potentially containing LDAP filter special characters) and returns a string with the same string with any special characters appropriately escaped. For example, the string "Asterisk (*) is more beautiful than backslash (\)." would be converted to "Asterisk \28\2a\29 is more beautiful than backslash \28\5c\29.".

Provides LDAP Filter Syntax Templates

A "syntax template" is one way to offer an API to a developer which automatically encodes LDAP filter special characters in a safe-by-default way. Consider the pseudocode:

 result = LDAPFilterQuery("(&(objectClass=user)(firstName=*?*)(lastName=*?*))", [first_name, last_name])

In this hypothetical API, the developer provides a LDAP filter query template in the first argument and a list of values as the second argument. Each "?" that appears in the template is bound in order to the value in the list. The LDAPFilterQuery function is responsible for automatically encoding the values stored in first_name and last_name. Note how this is very similar to parameterized prepared statements in the realm of SQL.

An LDAP client API should provide either a system for filter syntax templates, or an abstract API (see next item), or both.

Provides an Abstract API for LDAP Filter Queries

An abstract LDAP filter API allows developers to construct a data structure or model within the caller's language which is then automatically translated by the API into a safe LDAP filter expression. Consider the pseudocode:

 result = LDAPFilterQuery(LDAPAnd({"objectClass":"user", "account":username}))

In this hypothetical API, if the username had a value "AcmeCorp\Bob", then the LDAP filter expression generated by the API might look like: (&(objectClass=user)(account=AcmeCorp\5cBob)) Note how this is somewhat similar to object-relational mappings (ORMs) in the realm of SQL.

An LDAP client API should provide either an abstract API, or a filter syntax template API (see previous item), or both.

Supports LDAP with StartTLS

Provide support for LDAP with the StartTLS extended operation, as defined in RFC 4513. In order to be effective (and avoid downgrade attacks), the API must provide callers with a way to require TLS be used on StartTLS connections. That is, if a developer opts for StartTLS as a communications security mechanism, then any remote server claiming that it does not support StartTLS will cause the client to close the connection without attempting a bind, search query, or any other transaction.

Supports LDAPS

While not technically a standard, it is common to use LDAP over SSL/TLS on TCP port 636 (a.k.a. "LDAPS"). Often "ldaps://..." URLs are used to specify this and providing support for it is recommended to give developers additional deployment options.

Enables SSL/TLS Certificate Validation by Default

Whether the LDAP client library is using StartTLS or LDAPS, the client library should properly validate server certificates by default. Server certificate validation should include, at a minimum, the following two steps:

• Validation that the server certificate is signed by a trusted certificate authority
• Validation that the server certificate's host name matches the host name that the developer provided

Developers may be given the option of disabling one or both of these validation steps, but once again, they should be enabled by default.

Documents the Customization of Trusted Certificate Authorities

The documentation should make it easy for developers to obtain the information they need (perhaps with links to external tutorials) in order to add a custom certificate to the list of trusted CAs that the library uses. Even if the LDAP library simply relies on the trusted CAs installed on a system-wide basis, this should be documented. It is common for internal SSL/TLS services to leverage an organization's internal certificate authority for authentication, so it is important that developers are pointed in the right direction on how to set this up client-side.

Documents the Risk of Disabling Certificate Validation

The documentation should contain simple warnings indicating to developers the risk of disabling certificate validation checks. Consider using the following text, or something similar:

Disabling certificate validation typically results in the loss of all communications security. In other words, the protections against tampering and information leakage that SSL/TLS provides are typically rendered completely ineffective when certificate validation isn't fully performed.

Grading

In order to compare the relative security of LDAP client APIs on different platforms, we use the following scoring system:

• 2 points: Documents the Security Risks of LDAP Filter Injection
• 1 point: Documents LDAP Bind Authentication Without Filter Queries
• 2 points: Provides an LDAP Filter Escape Function
• 3 points: Either Provides LDAP Filter Syntax Templates or Provides an Abstract API for LDAP Filter Queries
• 4 points: Provides LDAP Filter Syntax Templates and Provides an Abstract API for LDAP Filter Queries
• 3 points: Either Supports LDAP with StartTLS or Supports LDAPS
• 4 points: Supports LDAP with StartTLS and Supports LDAPS
• 3 points: Enables SSL/TLS Certificate Validation by Default
• 1 point: Documents the Customization of Trusted Certificate Authorities
• 2 points: Documents the Risk of Disabling Certificate Validation
• Bonus points or deductions may be assigned for relevant behaviors not otherwise described here.

Total Points	Grade
19	A+
17-18	A
16	A-
15	B+
13-14	B
12	B-
11	C+
9-10	C
8	C-
7	D+
5-6	D
4	D-
3 or fewer	F

TODO

• What other forms of encryption should we encourage? SASL and/or proprietary mechanisms?

• The LDAP injection page could use work. Some statements are a bit off base, and there should be a clearer statement of the risk.

• Review the LDAP Injection Prevention Cheat Sheet page to see if it needs work as well.

• Add other .NET APIs, such as http://blogs.msdn.com/b/securitytools/archive/2010/09/30/antixss_2d00_4_2d00_0_2d00_release_2d00_notes.aspx and/or https://linqtoad.codeplex.com/

• Add items related to DN escaping, separate from filters