Howard Chu wrote:
A paper and presentation making the rounds, claiming to show how webapps using LDAP are vulnerable to search filter spoofing attacks.
http://www.youtube.com/watch?v=wtahzm_R8e4 http://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/...
Can't imagine that work like this gets peer-reviewed, because it's mostly garbage. They concoct a scenario in section 4.1.1 of their paper, supposedly showing how filter manipulation can allow a webapp user to bypass LDAP-based authentication. It's ridiculous drivel though, since LDAP-based authentication uses Bind requests and not search filters. Most LDAP deployments don't even give search/compare access to userPassword attributes in the first place.
Well, this is not really new: https://www.owasp.org/index.php/LDAP_injection
Anyway, the paper is a bit bloated and the term "code injecting" sounds really over-loaded here.
SQL injection attacks are generally much more powerful since an attacker can also write data. Compared to that manipulating search requests with LDAP filter injection is not such a massive attack vector.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access.
Ack, but ACLs only protect what's stored inside the LDAP server.
There could be possible attacks when mapping username to wrong user entry or when reading access control data from wrong LDAP entries based on user's input which protects other app data.
Ciao, Michael.