Crlf Injection in Chi with Jwt Tokens

Crlf Injection occurs when an attacker can inject a carriage return (CR, \r) and line feed (\n) sequence into a header or status-line context, causing the application to prematurely terminate a header and append additional lines. In the Chi ecosystem, this typically arises when developer-supplied values (e.g., from query parameters, headers, or cookies) are used to construct custom HTTP headers or to influence the status line without adequate sanitization. When Jwt Tokens are involved, the risk surface expands because tokens are often parsed, validated, and then used to derive claims that may influence header construction or redirection logic.

For example, a developer might extract a "next" claim or a user-supplied header value and directly embed it into a response header. If the Jwt Token payload contains \r\n sequences (either injected by an attacker during token creation via a weak upstream issuer or reflected from a misconfigured client), Chi routes can inadvertently split headers, leading to HTTP response splitting. This can enable cache poisoning, cross-site scripting via injected headers, or open up paths for session fixation when combined with Jwt Tokens that influence authentication state. The unauthenticated scan capabilities of middleBrick test such header-manipulation paths and can detect whether injected sequences reach the response layer, flagging Crlf Injection as a high-severity finding.

Consider a scenario where a Chi handler decodes a Jwt Token and uses a claim to set a custom X-User-Role header. If the claim is not sanitized, an attacker who can influence the token (e.g., via a vulnerable upstream issuer or a token with insufficient validation) can supply \r\nLocation: https://evil.com in the role claim. When the handler sets the header without sanitization, the injected sequence terminates the current header and appends a new one, potentially causing a redirect to a malicious site. middleBrick’s LLM/AI Security checks do not apply here, but its standard header and input validation checks highlight whether such uncontrolled data reaches response headers, emphasizing the need for strict allow-lists and encoding.

Remediation focuses on two pillars: strict input validation for any data that influences headers or status lines, and safe header-setting practices in Chi middleware. Never trust claims or token payloads that originate from outside your trusted authority. Always validate and sanitize before using them in header construction.

Below is a safe pattern for handling Jwt Tokens in Chi. It demonstrates decoding a token, validating claims against an allow-list, and setting headers without exposing the application to Crlf Injection.

import "strings"
import "net/http"
import "github.com/golang-jwt/jwt/v5"
import "github.com/go-chi/chi/v5"

// validateRole ensures the role claim contains only expected values.
func validateRole(raw string) (string, bool) {
    allowed := map[string]bool{"user": true, "admin": true, "service": true}
    if !allowed[raw] {
        return "", false
    }
    // Reject any CR or LF characters, even if allow-list passes.
    if strings.ContainsAny(raw, "\r\n") {
        return "", false
    }
    return raw, true
}

func secureHandler(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        auth := r.Header.Get("Authorization")
        if auth == "" {
            http.Error(w, "missing authorization", http.StatusUnauthorized)
            return
        }
        // Strip "Bearer " prefix.
        const bearer = "Bearer "
        if !strings.HasPrefix(auth, bearer) {
            http.Error(w, "invalid authorization scheme", http.StatusUnauthorized)
            return
        }
        tokenString := auth[len(bearer):]

        // Parse and validate token signature and claims with a trusted validator.
        token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
            // TODO: use your key source, e.g., JWKs.
            return myKey, nil
        })
        if err != nil || !token.Valid {
            http.Error(w, "invalid token", http.StatusUnauthorized)
            return
        }

        claims, ok := token.Claims.(jwt.MapClaims)
        if !ok {
            http.Error(w, "invalid claims", http.StatusUnauthorized)
            return
        }

        rawRole, hasRole := claims["role"]
        if !hasRole {
            http.Error(w, "role claim missing", http.StatusBadRequest)
            return
        }

        role, valid := validateRole(rawRole.(string))
        if !valid {
            http.Error(w, "invalid role", http.StatusBadRequest)
            return
        }

        // Safe header setting: no user-controlled newlines.
        w.Header().Set("X-Role", role)
        // If you must redirect, use a hard-coded or strictly validated URL.
        // Do not echo an untrusted "next" parameter directly.
        next.ServeHTTP(w, r)
    })
}

func main() {
    r := chi.NewRouter()
    r.Use(secureHandler)
    r.Get("/profile", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("profile"))
    })
    http.ListenAndServe(":8080", r)
}

If you must construct custom headers from user-influenced data, always sanitize with strings.Replace or strings.Map to remove \r and \n. For status-line redirects, prefer chi.Redirect with a hard-coded or enumerated destination rather than echoing a token-derived URL. middleBrick’s CLI can be used to verify that no injection vectors remain: run middlebrick scan <url> after implementing these fixes to confirm headers remain intact.