Ldap Injection in Actix with Hmac Signatures

Ldap Injection occurs when user-controlled input is concatenated directly into an LDAP query string without proper validation or escaping. In Actix-web applications that rely on LDAP for authentication or directory services, this typically happens in route handlers that build filter strings. For example, a developer might write code like format!("(&(uid={})(objectClass=person))", user_input), where user_input is taken directly from a form field or header. If the input contains special LDAP metacharacters such as *, (, ), or \, the filter logic can be altered, potentially bypassing authentication or extracting unintended entries.

When Hmac Signatures are used to secure API endpoints or webhook callbacks in Actix, the risk shifts to how the signature is validated. If the application includes user-supplied data in the string that is signed and then later uses that same data in an LDAP query, an attacker can manipulate the payload to change the signed value while still producing a valid Hmac. For instance, an attacker might send a crafted request with an LDAP filter like (&(uid=*)(objectClass=person)) as part of a parameter that is included both in the signature base string and in the LDAP query. If the server verifies the Hmac before properly sanitizing the input, it may trust the parameter value and proceed to construct an unsafe LDAP filter. This combination means that even though the request is authenticated cryptographically, the application logic remains vulnerable to injection because the signature does not protect against malformed or malicious directory content.

Another scenario involves logging or error reporting. If an Actix handler logs the raw query parameters or the signed payload for debugging, and those logs are later viewed or exported, sensitive directory traversal attempts or injected filter components could be exposed. The Hmac ensures integrity of the transmitted data, but it does not sanitize the content itself. Therefore, the application must treat all inputs that influence LDAP queries as untrusted, even when the Hmac validates the request origin. The OWASP API Top 10 category on Injection remains relevant here, as LDAP Injection is a specialized form of injection that exploits directory protocol syntax.

To remediate Ldap Injection in Actix while using Hmac Signatures, you must separate signature verification from input usage. First, validate the Hmac to confirm request authenticity, then sanitize and parameterize any data that will be used in LDAP queries. Never construct LDAP filter strings via string concatenation with user input. Instead, use parameterized approaches or strict allowlists for known attributes.

Below are concrete Actix-web examples. The first shows an unsafe handler that builds an LDAP filter directly from user input and includes it in the Hmac base string. The second demonstrates a secure pattern where input is validated and escaped before being used, and the signature is computed only on safe, canonical data.

Unsafe Example (Do Not Use)

use actix_web::{web, HttpResponse};
use hmac::{Hmac, Mac};
use sha2::Sha256;

type HmacSha256 = Hmac<Sha256>;

async unsafe_handler(user_id: web::Query<HashMap<String, String>>) -> HttpResponse {
    let user_input = user_id.get("filter").unwrap_or("");
    let base_string = format!("user_id={}&filter={}", user_id.get("id").unwrap_or(""), user_input);
    let mut mac = HmacSha256::new_from_slice(b"secret_key").unwrap();
    mac.update(base_string.as_bytes());
    let result = mac.finalize();
    let signature = result.into_bytes();

    // Unsafe: directly embedding user_input into LDAP filter
    let ldap_filter = format!("(&(uid={})(objectClass=person))", user_input);
    // ... proceed with LDAP query
    HttpResponse::Ok().finish()
}

Secure Example with Remediation

use actix_web::{web, HttpResponse};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use ldap3::scope::Subtree;
use ldap3::{LdapConnAsync, Scope, SearchEntry};

type HmacSha256 = Hmac<Sha256>;

async fn secure_handler(
    user_id: web::Query<HashMap<String, String>>
) -> HttpResponse {
    let uid = user_id.get("id").unwrap_or("");
    let raw_filter = user_id.get("filter").unwrap_or("");

    // Step 1: Verify Hmac on canonical data only
    let base_string = format!("id={}&filter={}", uid, raw_filter);
    let mut mac = HmacSha256::new_from_slice(b"secret_key").unwrap();
    mac.update(base_string.as_bytes());
    let expected_sig = mac.finalize();
    // In practice, compare with provided signature in constant time

    // Step 2: Validate and sanitize input — allow only alphanumeric and underscores
    let sanitized_filter = if raw_filter.chars().all(|c| c.is_alphanumeric() || c == '_' || c == '-') {
        raw_filter
    } else {
        return HttpResponse::BadRequest().body("Invalid filter characters");
    };

    // Step 3: Use parameterized LDAP query via ldap3 crate (not string concat)
    let (conn, mut ldap) = LdapConnAsync::new("ldap://example.com").await.unwrap();
    let filter = format!("(&(uid={})(objectClass=person))", sanitized_filter);
    let (rs, _res) = ldap.search(
        "dc=example,dc=com",
        Scope::Subtree,
        &filter,
        vec!["cn"]
    ).await.unwrap();

    // Process entries...
    HttpResponse::Ok().finish()
}

Key remediation steps include:

• Perform Hmac verification on a canonical representation that excludes or escapes special characters.
• Apply strict input validation (e.g., allowlist) before using any value in LDAP queries.
• Use LDAP client libraries that support parameterized filters where available, avoiding manual string assembly.
• Ensure that logging mechanisms do not inadvertently expose unsanitized user input included in signed payloads.