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

Projects/OWASP Framework Security Project/Secure LDAP API Standard

From OWASP
Revision as of 02:16, 19 January 2016 by TimMorgan (talk | contribs) (Documents the Security Risks of LDAP Filter Injection)

Jump to: navigation, search

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.


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.

Provides an LDAP Filter Escape Function

Escaping special characters in LDAP filter expressions is well described in section 4 of RFC 2254. 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

TODO

Provides an Abstract API for LDAP Filter Queries

TODO

Supports LDAPS

TODO

Supports LDAP with StartTLS

TODO

Enables SSL/TLS Certificate Validation by Default

TODO

Documents the Customization of Trusted Certificate Authorities

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.