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/bh-eu-08-alonso-parada-WP.pdf > > > 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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature