In some ways, all injection attacks are the same. The hacker puts code in some form of user input field, attempting to trick the machines on the other end into granting information or access they shouldn't. If successful, the hacker then uses these ill-gotten gains to carry out damaging attacks like information theft, browser/session hijacking, site defacement, and so on.
But the devil is in the details. Being well-defended against one form of injection attack (think SQL injection or cross-site scripting) doesn't mean you have them all licked.
Enter LDAP injection. By abusing flaws in a "widely used open-standard protocol" known as LDAP, according to one CA Veracode resource on the attack, hackers and data thieves can cause all sorts of drama, granting "bad" queries escalated permissions and viewing/modifying information within given LDAP trees. And that's just the start.
Like many popular open-source components, LDAP (short for Lightweight Directory Access Protocol) gets so much love because it makes jobs easier. In this instance, the protocol is designed to facilitate access to information and the apps containing it; in corporate settings, for instance, it can be used for single sign-on, giving employees access to multiple apps within the corporate intranet without requiring them to sign in multiple times.
On a conceptual level, this sounds like a great idea. And if it works securely (more on that below), it absolutely is. Considering the number of systems that even junior employees must sign into to perform their daily tasks these days, anything that promotes large-scale efficiency can save large-scale dollars. Instead of requiring separate logins for timecard applications, POS applications, account credit applications, PTO-request applications, and so on, the company only pays for a single button click's worth of productivity.
The problems start when you consider the flip side of all that convenience. Given the ease of access of an insecure LDAP system and the relative lack of skill needed to bypass faulty security, an attacker who gains the ability to read or modify information in an important database suddenly has access to every system, app, and bit of info that LDAP setup touches.
Moreover, a number of attack vectors fall under the LDAP injection banner, meaning attackers may approach an insecure LDAP system any number of ways: They could insert malicious code that lets them view all usernames and passwords assigned to the system, for example, or they might be able to add themselves to that system as administrators or bypass the requirement for usernames and passwords altogether. The attacker's ability, the system's security measures, and several other factors come into play when deciding exactly what angle to approach from — but in any event, a successful injection generally means a big win for the hacker and a major headache for the company trying to keep systems and info secure.
As with other methods of injection, attackers rely on user input — that is, fields where users can directly or indirectly interface with hardware on the other end by signing in, querying information and so on — to pull off an LDAP attack. This, in turn, points to the single most important idea organizations can consider when protecting systems against injection attacks, one so important it deserves its own paragraph:
In practice, this idea takes several forms. The above-linked CA Veracode resource strongly suggests limiting what types of characters users can input; if you take away all non-letter-and-number symbols in areas that won't require that sort of input anyway, you vastly reduce the number of inroads attackers can take to your protected data.
Outgoing data should be subject to similar levels of scrutiny, a truism for protection against any sort of injection attack: If an attacker's end goal is accessing a list of all usernames or passwords within a given database, restricting the amount of data your system is able to return could stop them cold.
Along these lines, LDAP users must strongly consider the permissions they allow use