Ldap Injection in Fiber with Basic Auth

LDAP Injection is an attack technique that manipulates LDAP query construction to bypass authentication or access unauthorized directory data. In the Go Fiber framework, using HTTP Basic Authentication does not inherently protect against LDAP Injection when the server constructs LDAP filters or DNs from user-controlled input. Basic Auth supplies a username and password via the Authorization header, but if the application uses the provided username to dynamically build LDAP search filters or distinguished names without proper validation or escaping, the attacker can inject LDAP metacharacters such as (, ), *, &, and |.

Consider a scenario where Fiber uses the Basic Auth username to locate a user object in LDAP before validating the password. An attacker can supply a username like admin)(uid=*))(|(uid=, which alters the intended LDAP filter structure. For example, a filter originally intended to be (uid={username}) becomes (uid=admin)(uid=*))(|(uid=))(uid=*), potentially returning multiple entries or bypassing the lookup entirely. This can lead to authentication bypass, information disclosure, or unauthorized directory access even when the password is verified separately.

Because Fiber does not automatically sanitize inputs for LDAP contexts, developers must treat Basic Auth credentials as untrusted. The combination of unescaped user input in LDAP filters and the direct use of Basic Auth credentials enables attackers to manipulate the LDAP query logic. This risk is compounded when the application performs additional operations, such as group membership checks, using the same injected input. The attack surface exists even when passwords are verified safely, as the injection occurs during the user lookup phase before password verification.

middleBrick detects LDAP Injection as part of its Input Validation checks during unauthenticated scans. It observes how usernames are used in LDAP-related requests and identifies filter construction patterns that are vulnerable to injection. The scanner does not fix the logic but provides findings with severity, impact description, and remediation guidance to help developers secure the interaction between Basic Auth and LDAP operations.

To mitigate LDAP Injection in Fiber when using Basic Auth, you must ensure that any user-controlled data used in LDAP filters or DNs is properly escaped and that authentication logic does not rely on dynamic query building. Below are concrete remediation patterns with working Fiber code examples.

1. Avoid building LDAP filters from raw usernames

Instead of directly interpolating the Basic Auth username into an LDAP filter, perform a controlled bind or use a static filter with indexed lookup. For example, first retrieve the user’s DN from a known mapping or use an indexed attribute that does not require constructing a filter from raw input.

// Unsafe: building filter from user input
app.get('/login', (c *fiber.Ctx) error {
    username := string(c.Request().Header.Peek("Authorization"))
    // extract username from Basic Auth (simplified)
    filter := fmt.Sprintf("(uid=%s)", username)
    // ldap search using filter... (vulnerable)
    return c.SendString("checking...")
})

Use a safer approach by validating the username format and using parameterized searches or direct binds where possible.

2. Escape special characters when constructing filters

If you must construct an LDAP filter, escape reserved characters using an LDAP escaping function. Below is an example using a simple escaping helper to neutralize injection characters.

func escapeLDAPFilter(s string) string {
    // Replace * with \2a, ( with \28, ) with \29, \000 with \0000
    // This is a simplified example; use a well-tested library in production
    s = strings.ReplaceAll(s, "\\", "\\5c")
    s = strings.ReplaceAll(s, "*", "\\2a")
    s = strings.ReplaceAll(s, "(", "\\28")
    s = strings.ReplaceAll(s, ")", "\\29")
    s = strings.ReplaceAll(s, "\x00", "\\0000")
    return s
}

app.Post('/login', func(c *fiber.Ctx) error {
    auth := string(c.Request().Header.Peek("Authorization"))
    // Basic Auth format: Basic base64(credentials)
    creds, err := base64.StdEncoding.DecodeString(strings.TrimPrefix(auth, "Basic "))
    if err != nil {
        return c.Status(fiber.StatusBadRequest).SendString("invalid auth")
    }
    pair := strings.SplitN(string(creds), "\x00", 2)
    if len(pair) != 2 {
        return c.Status(fiber.StatusBadRequest).SendString("invalid credentials")
    }
    username := escapeLDAPFilter(pair[0])
    password := pair[1]

    filter := fmt.Sprintf("(uid=%s)", username)
    // Use filter and password with LDAP client for bind
    // ldapClient.Bind(dn, password)
    return c.SendString("ok")
})

3. Prefer simple bind with indexed lookup instead of search-and-bind

If your LDAP server allows direct bind using a known DN pattern (for example, uid={username},ou=people,dc=example,dc=com), you can construct the DN safely by validating the username format (e.g., allow only alphanumeric characters) and avoiding filters entirely.

app.Post('/login-safe', func(c *fiber.Ctx) error {
    auth := string(c.Request().Header.Peek("Authorization"))
    creds, err := base64.StdEncoding.DecodeString(strings.TrimPrefix(auth, "Basic "))
    if err != nil {
        return c.Status(fiber.StatusBadRequest).SendString("invalid auth")
    }
    pair := strings.SplitN(string(creds), "\x00", 2)
    if len(pair) != 2 {
        return c.Status(fiber.StatusBadRequest).SendString("invalid credentials")
    }
    username := pair[0]
    password := pair[1]

    // Validate username to allow only safe characters
    if !regexp.MustCompile(`^[a-zA-Z0-9._-]+$`).MatchString(username) {
        return c.Status(fiber.StatusBadRequest).SendString("invalid username")
    }
    dn := fmt.Sprintf("uid=%s,ou=people,dc=example,dc=com", username)
    // ldapClient.Bind(dn, password)
    return c.SendString("authenticated")
})

These examples demonstrate how to integrate Basic Auth with LDAP safely in Fiber by avoiding dynamic filter construction, validating and escaping input, and preferring direct DN-based binds. Security testing tools like middleBrick can verify that these mitigations reduce the observable attack surface by checking for improper filter usage and injection-prone patterns.