Crlf Injection in Echo Go with Basic Auth

Crlf Injection occurs when user-controlled data is reflected in HTTP headers without proper sanitization, allowing an attacker to inject newline characters (CRLF: \r\n) to split headers and inject additional ones. In Echo Go, this risk is heightened when Basic Authentication is used and the application improperly incorporates user input into header values or response lines.

Basic Auth in Echo Go typically involves extracting the Authorization header, decoding the base64 payload, and using the username or password in business logic or downstream logging. If an attacker can control any part of the request that ends up in a header—such as a username, an injected token, or a reflected query parameter—and the framework or handler writes that value into a response header or status line without validation, CRLF Injection becomes possible.

For example, consider an endpoint that echoes the provided username in a custom header. A malicious username like attacker\r\nX-Injected: true would, if written directly into the response, cause the server to emit two separate logical headers. This can enable HTTP response splitting, cache poisoning, or the injection of arbitrary headers such as Set-Cookie or Location, which may lead to further client-side attacks like cross-site scripting or open redirects.

When Basic Auth is involved, the decoded credentials often flow through middleware or handlers that may log or reflect them. If logging or diagnostic code writes these values into HTTP headers without sanitization, the CRLF characters embedded in the username or password (though uncommon but possible if an attacker controls credential generation) can similarly split responses. Additionally, Echo Go applications that build custom WWW-Authenticate challenge headers or incorporate user data into authentication-related error messages must be cautious; unsanitized newlines in these headers can break protocol parsing and enable injection-based exploits.

Using middleBrick to scan an endpoint with Basic Auth can surface these issues by analyzing header handling and injection surfaces. The scanner checks input validation and output encoding across authentication flows, helping to identify places where user-controlled data reaches headers. Findings include specific guidance on sanitizing and encoding header values and avoiding direct reflection of untrusted input in any response line or header.

Remediation focuses on strict validation, avoiding reflection of untrusted data in headers, and safe construction of WWW-Authenticate challenges. Always treat credentials and any user-influenced strings as untrusted when they may be included in headers.

1. Never reflect raw credentials in headers or body

Do not write the username or password from Basic Auth into response headers or status messages. If you must include a user identifier in headers, derive a safe, non-sensitive value (such as a user ID from your database) and validate it.

// Unsafe: reflects raw username into a custom header
username, password, ok := e.Request.BasicAuth()
if ok {
    e.Response().Header().Set("X-User", username) // Vulnerable to CRLF injection
}

// Safe: use an internal, sanitized identifier instead
if ok {
    userID, err := getUserID(username) // map to a safe internal ID
    if err != nil {
        return echo.ErrUnauthorized
    }
    e.Response().Header().Set("X-User-ID", userID)
}

2. Validate and encode header values

If you must include external data in headers, enforce a strict allowlist and remove or replace newline characters. Use Go’s http.CanonicalHeaderKey and avoid concatenating raw input into header values.

import "strings"

func safeHeaderValue(input string) string {
    // Remove any carriage return or newline to prevent header splitting
    cleaned := strings.ReplaceAll(input, "\r", "")
    cleaned = strings.ReplaceAll(cleaned, "\n", "")
    return cleaned
}

// Usage
username, _, ok := e.Request.BasicAuth()
if ok {
    safeUser := safeHeaderValue(username)
    e.Response().Header().Set("X-Safe-User", safeUser)
}

3. Construct WWW-Authenticate headers safely

When returning 401 challenges, ensure realm and other parameters are static or carefully controlled. Do not incorporate user input into the WWW-Authenticate header without encoding.

// Unsafe: incorporates dynamic input into WWW-Authenticate
realm := fmt.Sprintf("Restricted area for %s", username)
e.Response().Header().Set("WWW-Authenticate", fmt.Sprintf(`Basic realm="%s"`, realm))

// Safe: use a fixed realm
const realm = "API Access"
e.Response().Header().Set("WWW-Authenticate", `Basic realm="API Access"`)

4. Prefer middleware-based authentication with validated flows

Use Echo’s built-in HTTP Basic Auth middleware with a validated user checker, and avoid manually handling headers where possible.

func basicAuthValidator(username, password string, c echo.Context) (bool, error) {
    // Validate credentials against a safe store
    return validateUser(username, password), nil
}

e := echo.New()
e.Use(middleware.BasicAuth(basicAuthValidator))

By following these practices—avoiding reflection of raw credentials, sanitizing any user data that reaches headers, and using fixed realms—you mitigate CRLF Injection risks in Echo Go applications that use Basic Authentication.