Ldap Injection in Actix with Firestore

Ldap Injection occurs when an attacker can manipulate LDAP query construction by injecting malicious input. In an Actix web service that uses Firestore as a data store and also interacts with an LDAP backend for authentication or group lookups, user-controlled input that is not strictly validated or escaped can be concatenated into LDAP filter strings. Firestore does not directly execute LDAP queries, but it may store configuration or user-supplied values (such as identifiers or search bases) that later become part of LDAP filter construction in Actix handlers. If an endpoint builds an LDAP filter like (uid=USER_INPUT) by string concatenation, an attacker can supply *) or other filter metacharacters to expand the scope of the search, bypass authorization checks, or cause excessive queries (information disclosure).

Consider an Actix handler that retrieves a user profile from Firestore and then uses a value stored in Firestore (e.g., a mapped LDAP DN or base DN) to perform an LDAP search. If the handler builds the filter via string interpolation instead of parameterized filters, an attacker who can influence the Firestore-stored mapping (or supply a malicious identifier that ends up in the filter) can manipulate the LDAP query. For example, a filter built as (&(objectClass=person)(cn={input})) becomes vulnerable when input is not sanitized. This exposes the unauthenticated attack surface that middleBrick tests, particularly the BOLA/IDOR and Input Validation checks, which can flag unsafe usage of user-controlled data in LDAP filter construction.

Because the scan runs black-box against the unauthenticated endpoint, middleBrick’s LLM/AI Security checks would not apply here (no LLM endpoint is involved), but the Input Validation and Authentication checks may surface indicators of unsafe string building in LDAP filters. Real-world LDAP injection payloads include wildcard characters like * and escape sequences that can return large directory trees or authenticate as unintended users. In an Actix service, this often maps to business logic flaws such as elevation of privilege or unauthorized data access when combined with Firestore-stored configuration. Remediation focuses on strict input validation, using parameterized LDAP APIs, and avoiding concatenation of untrusted data into filters.

To remediate Ldap Injection in Actix while using Firestore, ensure that any data flowing from Firestore into LDAP operations is strictly validated and never directly concatenated into filter strings. Use parameterized LDAP APIs or prepared filter components where possible. Below are concrete Actix snippets that demonstrate secure handling when Firestore values are involved.

use actix_web::{web, HttpResponse, Result};
use firestore::*; // hypothetical Firestore client wrapper
use ldap3::{LdapConnAsync, Scope, SearchEntry};
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct UserProfile {
    uid: String,
    ldap_base_dn: String, // stored in Firestore, must be validated
}

async fn get_user_ldap_filter(
    firestore_client: web::Data,
    user_id: web::Path,
) -> Result {
    // Retrieve profile from Firestore
    let profile: UserProfile = firestore_client
        .get(&format!("users/{}", user_id))
        .await
        .map_err(|e| actix_web::error::ErrorBadRequest(e.to_string()))?;

    // Validate the base DN before use
    if !is_valid_base_dn(&profile.ldap_base_dn) {
        return Ok(HttpResponse::BadRequest().body("Invalid directory base DN"));
    }

    // Safe: use parameterized filter construction via ldap3's filter builder
    let filter = ldap3::filter::create_filter("objectClass", "person")
        .and(ldap3::filter::create_filter("uid", &profile.uid));

    // Example LDAP search using the safe filter
    let (conn, mut ldap) = LdapConnAsync::new("ldap://example.com").await?;
    let (res, _res) = ldap
        .search(
            profile.ldap_base_dn,
            Scope::Subtree,
            &filter.to_string(),
            vec!["cn"],
        )
        .await?;
    // Process results safely
    for entry in res.success()?.iter() {
        let e = SearchEntry::construct(entry);
        // handle entry
    }
    Ok(HttpResponse::Ok().finish())
}

fn is_valid_base_dn(dn: &str) -> bool {
    // Basic validation to prevent injection via base DN
    dn.chars().all(|c| c.is_alphanumeric() || c == '.' || c == ',' || c == '=')
}

Key practices demonstrated:

• Validate Firestore-stored values (e.g., ldap_base_dn) before using them in LDAP operations.
• Use library-supported filter builders (e.g., ldap3::filter::create_filter) instead of string concatenation to avoid injection.
• Treat Firestore as a source of configuration and identifiers only; never trust its contents for constructing LDAP filters without strict validation.

These steps align with middleBrick’s findings and remediation guidance by ensuring inputs are validated and by avoiding direct interpolation of untrusted data into LDAP filters, reducing the attack surface tested by the scanner.