Revision as of 15:50, 19 January 2016

This standard is designed to describe the specific properties secure LDAP APIs have. 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

Properties of Safe LDAP 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 the LDAP Bind Without Filter Queries

TODO

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 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 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 extension, 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

TODO

Documents the Risk of Disabling Certificate Validation

TODO

Grading Scale

TODO

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.