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.