Ldap Injection in Aspnet with Mongodb

LDAP injection occurs when an attacker can manipulate LDAP query construction through untrusted input. In an ASP.NET application that uses MongoDB as a backend data store, the risk arises when developer code builds LDAP filter strings by concatenating user-controlled values without validation or parameterization. Even though MongoDB is not an LDAP server, the web application may use LDAP (for example, to bind and validate credentials or to query an Active Directory service) and also use MongoDB to store application data such as user roles or session information. If the LDAP query-building logic is vulnerable, an attacker can inject filter meta-characters like (, ), &, or | to alter the intended scope of the search.

Consider a typical scenario: an ASP.NET Core controller receives a username and builds an LDAP filter like (&(objectClass=user)(sAMAccountName=INPUT)). If INPUT is taken directly from the request and concatenated, an input such as admin)(objectClass=group)|(objectClass=computer) changes the filter structure, potentially returning unintended entries or bypassing authentication checks. After authentication via LDAP, the application might use MongoDB to look up additional user attributes or permissions. If the MongoDB queries also rely on concatenated values derived from the same unchecked input (for example, using the username in a Find filter), the chain of trust is broken. Attackers can then probe for data exposure, privilege escalation across directories, or lateral movement between LDAP and MongoDB-backed features, especially if rate limiting and input validation are weak.

In this combined stack, the attack surface includes both the LDAP path and the MongoDB path. For instance, an injection in the LDAP filter can lead to authentication as a different user, and the subsequent MongoDB operations may run under that user’s permissions, exposing or modifying data that should be isolated. Because the scanner tests authentication, authorization, and input validation in parallel, it can identify malformed LDAP filters and unsafe MongoDB query construction as separate findings that together indicate a systemic lack of input sanitization.

To secure the interaction between ASP.NET and MongoDB, treat all external input as untrusted and enforce strict allow-lists and schema validation. For LDAP, avoid building filters via string concatenation; instead, use dedicated LDAP libraries that support parameterized filters or escape special characters. For MongoDB, use the official C# driver’s strongly typed queries and filter builders, which automatically handle encoding and reduce injection risk.

LDAP input handling

Do not concatenate user input into LDAP filter strings. Use library functions to escape special characters. For example, with System.DirectoryServices.Protocols, you can sanitize inputs before inclusion:

using System.DirectoryServices.Protocols;
// Escape special characters per RFC 4515
string sanitizedUsername = DirectoryAttribute.EscapeFilter(userInput);
string filter = $"(&(objectClass=user)(sAMAccountName={sanitizedUsername}))";
// Use filter with a DirectorySearcher or similar API

MongoDB query construction in ASP.NET

Use the MongoDB C# driver’s Builders<T>.Filter to create type-safe queries. This approach avoids string-based filters and ensures that values are correctly handled.

using MongoDB.Driver;
using System;

public class UserService
{
    private readonly IMongoCollection<User> _users;
    public UserService(IMongoDatabase database)
    {
        _users = database.GetCollection<User>("users");
    }

    public User GetByUsername(string username)
    {
        // Safe: uses a filter definition with a parameter
        var filter = Builders<User>.Filter.Eq(u => u.Username, username);
        return _users.Find(filter).FirstOrDefault();
    }

    // Example with additional validation and multiple fields
    public User GetByValidatedInput(string providedUsername, string allowedDomain)
    {
        // Basic allow-list validation (alphanumeric and underscore)
        if (!System.Text.RegularExpressions.Regex.IsMatch(providedUsername, @"^[a-zA-Z0-9_]+$"))
        {
            throw new ArgumentException("Invalid username format");
        }

        var filter = Builders<User>.Filter.And(
            Builders<User>.Filter.Eq(u => u.Username, providedUsername),
            Builders<User>.Filter.Eq(u => u.Domain, allowedDomain)
        );
        return _users.Find(filter).FirstOrDefault();
    }
}

In addition to using filter builders, apply schema validation on the MongoDB collection to reject malformed documents and enforce data integrity. Configure JSON Schema validation rules at the collection level where supported, and ensure that indexes align with your query patterns to maintain performance without sacrificing security.

For applications scanned by middleBrick, these practices help reduce findings in Authentication, Input Validation, and Property Authorization checks. The CLI (middlebrick scan <url>) can be integrated into development workflows, while the GitHub Action can enforce a maximum risk score before merges, and the MCP Server enables in-IDE scanning so issues can be caught early.