Access Control: LDAP

Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to access unauthorized directory entries.

Database access control errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to specify a data value in an LDAP query.
Example 1: The employee ID of the current authenticated user is automatically submitted with each request by the client-side interface. The following code properly validates an employee name using an allow list before using it to construct an LDAP query. This validation prevents LDAP injection vulnerabilities, but may still leave the code vulnerable.

static string AllowlistVerify(string name) {
    Regex pattern = new Regex(@"^[a-zA-Z\-\.']+$");
    if (pattern.IsMatch(name)) {
        return name;
    }
    return null;
}

...
string verifiedName = AllowlistVerify(managerName.Text.trim());
if(verifiedName != null) {
    DirectorySearcher src = new DirectorySearcher("(manager=" + verifiedName + ")");
    src.SearchRoot = de;
    src.SearchScope = SearchScope.Subtree;

    foreach(SearchResult res in src.FindAll()) {
        ...
    }
}

The problem is that the developer has failed to consider what would happen if an attacker provides alternate values of empName. Although the interface automatically submits the employee ID of the current user, an attacker could submit an alternative value as part of a malicious request. Because the code in this example executes the query under an anonymous bind, it will return the directory entry for any valid employee ID, regardless of the identity of the current authenticated user.

Without proper access control, executing an LDAP statement that contains a user-controlled value can allow an attacker to access unauthorized directory entries.

Database access control errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to specify a data value in an LDAP query.
Example 1: The following code uses an allow list to validate an employee name read from a socket before using it to construct an LDAP query. This validation prevents LDAP injection vulnerabilities, but may still leave the code vulnerable.

char* allowlist_verify(char* name) {
    const char *error;
    int errOffset;
    char* regex = "^[a-zA-Z\\-\\.']+$";
    pcre* re = pcre_compile(regex, 0, &err, &errOffset, NULL);
    int rc = pcre_exec(re, NULL, name, strlen(name), 0, 0, NULL, 0);
    if (rc == 1)
        return name;
    return NULL;
}
...
fgets(managerName, sizeof(managerName), socket);
char* verified_name = allowlist_verify(managerName);
if(verified_name != NULL) {
    snprintf(filter, sizeof(filter), "(manager=%s)", verified_name);
    if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
            filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
            LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
    ...
    }
}

The problem is that the developer has failed to consider what would happen if an attacker provides alternate values of username. Because the code in this example executes the query under an anonymous bind, it will return the directory entry for any valid employee ID, regardless of the identity of the current authenticated user.