Ldap Injection in Aspnet with Mutual Tls

LDAP Injection is an injection attack targeting LDAP query construction, typically occurring when user-controlled input is concatenated directly into LDAP filters or distinguished names without proper validation or escaping. In an ASP.NET application, this often manifests in authentication or group-membership checks where the developer builds an LDAP filter string using raw input. For example, a common vulnerable pattern is:

string filter = $"(uid={userInput})";

If userInput contains special LDAP metacharacters such as *, (, ), or \, an attacker can manipulate the filter logic to bypass authentication or extract additional attributes. Classic LDAP Injection payloads include *)(uid=admin) to close the original filter and append a new condition, or use of wildcard characters to broaden the search and harvest directory data.

Mutual TLS (mTLS) provides transport-layer authentication by requiring both the client and server to present valid X.509 certificates. When mTLS is in use, the server may be configured to trust the client certificate and extract claims such as the subject distinguished name (DN) or attributes from the certificate to identify the user. If the application then takes a certificate attribute (e.g., CN or email) and directly embeds it into an LDAP filter, the same injection risk exists despite the presence of mTLS. In this scenario, mTLS secures the channel and binds identity to a certificate, but it does not sanitize the attribute value used in LDAP queries. Therefore, the combination of mTLS-derived identity and unchecked LDAP filter construction creates an exposure where the trusted identity source becomes the vector for injection.

Additionally, mTLS may influence authorization logic. For instance, an application might perform supplementary LDAP queries to evaluate group membership or role attributes after certificate validation. If these queries incorporate certificate fields without escaping, attackers who can influence the certificate (e.g., via a misconfigured CA or a compromised client) can craft values that manipulate LDAP search results. This can lead to privilege escalation or unauthorized access decisions. The presence of mTLS can give a false sense of security, leading developers to skip input validation, which is still required for data used in LDAP filters.

It is important to note that middleBrick detects such risky patterns during scans that include unauthentored LDAP-related endpoints. The scanner evaluates whether identity attributes from mTLS are properly escaped before use in LDAP queries and highlights findings in the Authentication and Property Authorization checks, providing prioritized findings with severity and remediation guidance.

To mitigate LDAP Injection in ASP.NET when using mutual TLS, treat all certificate-derived claims as untrusted input. Apply strict validation and canonicalization, and use parameterized LDAP queries or an LDAP library that supports escaping. Below are concrete remediation steps and code examples.

1. Avoid string concatenation for LDAP filters

Use a library that supports building filters safely. For example, with System.DirectoryServices.Protocols, construct filters using proper APIs rather than string interpolation:

using System.DirectoryServices.Protocols;

public string BuildSafeFilter(string userSuppliedValue)
{
    // Validate and restrict input length and allowed characters
    if (string.IsNullOrWhiteSpace(userSuppliedValue) || userSuppliedValue.Length > 256)
        throw new ArgumentException("Invalid input");

    // Use DirectoryAttribute constructor or a safe builder if available
    // This example demonstrates manual escaping for a simple equality filter
    string escaped = EscapeLdapFilterValue(userSuppliedValue);
    return $"(uid={escaped})";
}

private string EscapeLdapFilterValue(string value)
{
    // Basic escaping for special LDAP filter metacharacters: * ( ) \ NUL
    return value.Replace("\\", "\\5c")
                .Replace("*", "\\2a")
                .Replace("(", "\\28")
                .Replace(")", "\\29")
                .Replace("\0", "\\00");
}

// Usage with LdapConnection
var connection = new LdapConnection(new LdapDirectoryIdentifier("ldap.example.com"));
connection.SessionOptions.SecureSocketLayer = true;
connection.AuthType = AuthType.Basic;
// Certificate-based authentication handled by mTLS at transport layer
connection.Bind();

string filter = BuildSafeFilter(certificateSubjectCN);
var request = new SearchRequest("dc=example,dc=com", filter, SearchScope.Subtree, null);
var response = (SearchResponse)connection.SendRequest(request);

In this example, EscapeLdapFilterValue ensures that metacharacters are escaped according to RFC 4515. This prevents attackers from injecting control characters that alter the filter logic.

2. Validate and restrict certificate attributes

Limit which certificate fields are used and enforce strict patterns. For instance, if you rely on the Common Name (CN), validate it against an expected format (e.g., alphanumeric with limited length) before using it in LDAP queries:

using System.Security.Cryptography.X509Certificates;

public string GetValidatedSubjectCN(X509Certificate2 clientCert)
{
    if (clientCert == null)
        throw new ArgumentNullException(nameof(clientCert));

    string cn = clientCert.SubjectName.Name; // e.g., "CN=john,OU=users,DC=example,DC=com"
    // Extract CN safely; consider using a certificate parser library for robustness
    // This is a simplified extraction; in production, use a robust method
    int cnIndex = cn.IndexOf("CN=", StringComparison.OrdinalIgnoreCase);
    if (cnIndex < 0) throw new ArgumentException("Missing CN in subject");
    int end = cn.IndexOf(',', cnIndex + 3);
    if (end < 0) end = cn.Length;
    string cnValue = cn.Substring(cnIndex + 3, end - cnIndex - 3);

    // Restrict to safe characters and length
    if (!System.Text.RegularExpressions.Regex.IsMatch(cnValue, @"^[a-zA-Z0-9._-]{1,64}$"))
        throw new ArgumentException("Invalid CN format");

    return cnValue;
}

By validating and canonicalizing the CN, you reduce the risk of injection even when the value originates from a trusted certificate.

3. Use mTLS for transport and identity binding, not for query construction

Consider using mTLS to authenticate the client and establish a secure channel, but avoid using certificate attributes directly in LDAP filters. Instead, map the certificate to an internal user identifier (e.g., a stable UID) via a trusted configuration or directory lookup, then use that identifier in a parameterized query. This decoupling helps prevent injection while retaining the security benefits of mTLS.

4. Additional hardening

• Enforce size and character constraints on all inputs derived from certificates.
• Log and monitor suspicious patterns, such as unexpected wildcards or malformed filters.
• Keep libraries and frameworks up to date to benefit from security improvements.

These steps help ensure that mutual TLS strengthens authentication without inadvertently introducing injection vulnerabilities in LDAP query construction.