Ldap Injection in Actix with Jwt Tokens

Ldap Injection occurs when user-controlled input is concatenated into an LDAP query without proper validation or escaping. In an Actix web service that uses JWT Tokens for initial authentication but then relies on LDAP for authorization or group membership checks, the combination can expose an unauthenticated or low-privilege attack surface. After JWT-based identity is established, the application may query an LDAP directory to enrich user attributes or verify group membership. If these LDAP queries are built by string interpolation using values from the JWT payload (such as username or email), an attacker can manipulate the input to alter the LDAP filter.

For example, an Actix handler might decode a JWT, extract a username claim, and directly use it in an LDAP filter like (&(objectClass=user)(uid={username})). If the username is not sanitized, an attacker can supply a value like admin)(uid=*)(objectClass=user), causing the filter to become (&(objectClass=user)(uid=admin)(uid=*)(objectClass=user)), which can bypass intended access controls or disclose other users’ entries. This represents a BOLA/IDOR and Property Authorization issue because the subject’s identity derived from JWT Tokens is not sufficient to govern LDAP read permissions; the LDAP query inherits trust from the token without additional scope checks.

middleBrick’s 12 security checks run in parallel and would flag this as a finding in the Authentication, BOLA/IDOR, and Property Authorization categories. The scanner tests unauthenticated endpoints and, when an OpenAPI spec is provided, cross-references spec definitions with runtime behavior to highlight how JWT Tokens usage may inadvertently extend LDAP query influence. An attacker does not need credentials if the endpoint is misconfigured to allow LDAP queries derived from token claims, and middleBrick would surface this risk with severity and remediation guidance in the generated report.

Remediation focuses on strict input validation, parameterized LDAP filters, and scoping LDAP queries to the minimal required attributes. Do not directly interpolate JWT claims into LDAP filters. Instead, treat the JWT subject as an identifier to look up a pre-authorized mapping, and use placeholders or an allow-list for any LDAP search components. Below are two concrete Actix examples: one vulnerable pattern and one corrected pattern using parameterized filters.

Vulnerable pattern (concatenation):

use actix_web::{web, HttpResponse};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use ldap3::{LdapConnAsync, Scope, SearchEntry};

async fn vulnerable_handler(token: web::Header<&str>) -> HttpResponse {
    let token_str = token.to_string();
    let decoded = decode::(
        &token_str,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    ).unwrap();
    let username = decoded.claims()["username"].as_str().unwrap();

    // Vulnerable: direct concatenation of JWT claim into LDAP filter
    let filter = format!("(&(objectClass=user)(uid={}))", username);
    let (conn, mut ldap) = LdapConnAsync::new("ldap://ldap.example.com").await.unwrap();
    let (rs, _res) = ldap.search(
        "dc=example,dc=com",
        Scope::Subtree,
        &filter,
        vec!["mail"],
    ).await.unwrap();
    // process entries...
    HttpResponse::Ok().finish()
}

Corrected pattern (parameterized filter with allow-list validation):

use actix_web::{web, HttpResponse};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation};
use ldap3::{LdapConnAsync, Scope, SearchEntry};
use regex::Regex;

async fn secure_handler(token: web::Header<&str>) -> HttpResponse {
    let token_str = token.to_string();
    let decoded = decode::(
        &token_str,
        &DecodingKey::from_secret("secret".as_ref()),
        &Validation::new(Algorithm::HS256),
    ).unwrap();
    let username = decoded.claims()["username"].as_str().unwrap();

    // Validate against an allow-list pattern to prevent injection
    let re = Regex::new(r"^[a-zA-Z0-9._-]{1,64}$").unwrap();
    if !re.is_match(username) {
        return HttpResponse::BadRequest().body("invalid username");
    }

    // Use parameterized approach: bind DN and filter separately
    let base_dn = "dc=example,dc=com";
    let filter = "(&(objectClass=user)(uid=?))";
    let (conn, mut ldap) = LdapConnAsync::new("ldap://ldap.example.com").await.unwrap();
    let (rs, _res) = ldap.search_ext(
        base_dn,
        Scope::Subtree,
        filter,
        vec!["mail"],
        vec![&username],
    ).await.unwrap();
    // process entries...
    HttpResponse::Ok().finish()
}

Key remediation points: validate JWT claims with strict regex allow-lists, avoid string concatenation for LDAP filters, use library-supported parameterized search APIs (e.g., ldap3’s search_ext with separate filter arguments), and scope queries to the minimum required subtree. These steps reduce the risk of BOLA/IDOR and ensure that identity derived from JWT Tokens does not over-privilege LDAP operations.