Access Control: LDAP

Sem o devido controle de acesso, a execução de uma instrução LDAP que contém um valor controlado pelo usuário pode permitir que um invasor acesse entradas de diretório não autorizadas.

Erros de controle de acesso ao banco de dados ocorrem quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são usados para especificar um valor de dados em uma consulta LDAP.
Exemplo 1: A ID de funcionário do usuário atual autenticado é enviada automaticamente com cada solicitação pela interface no lado do cliente. O código a seguir valida corretamente um nome de funcionário usando uma lista de permissões antes de usá-lo para construir uma consulta LDAP. Essa validação impede vulnerabilidades de injeção de LDAP, mas ainda pode deixar o código vulnerável.

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()) {
        ...
    }
}

O problema é que o desenvolvedor não considerou o que aconteceria se um invasor fornecesse valores alternativos de empName. Embora a interface envie automaticamente a ID de funcionário do usuário atual, um invasor pode enviar um valor alternativo como parte de uma solicitação mal-intencionada. Como o código nesse exemplo executa a consulta sob uma associação anônima, ele retornará a entrada de diretório de qualquer ID de funcionário válida, independentemente da identidade do usuário autenticado atual.

Sem o devido controle de acesso, a execução de uma instrução LDAP que contém um valor controlado pelo usuário pode permitir que um invasor acesse entradas de diretório não autorizadas.

Erros de controle de acesso ao banco de dados ocorrem quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são usados para especificar um valor de dados em uma consulta LDAP.
Exemplo 1: O código a seguir usa uma lista de permissões para validar um nome de funcionário lido a partir de um soquete antes de usá-lo para construir uma consulta LDAP. Essa validação impede vulnerabilidades de injeção de LDAP, mas ainda pode deixar o código vulnerável.

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 ) {
    ...
    }
}

O problema é que o desenvolvedor não considerou o que aconteceria se um invasor fornecesse valores alternativos de username. Como o código nesse exemplo executa a consulta sob uma associação anônima, ele retornará a entrada de diretório de qualquer ID de funcionário válida, independentemente da identidade do usuário autenticado atual.