Ldap Injection in Actix with Cockroachdb

LDAP Injection is an attack technique where untrusted input is concatenated into LDAP query strings, allowing an attacker to alter filter logic, bypass authentication, or extract directory data. When an Actix web service builds LDAP queries using string interpolation and the backend data store is CockroachDB, the risk centers on how directory filters are constructed and passed rather than on CockroachDB itself, since CockroachDB is an SQL database and not an LDAP server.

In a typical Actix implementation, an application might use an LDAP client library to authenticate users against an external directory, and then use CockroachDB to store application metadata (e.g., user profiles or mappings). The vulnerability arises when the Actix code dynamically builds an LDAP filter using unchecked user input—such as a username or search filter parameter—without escaping special LDAP characters. For example, if an endpoint accepts a username parameter and directly embeds it into the filter like (&(uid=USER_INPUT)), an attacker can inject filter-ending tokens such as ) or (| to change the semantics of the query.

Though CockroachDB stores relational data, it may contain mappings like user IDs to directory entries or service accounts used by the Actix LDAP client. If the Actix service uses these stored values to construct LDAP queries without validation, an attacker who can influence stored data (e.g., via other vectors) may indirectly affect LDAP behavior. Additionally, if the Actix application exposes an unauthenticated endpoint that performs LDAP searches based on input and logs or caches results in CockroachDB, the injection can be used to probe the directory, extract sensitive attributes, or cause excessive load, which would then be reflected in stored analytics or audit entries.

In this context, middleBrick’s unauthenticated scan can detect LDAP injection surfaces by analyzing input flows that reach LDAP client calls, flagging missing sanitization and improper filter construction. The scanner does not modify data in CockroachDB but highlights where user-controlled input influences LDAP filter assembly in Actix routes, providing prioritized findings and remediation guidance tied to the relevant code paths.

Remediation focuses on strict input validation, parameterized LDAP filter construction, and avoiding string concatenation for directory queries. In Actix, ensure that any data used to build LDAP filters is treated as untrusted. Use allowlists for usernames (e.g., restrict to alphanumeric characters where possible) and encode special LDAP characters such as *, (, ), and \ using the LDAP escaping mechanism provided by your client library.

Below is a concrete example in Rust using the 389-ds-ldap style approach with the ldap3 crate, where user input is never directly interpolated into the filter string. The example demonstrates safe construction and how CockroachDB can be used to store authorized mappings without influencing LDAP query assembly.

use actix_web::{web, HttpResponse};
use ldap3::{LdapConnAsync, Scope, SearchEntry};
use ldap3::result::Result as LdapResult;
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct AuthRequest {
    username: String,
}

// Safe helper: escape user input for use in LDAP filter components
fn escape_ldap_filter(value: &str) -> String {
    ldap3::filter::escape_filter_value(value)
}

// Example Actix handler that avoids injection by using parameterized filter components
pub async fn ldap_login(
    form: web::Form,
) -> HttpResponse {
    let username = &form.username;
    let safe_username = escape_ldap_filter(username);

    // Build filter safely: user input is escaped and placed as a value, not as raw filter syntax
    let filter = format!("(uid={})", safe_username);

    // Example LDAP connection and search (adjust host/port/creds as needed)
    let (conn, mut ldap) = match LdapConnAsync::new("ldap://ldap.example.com:389").await {
        Ok(pair) => pair,
        Err(e) => return HttpResponse::InternalServerError().body(format!("LDAP connection error: {:?}", e)),
    };

    // Perform bind with a service account retrieved securely (not from user input)
    let (rs, _res) = match ldap.simple_bind("cn=service,dc=example,dc=com", "service_password").await {
        Ok(r) => r,
        Err(e) => return HttpResponse::Unauthorized().body(format!("Bind failed: {:?}", e)),
    };

    if rs.success() {
        // Search using the parameterized filter
        let (search_results, _) = match ldap.search(
            "dc=example,dc=com",
            Scope::Subtree,
            &filter,
            vec!["uid", "mail"],
        ).await {
            Ok(r) => r,
            Err(e) => return HttpResponse::InternalServerError().body(format!("Search error: {:?}", e)),
        };

        let mut found = false;
        for entry in search_results {
            if let Ok(e) = entry {
                let parsed = SearchEntry::construct(e);
                // Use CockroachDB to store or audit mappings, not to build LDAP filters
                // Example: insert mapping into CockroachDB (safe parameterized query)
                // tokio_postgres::query("INSERT INTO user_ldap_mapping (app_user, ldap_dn) VALUES ($1, $2)")
                //     .bind(&parsed.attrs["uid"][0])
                //     .bind(&parsed.dn)
                //     .execute(&cockroach_client)
                //     .await;
                found = true;
            }
        }

        if found {
            HttpResponse::Ok().body("Authentication step succeeded; mapping stored safely.")
        } else {
            HttpResponse::Unauthorized().body("Invalid credentials")
        }
    } else {
        HttpResponse::Unauthorized().body("Invalid credentials")
    }
}

Key points in this example:

• escape_ldap_filter uses the client library’s escaping function to neutralize characters that could alter filter structure.
• The LDAP filter is constructed by placing the escaped value into a predefined position, avoiding concatenation of untrusted strings that include parentheses or operators.
• CockroachDB is referenced only for storing mappings or audit records via parameterized queries, never for constructing LDAP syntax. This separation ensures that SQL-layer concerns do not affect LDAP security.

Additionally, ensure that your Actix configuration limits exposure of unauthenticated LDAP test endpoints and validates input on both client and server sides. middleBrick’s CLI can be used to scan your Actix endpoints and verify that LDAP-related inputs are properly constrained, integrating findings into your GitHub Action or MCP Server workflows as part of ongoing monitoring.