Update: LDAP_Injection_Prevention_Cheat_Sheet #1372
Labels
ACK_OBTAINED
Issue acknowledged from core team so work can be done to fix it.
HELP_WANTED
Issue for which help is wanted to do the job.
UPDATE_CS
Issue about the update/refactoring of a existing cheat sheet.
What is missing or needs to be updated?
After a casual reading, the Cheat Sheet seems to suggests that even passwords should always be escaped. When this is taken at face value, it can cause all kinds of issues, mainly stuff not working as expected any more (see dexidp/dex#3433).
The
Safe Java Escaping Example
wrongly assumes that a password check against LDAP is done via LDAP filter and escapes the password, when actually password checking against an ldap server is (or at least should be) exclusively done via BIND request which safely accepts the password in unfiltered plaintext.How should this be resolved?
The usual methods for password authentication against LDAP should be mentioned:
uid=${USERID},ou=people,dc=example,dc=com
. Whatever is inserted in that template should be escaped as needed. Password from user input is given to BIND call as is.SEARCH
LDAP for users DN like(&(uid=${USERID})(deactivated=0))
or something. Again, anything inserted into that query should be escaped as neededThese two both assume the LDAP server to require (non-anonymous) BIND before allowing access to user data, which I think is (or should be) default or at least best practice. So
Enabling Bind Authentication
should be moved up in the document's focus, i.e. "To prevent LDAP Injection, first the LDAP server needs to be configured properly...". Even if it's out of scope of this document, proper safety precautions should be mentioned - "Simple BIND transmits plain text passwords to the server, so it should only be used with an encrypted connection" or "If you really need to use unencrypted connection, make sure to only use SASL BIND with challenge protocols etc. to prevent password sniffing."The
Safe Java Escaping Example
should be updated to reflect either one of the above methods and no longer use the password in a search filter.The text was updated successfully, but these errors were encountered: