Ldap Injection in Django with Firestore

Ldap Injection occurs when an attacker can manipulate LDAP query construction through untrusted input. In a Django application using Firestore as a data store, the risk arises when Firestore-stored configuration values (such as LDAP server URIs, base DNs, or filter templates) are injected into LDAP query building without proper validation or escaping. Because Firestore itself does not execute LDAP operations, the vulnerability is not in Firestore but in the way Django consumes stored LDAP settings and constructs queries using user-supplied data combined with those settings.

Consider a scenario where Firestore holds an LDAP filter template intended to match user entries. If this template includes placeholders that are later filled directly with unsanitized input, an attacker can inject additional LDAP filter syntax to bypass authentication or extract sensitive directory information. For example, a stored Firestore document might define (&(uid=%s)(objectClass=person)), and Django builds the final filter using string formatting with user input. An attacker providing admin)(&(objectClass=*) as the username can turn the query into (&(uid=admin)(&(objectClass=*)(objectClass=person)), potentially returning all entries depending on the LDAP server’s behavior.

Django’s LDAP integrations (such as django-auth-ldap) often build filters using string interpolation or ldap.filter.filter_format. If the base DN or filter components are sourced from Firestore and concatenated without escaping user input, the attack surface mirrors classic LDAP Injection despite Firestore being a separate backend. Firestore may also store mappings between usernames and LDAP group DNs; if these mappings are used to construct dynamic search bases without escaping, attackers can traverse the directory by injecting subtree or parent traversals (e.g., .. sequences) or by exploiting special characters like asterisks for wildcard expansion.

Another realistic pattern involves using Firestore to store rate-limiting or access-control rules keyed by LDAP identity. If these rules are combined with unchecked user input to form LDAP search filters, an attacker can manipulate which directory entries are evaluated, leading to privilege escalation or information disclosure. Because the scan lists LDAP among its 12 security checks, middleBrick would flag scenarios where user-controlled data influences LDAP filter construction, especially when Firestore-supplied configuration is involved.

Real-world LDAP filter special characters include (, ), *, \\, and null bytes. Without escaping via utilities such as ldap.filter.escape_filter_chars, these characters enable injection. Even when Firestore provides sanitized defaults, developers must ensure runtime values are escaped before inclusion in LDAP queries, and avoid treating Firestore-stored templates as inherently safe.

To prevent Ldap Injection in Django when using Firestore, treat all Firestore-stored LDAP configuration as potentially compromised and apply strict input validation and escaping at the point of query construction. Use parameterized APIs or dedicated escaping functions rather than string concatenation. Below are concrete, realistic code examples that demonstrate secure patterns.

1. Secure LDAP filter construction with escaped user input

Always escape user-controlled components before inserting them into LDAP filters. Use ldap.filter.escape_filter_chars from the python-ldap library. Retrieve LDAP settings from Firestore but sanitize dynamic parts.

import firebase_admin
from firebase_admin import firestore
import ldap.filter

# Initialize Firestore (assumes default credentials are set)
firebase_admin.initialize_app()
db = firestore.client()

# Fetch an LDAP filter template from Firestore (e.g., stored as a document field)
template_doc = db.collection('auth_config').document('ldap').get()
template = template_doc.to_dict().get('user_filter_template', '(&(uid=%s)(objectClass=person))')

# User input from login form
username = request.POST.get('username', '')

# Escape user input for safe LDAP filter inclusion
safe_username = ldap.filter.escape_filter_chars(username)

# Build final filter using safe insertion; avoid %-formatting with raw input
final_filter = template.replace('%s', safe_username)

# Use final_filter with ldap.initialize and bind (not shown)

2. Parameterized base DN assembly

If Firestore stores base DN fragments, concatenate them with constant, trusted strings and validate the overall structure. Do not allow user input to dictate directory traversal components.

import firebase_admin
from firebase_admin import firestore

firebase_admin.initialize_app()
db = firestore.client()

# Firestore stores base DN parts; ensure they are pre-approved values
doc = db.collection('ldap_config').document('base').get()
config = doc.to_dict()
base_dn_parts = config.get('base_dn_parts', ['dc=example,dc=com'])
base_dn = ','.join(base_dn_parts)  # Trusted, static assembly

# User input used only as attribute value, not as DN component
username = request.POST.get('username', '')
search_filter = '(&(uid=%s)(objectClass=person))' % ldap.filter.escape_filter_chars(username)

# Perform search using base_dn and search_filter via ldap.initialize().search_s(...)

3. Validate and restrict special characters in Firestore-derived rules

If Firestore stores access rules that include LDAP identity patterns, validate and normalize these patterns server-side before use. Reject or encode unexpected wildcards or groupings introduced by users.

import re

# Example: ensure a Firestore-supplied group pattern does not contain injection-prone constructs
stored_pattern = '(ou=groups)(memberUid=%s)'  # From Firestore

def is_safe_pattern(pattern):
    # Disallow standalone parentheses or asterisks that are not part of intended wildcards
    if re.search(r'[^\\*a-zA-Z0-9_\-=\s,\(\)\\]', pattern):
        return False
    return True

if is_safe_pattern(stored_pattern):
    safe_pattern = stored_pattern.replace('%s', ldap.filter.escape_filter_chars(username))
else:
    raise ValueError('Unsafe pattern from configuration')

4. Use Django settings for static configuration, limit Firestore roles to non-critical data

Prefer storing non-sensitive configuration in Django settings and restrict Firestore to metadata that does not directly influence LDAP query structure (e.g., display names or UI hints). This reduces the attack surface where Firestore values affect LDAP behavior.