4 ms·

Buzz, wrong - no such thing as LDAP injection attacks, sorry.

viraptor 12y ago
Come on, it's just one google search away. https://www.owasp.org/index.php/LDAP_injection https://www.owasp.org/index.php/LDAP_injection (but confirms the "nobody knows LDAP" nicely) Unless you escape your "(cn=$username)" properly, the users can do a lot of fun things.
- hyc_symas 12y ago
  Nonsense. That page is utter tripe. The 2nd example " ( cn = jonys ) ( | (password = * ) ) " isn't even a valid filter, and a proper LDAP server will discard it. An OpenLDAP libldap-based app won't even be able to generate the request because the library will reject it. More importantly, an LDAP search filter only goes with an LDAP search request, which is read-only. You cannot use silly parser games like this to destroy a database, like you can in SQL with Little Bobby Tables. https://xkcd.com/327/ https://xkcd.com/327/ Playing games with LDAP search filters can't return you more information than the app was originally authorized to see. It most often won't even return you more than a single record, since most apps that make LDAP queries and expect only a single entry to be returned won't even look at any subsequent entries if they happen to be in the reply. Canonical LDAP application code to search for a user record, for authentication/authorization purposes, sets the LDAP search sizelimit to 1. Getting more than 1 matching result is an error.
  - viraptor 12y ago
    Uncommon - yes. Can do less than SQL injections - yes. Read-only - yes. But it does exist. Saying that LDAP auth[nz] code should set sizelimit to 1 is like saying SQL auth[nz] code should set LIMIT 1. Correct and defensive code does that. But there's still code out there which doesn't and is vulnerable. Then again, I don't think you understood the second example. It's not for auth, but rather user search - which is the probably the second most common corporate ldap usage. As for LDAP injection being nonsense, how about searching some CVEs: - LDAP injection and resulting STORED Cross Site Scripting in Events Planner - SmarterMail 7.x (7.2.3925) - https://www.exploit-db.com/exploits/15189/ https://www.exploit-db.com/exploits/15189/ - Graylog2 before 0.92 allows remote attackers to bypass LDAP authentication via crafted wildcards. - CVE-2014-9217 - PowerDNS before 2.9.18, when running with an LDAP backend, does not properly escape LDAP queries, which allows remote attackers to cause a denial of service (failure to answer ldap questions) and possibly conduct an LDAP injection attack. - CVE-2005-2301 And many many more...
    - hyc_symas 12y ago
      For user search you still would set a size limit, and a server admin would set a server-side size limit to avoid other resource hogging issues. I concede the point that there's poorly written code out there that is vulnerable. Still, to lump this into the label of "injection attack" along the lines of SQL injection attacks is grossly misleading. An SQL injection attack can cause destruction of data, invocation of arbitrary commands on the backend, and innumerable kinds of other mischief. A misparsed LDAP filter can do none of these things.

Come on, it's just one google search away. https://www.owasp.org/index.php/LDAP_injection https://www.owasp.org/index.php/LDAP_injection (but confirms the "nobody knows LDAP" nicely) Unless you escape your "(cn=$username)" properly, the users can do a lot of fun things.

hyc_symas 12y ago
Nonsense. That page is utter tripe. The 2nd example " ( cn = jonys ) ( | (password = * ) ) " isn't even a valid filter, and a proper LDAP server will discard it. An OpenLDAP libldap-based app won't even be able to generate the request because the library will reject it. More importantly, an LDAP search filter only goes with an LDAP search request, which is read-only. You cannot use silly parser games like this to destroy a database, like you can in SQL with Little Bobby Tables. https://xkcd.com/327/ https://xkcd.com/327/ Playing games with LDAP search filters can't return you more information than the app was originally authorized to see. It most often won't even return you more than a single record, since most apps that make LDAP queries and expect only a single entry to be returned won't even look at any subsequent entries if they happen to be in the reply. Canonical LDAP application code to search for a user record, for authentication/authorization purposes, sets the LDAP search sizelimit to 1. Getting more than 1 matching result is an error.
- viraptor 12y ago
  Uncommon - yes. Can do less than SQL injections - yes. Read-only - yes. But it does exist. Saying that LDAP auth[nz] code should set sizelimit to 1 is like saying SQL auth[nz] code should set LIMIT 1. Correct and defensive code does that. But there's still code out there which doesn't and is vulnerable. Then again, I don't think you understood the second example. It's not for auth, but rather user search - which is the probably the second most common corporate ldap usage. As for LDAP injection being nonsense, how about searching some CVEs: - LDAP injection and resulting STORED Cross Site Scripting in Events Planner - SmarterMail 7.x (7.2.3925) - https://www.exploit-db.com/exploits/15189/ https://www.exploit-db.com/exploits/15189/ - Graylog2 before 0.92 allows remote attackers to bypass LDAP authentication via crafted wildcards. - CVE-2014-9217 - PowerDNS before 2.9.18, when running with an LDAP backend, does not properly escape LDAP queries, which allows remote attackers to cause a denial of service (failure to answer ldap questions) and possibly conduct an LDAP injection attack. - CVE-2005-2301 And many many more...
  - hyc_symas 12y ago
    For user search you still would set a size limit, and a server admin would set a server-side size limit to avoid other resource hogging issues. I concede the point that there's poorly written code out there that is vulnerable. Still, to lump this into the label of "injection attack" along the lines of SQL injection attacks is grossly misleading. An SQL injection attack can cause destruction of data, invocation of arbitrary commands on the backend, and innumerable kinds of other mischief. A misparsed LDAP filter can do none of these things.