Millions of accounts compromised because there is no specialised user database • Hacker News Board

Post by hyc_symas » Thu, Apr 23, 2015, 3:43 AM UTC

viraptor wrote: post #60

hyc_symas wrote: post #58

Earlier quoted context omitted.

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 des…

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 t…

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.