Crlf Injection in Fiber with Dynamodb

Crlf Injection occurs when user-controlled data is reflected in HTTP headers without sanitization, allowing an attacker to inject newline characters (CRLF = Carriage Return + Line Feed). In a Fiber application that interacts with DynamoDB, this typically happens when request parameters (such as a user ID, query string, or header value) are used both to build a response header and to query DynamoDB without proper validation or escaping.

Consider a Fiber handler that takes a user_id from a query parameter and uses it to fetch a user record from DynamoDB, then reflects the user’s display name in a custom response header. If the display name contains a CRLF sequence (e.g., injected via application logic or compromised data), the header split is broken. An attacker can inject additional headers or split the response, leading to HTTP response splitting, cache poisoning, or cross-site scripting in some contexts.

Example vulnerable pattern:

// Vulnerable: user input used in header and DynamoDB query
app.Get('/user', func(c *fiber.Ctx) error {
    userID := c.Query("user_id")
    // DynamoDB query using userID (omitted validation)
    result, err := db.GetItem(&dynamodb.GetItemInput{
        TableName: aws.String("Users"),
        Key: map[string]types.AttributeValue{
            "user_id": &types.AttributeValueMemberS{Value: userID},
        },
    })
    if err != nil {
        return c.SendStatus(fiber.StatusInternalServerError)
    }
    displayName := aws.ToString(result.Item["display_name"].S)
    // Unsafe reflection of attacker-controlled data in header
    c.Set("X-Display-Name", displayName)
    return c.JSON(fiber.Map{"id": userID})
})

If the DynamoDB item contains display_name: "John\r\nX-Injected: malicious", the header is split, and X-Injected: malicious becomes a new response header. This can enable further attacks, including header injection or smuggling, depending on deployment proxies and caching layers.

The same DynamoDB data may also be used in other reflection contexts, such as JSON responses with embedded user-controlled strings. While the JSON body is generally not vulnerable to classic CRLF injection, newlines can break structured logging or be misinterpreted by downstream parsers that do not handle multiline strings safely.

middleBrick scans this attack surface by testing unauthenticated endpoints and cross-referencing OpenAPI specs with runtime behavior. It flags header-based injection risks and highlights areas where DynamoDB-sourced data enters response headers or critical strings, helping you identify and prioritize fixes before an attacker can exploit a split.

Remediation focuses on strict input validation, output encoding, and avoiding the use of untrusted data in headers. For DynamoDB-driven values, treat all stored data as potentially malicious and apply defense-in-depth.

1. Validate and sanitize inputs used in DynamoDB queries

Ensure IDs and query parameters conform to an expected pattern before using them in DynamoDB requests. This prevents unexpected characters from entering your data layer and reduces risk of injection chains.

// Validate user_id before using it in DynamoDB
func isValidUserID(id string) bool {
    // Allow only alphanumeric and underscores, length 1..64
    matched, _ := regexp.MatchString(`^[A-Za-z0-9_]{1,64}$`, id)
    return matched
}

app.Get('/user', func(c *fiber.Ctx) error {
    userID := c.Query("user_id")
    if !isValidUserID(userID) {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid user_id"})
    }
    result, err := db.GetItem(&dynamodb.GetItemInput{
        TableName: aws.String("Users"),
        Key: map[string]types.AttributeValue{
            "user_id": &types.AttributeValueMemberS{Value: userID},
        },
    })
    if err != nil {
        return c.SendStatus(fiber.StatusInternalServerError)
    }
    if result.Item == nil {
        return c.SendStatus(fiber.StatusNotFound)
    }
    displayName := aws.ToString(result.Item["display_name"].S)
    // Safe: validation applied upstream, but still encode header values
    safeName := headerEncode(displayName)
    c.Set("X-Display-Name", safeName)
    return c.JSON(fiber.Map{"id": userID})
})

2. Encode data before placing it in headers

Strip or percent-encode CRLF characters in any data that may be reflected in headers. For DynamoDB values, apply a strict sanitization function that removes or replaces \r and \n.

// Remove carriage return and line feed to prevent header splitting
func headerEncode(value string) string {
    // Remove CRLF characters
    value = strings.ReplaceAll(value, "\r", "")
    value = strings.ReplaceAll(value, "\n", "")
    // Optionally replace with a safe space or reject
    return value
}

3. Use structured logging and avoid header reflection for DynamoDB data

If you must log or forward DynamoDB attributes, write them to structured logs (e.g., JSON) rather than HTTP headers. This avoids inadvertent parsing issues and keeps sensitive or multiline data out of the HTTP protocol layer.

// Prefer structured logging over header reflection
logEntry, _ := json.Marshal(map[string]interface{}{
    "user_id":   userID,
    "timestamp": time.Now().UTC(),
    "display_name": displayName,
})
c.Logger().Info(string(logEntry))

middleBrick’s LLM/AI Security checks can also detect scenarios where DynamoDB outputs containing newline-rich data are exposed in AI-assisted tooling or prompts, helping you identify less obvious injection channels.