Ldap Injection in Aspnet with Basic Auth

LDAP Injection occurs when an attacker is able to manipulate an LDAP query by injecting malicious input. In ASP.NET applications that rely on Basic Authentication and construct LDAP filter strings by concatenating user-supplied values, this creates a path for injection. Basic Authentication typically sends credentials as a base64-encoded string in the Authorization header; the server then uses those credentials to bind or query an LDAP directory. If the application builds the LDAP filter using string concatenation or interpolation with the username or password directly, special LDAP characters such as (, ), *, and \ can alter the filter syntax.

For example, a common vulnerable pattern is constructing the filter as (&(objectClass=user)(sAMAccountName={username})(userPassword={password})) by inserting raw input. An attacker can supply a username like admin)(&objectClass=user)(sAMAccountName=* to change the logical grouping of the filter, potentially bypassing authentication or extracting unintended entries. Because Basic Authentication supplies the credentials before the application performs any validation, the LDAP query runs with the attacker-controlled values, enabling authentication bypass or information disclosure.

ASP.NET applications often use the System.DirectoryServices or System.DirectoryServices.Protocols namespaces to interact with LDAP. When these APIs receive a filter string built from unchecked input, the LDAP server executes the modified query and may return entries the attacker did not have permission to see. This can lead to user enumeration or retrieval of sensitive attributes. The unauthenticated attack surface of such endpoints is particularly risky because the probe stage of an LDAP injection can be performed without prior access, and findings related to authentication and input validation are among the checks middleBrick runs in parallel.

In a black-box scan, a security tool can detect LDAP injection by sending crafted payloads that change the structure of the LDAP filter and observing differences in responses, such as different bind success behavior or additional returned entries. Because Basic Authentication does not inherently encode or escape special characters in the username or password, the onus is on the developer to sanitize and parameterize inputs. The presence of LDAP injection in this context is a strong indicator that the application is constructing directory queries dynamically rather than using safe abstractions.

Remediation focuses on avoiding direct string concatenation when building LDAP filters. Instead, use parameterized approaches or dedicated libraries that escape special LDAP characters. When credentials are provided via Basic Authentication, treat the username and password as untrusted input and validate them before using them in directory queries.

Below is a secure example in ASP.NET using System.DirectoryServices.Protocols with a parameterized filter pattern. This approach avoids embedding raw user input directly into the filter string and uses placeholders that are properly escaped by the API.

using System;
using System.DirectoryServices.Protocols;
using System.Net;

public class LdapService
{
    private readonly string _ldapServer;
    private readonly int _port;

    public LdapService(string ldapServer, int port)
    {
        _ldapServer = ldapServer;
        _port = port;
    }

    public bool TryAuthenticate(string username, string password)
    {
        if (string.IsNullOrWhiteSpace(username) || string.IsNullOrWhiteSpace(password))
        {
            return false;
        }

        // Input validation: allow only expected characters for your user identifiers
        if (!System.Text.RegularExpressions.Regex.IsMatch(username, @"^[a-zA-Z0-9._-]+$"))
        {
            return false;
        }

        var identifier = new LdapDirectoryIdentifier(_ldapServer, _port);
        using var connection = new LdapConnection(identifier);
        connection.SessionOptions.SecureSocketLayer = false; // or true for LDAPS

        try
        {
            // Use the overload that performs a secure bind with explicit credentials
            // This avoids building a custom filter with user input
            connection.Credential = new NetworkCredential(username, password);
            connection.Bind();
            return true;
        }
        catch (LdapException)
        {
            // Log and handle invalid credentials without revealing details
            return false;
        }
    }
}

If you must construct a filter, ensure you escape special characters using System.DirectoryServices.AccountManagement or a manual escaping routine for the distinguished name and filter substrings. Never concatenate raw username or password values into the filter string. The above example prefers a bind-based authentication flow, which is safer than building a query with user-controlled input.

Additionally, enforce transport security (LDAPS) to protect credentials in transit, and apply rate limiting to mitigate brute-force attempts. Because Basic Authentication sends credentials in each request, pair it with HTTPS to prevent interception. The middleBrick CLI can be used to verify that your endpoints do not expose authentication-related findings, and the GitHub Action can enforce a minimum score threshold before merging changes.