Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerable to ldap injection #21

jtblin opened this issue May 22, 2015 · 2 comments


Copy link

commented May 22, 2015

The username is not filtered as per ldap specifications so the code seems to be vulnerable to ldap injection:


This comment has been minimized.

Copy link

commented Jun 3, 2015

Seems true to some extent, although the parameter is used only in search, the search fails if the result size is not one, and the search result together with provided password needs to successfully bind before the resulting object is returned to caller. Nevertheless I'll see if I find a good source on what characters (in addition to obvious *, |, and parentheses) need to be escaped.


This comment has been minimized.

Copy link

commented Jul 2, 2015

@vesse rfc4515 section 3, states the following:

The rule ensures that the entire filter string is a
valid UTF-8 string and provides that the octets that represent the
ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
0x29), "" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
backslash "" (ASCII 0x5c) followed by the two hexadecimal digits
representing the value of the encoded octet.

This simple escaping mechanism eliminates filter-parsing ambiguities
and allows any filter that can be represented in LDAP to be
represented as a NUL-terminated string. Other octets that are part
of the set may be escaped using this mechanism, for example,
non-printing ASCII characters.

For AssertionValues that contain UTF-8 character data, each octet of
the character to be escaped is replaced by a backslash and two hex
digits, which form a single octet in the code of the character. For
example, the filter checking whether the "cn" attribute contained a
value with the character "" anywhere in it would be represented as

As indicated by the rule, implementations MUST escape
all octets greater than 0x7F that are not part of a valid UTF-8
encoding sequence when they generate a string representation of a
search filter. Implementations SHOULD accept as input strings that
are not valid UTF-8 strings. This is necessary because RFC 2254 did
not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP
search filter is a string of UTF-8-encoded Unicode characters).

@vesse vesse closed this in 3feea43 Aug 14, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.