Difference between revisions of "Testing for LDAP Injection (OTG-INPVAL-006)"

From OWASP
Jump to: navigation, search
(Example 1. Search Filters)
Line 85: Line 85:
 
which is instantiated by an HTTP request like this:
 
which is instantiated by an HTTP request like this:
  
  http://www.example.com/ldapsearch?user=John
+
  <nowiki>http://www.example.com/ldapsearch?user=John</nowiki>
  
 
If 'John' value is replaced with a '*',
 
If 'John' value is replaced with a '*',
 
by sending the request:
 
by sending the request:
  
  http://www.example.com/ldapsearch?user=*
+
  <nowiki>http://www.example.com/ldapsearch?user=*</nowiki>
  
 
the filter will look like:
 
the filter will look like:

Revision as of 08:52, 7 November 2006

OWASP Testing Guide v2 Table of Contents

Brief Summary

LDAP is an acronym for Lightweight Directory Access Protocol.
It is a paradigm to store informations about users, hosts and many other objects.

LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified or inserted.
This is done by manipulating input parameters afterwards passed to internal search,add and modify functions.

Description of the Issue

A web application could use LDAP in order to let a user to login with his own credentials or search other users informations inside a corporate structure.

The primary concept on LDAP Injection is that in occurrence of an LDAP query during execution flow, it is possible to fool a vulnerable web application by using LDAP Search Filters metacharacters.

[Rfc2254] defines a grammar on how to build a search filter on LDAPv3 and extends [Rfc1960] (LDAPv2).

A LDAP search filter is constructed in Polish notation, also known as [prefix notation].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will result in:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an LDAP search filter could be applied by using the following metacharacters:

Metachar Meaning
& Boolean AND
| Boolean OR
 ! Boolean NOT
= Equals
~= Approx
>= Greater than
<= Lesser than
* Any character
() Grouping parenthesis

More complete examples on how to build a search filter could be found in related RFC.

A successful exploitation of LDAP Injection could allow the tester to:

  • Access unauthorized content
  • Evade Application restrictions
  • Gather unauthorized informations
  • Add or modify Objects inside LDAP tree structure.


Black Box testing and example

Example 1. Search Filters

Let's suppose we have web application using a search filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

http://www.example.com/ldapsearch?user=John

If 'John' value is replaced with a '*', by sending the request:

http://www.example.com/ldapsearch?user=*

the filter will look like:

searchfilter="(cn=*)"

which means every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection depending on LDAP connected user permissions and application execution flow it will be displayed some or all of users attributes.

A tester could use trial and error approach by inserting '(', '|', '&', '*' and the other characters in order to check the application for errors.

Example 2. Login

If a web application uses a vulnerable login page with LDAP query for user credentials, it is possible to bypass the check for user/password presence by injecting an always true LDAP query (in a similar way to SQL and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

user=*)(uid=*))(|(uid=*
 pass=password

the search filter will results in:

searchlogin="(&(uid=*)((uid=*))(|(uid=*))(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true. This way the tester will gain logged-in status as the first user in LDAP three.

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents OWASP Testing Guide v2 Table of Contents

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.