curity, 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 users at various levels when assigning responsibilities. This, in turn, could mitigate the damage done in the event of an LDAP attack. An attacker can do less with a properly provisioned, low-level account than they can with one that has admin-level access, of course. Whatever your opinion of employees, giving them the least level of access possible to competently function in their roles should be your goal when assigning privileges and powers.
In the end, protecting against LDAP injection (or any other number of injection attacks) comes down to taking proper measures to stop it, and assuming those defenses will fail anyway. A solid one-two punch of defense and what-if planning, in other words, goes a heck of a long way. And if you know much about digital security, you know that basic idea applies no matter what you're defending against.
Photo Source: Flickr