LDAP Injection: Bypassing Auth Through the Directory

An enterprise app authenticates users against Active Directory. The login builds an LDAP search filter to find the matching account:

const filter = `(&(uid=${username})(userPassword=${password}))`;
client.search('ou=people,dc=corp,dc=com', { filter });

An attacker logs in with the username *)(uid=*))(|(uid=* and any password. The filter becomes a different query than you wrote — the injected parentheses and wildcards restructure it so it matches the first account in the directory, and they're authenticated. This is LDAP injection, and it works for the same reason SQL and NoSQL injection do: user input became part of the query's structure instead of staying inside it as data.

How the filter grammar gets abused

LDAP search filters are a small prefix-notation language. (uid=jsmith) is an equality match; (&(a)(b)) is "a AND b"; (|(a)(b)) is "a OR b"; and * is a wildcard. When you paste raw input between the parentheses, the attacker gains access to all of that syntax:

• * — wildcard. uid=* matches every user. A password field of * can match any stored value in a naive filter.
• ) and ( — close your clause early and open a new one, letting the attacker append their own conditions.
• | and & — inject OR/AND logic to loosen an AND-based auth check into something that always matches.

The canonical auth-bypass payload *)(uid=*))(|(uid=* does exactly this: it closes the username clause, injects an always-true wildcard, and rebalances the parentheses so the overall filter stays syntactically valid but semantically wide open.

Injection also enables enumeration and blind extraction. By searching for (uid=a*), then (uid=b*), and observing which queries return results, an attacker maps out valid usernames — and the same prefix trick against a sensitive attribute extracts its value one character at a time, exactly like a blind SQL injection.

The fix: escape filter input, or better, don't build filters by hand

There are two levels of defense, and you want both.

Escape every value that goes into a filter. RFC 4515 defines exactly how: each special character becomes a backslash followed by its two-digit hex code — ( → \28, ) → \29, * → \2a, \ → \5c, NUL → \00. Do not hand-roll this; use your LDAP library's escaping function, which encodes filter assertion values and distinguished names correctly.

Then verify the password by binding, not by matching it in the filter. The strongest pattern is: search for the user by their (escaped) username to find their distinguished name, then attempt an LDAP bind with that DN and the supplied password. The password never appears in a filter at all — the directory itself checks it — so there is nothing to inject on the credential side.

const ldap = require('ldapjs');

// ldapjs exposes a filter-escaping helper. If yours doesn't, escape
// per RFC 4515: ( ) * \ and NUL -> backslash + two hex digits.
function escapeFilter(value) {
return String(value).replace(/[\0()*\\]/g, (c) => {
  return '\\' + c.charCodeAt(0).toString(16).padStart(2, '0');
});
}

async function authenticate(username, password) {
const client = ldap.createClient({ url: 'ldaps://ad.corp.com' });

// 1) Bind as a service account and search for the user's DN.
//    Only the username goes in the filter — and it's escaped.
const filter = `(uid=${escapeFilter(username)})`;
const entry = await searchOne(client, 'ou=people,dc=corp,dc=com', filter);
if (!entry) return null;

// 2) Verify the password by BINDING as that DN. The password is
//    never placed in a filter, so it can't be injected.
try {
  await bindAs(client, entry.dn, password);
  return entry;
} catch {
  return null; // bind failed = wrong password
}
}

The principles to carry over

• Escape filter values with a library function, never by hand. RFC 4515 escaping is small but easy to get subtly wrong; use the encoder your LDAP client ships.
• Verify passwords by binding, not by filtering. Keep the credential out of the query entirely — let the directory authenticate it. This also avoids ever needing the password in a comparable form.
• Use a low-privilege service account. The account that runs the initial search should be able to read only what it needs. If injection ever broadens a search, it can't reach attributes the service account can't see.
• Scope and constrain searches. Set a narrow base DN, SUBTREE only where required, and a small size limit, so a widened filter can't enumerate the whole directory.

The single idea underneath all of it: an LDAP filter is code, and user input belongs in it only as escaped data — ideally not on the password path at all. Bind to check credentials; escape to search.

Try it in the LDAP injection simulation: bypass a corporate login with a wildcard payload, then switch to search-then-bind with escaping and watch the bypass close. It rounds out the injection family alongside SQL injection and NoSQL injection — same root cause, three different query languages.