Header Injection in Chi with Basic Auth

Header Injection in the context of Chi with HTTP Basic Auth arises when untrusted input is used to construct response headers while authentication credentials are transmitted in the Authorization header. Basic Auth encodes username:password in Base64 but does not encrypt it; therefore, any injection into header values can lead to response splitting, cache poisoning, or header manipulation if user-controlled data reaches header construction logic.

Chi is a small, composable router for Clojure web applications. When combined with Basic Auth, developers often validate credentials and then forward or transform request data into headers for downstream services or logging. If the values taken from request parameters, headers, or cookies are not strictly validated, an attacker can inject newline characters (e.g., CRLF) into header fields. For example, an injected line can append a new header such as Set-Cookie or Location, enabling session fixation or open redirects. Even in a read-only probe, injection can corrupt the header block format, causing undefined behavior in clients or intermediaries that parse responses.

During a black-box scan, middleware that reads raw headers and reflects them (e.g., via x-requested-for or custom headers) can inadvertently echo attacker-controlled CR/LF sequences. With Basic Auth present, scanners may also test whether credentials are accepted in different formats (e.g., Authorization: Basic base64) and whether injected headers are ignored or interpreted. Because Chi routes are built as compositional functions, misconfigured middleware order can allow injected headers to pass through to the response phase, creating a bypass surface for controls that assume strict header hygiene.

Real attack patterns mapped to this scenario include response splitting (CVE-like constructs where injected headers alter navigation or security directives) and unauthorized redirection. In the context of the 12 checks run by middleBrick, Header Injection is assessed alongside Authentication and Input Validation to determine whether user-controlled data reaches headers in a way that violates the integrity of the HTTP protocol. The scanner does not fix the implementation but provides findings with remediation guidance to ensure headers remain controlled and predictable.

Remediation focuses on preventing user-controlled data from reaching header construction and ensuring Basic Auth credentials are handled without side effects on downstream header logic. Validate and sanitize all inputs that may influence headers, and avoid reflecting raw request values into response headers.

Example of vulnerable code where user input leaks into headers:

(defn vulnerable-handler [request]
  (let [user-header (get-in request [:headers "x-custom-user"])
        auth-header (get-in request [:headers "authorization"])]
    {:status 200
     :headers {"x-user" user-header
               "server" "chi"}
     :body "ok"}))

In the example above, x-custom-user is reflected directly into the response headers. An attacker can supply a value containing \r\nSet-Cookie: auth=evil to inject a new header. With Basic Auth present, the Authorization header is parsed by Chi or your authentication middleware; ensure you do not inadvertently incorporate it into other headers.

Secure approach that sanitizes and avoids reflection of untrusted data:

(defn safe-handler [request]
  (let [auth-header (get-in request [:headers "authorization"])
        ;; Validate and parse Basic credentials without reflecting raw header values
        username (when auth-header
                   (some-> auth-header
                           (clojure.string/replace-first #"^Basic " "")
                           (.getBytes Standard/UTF_8)
                           String.))]
    ;; Do not include raw user-controlled headers in the response
    {:status 200
     :headers {"server" "chi"}
     :body (str "authenticated: " (boolean username))}))

Additional remediation steps include:

• Strictly allowlist known-safe header names and values; reject or neutralize any control characters in user input before any header assignment.
• Ensure authentication middleware that processes Basic Auth runs before any header-manipulating middleware, and avoid chaining user-supplied values into header maps.
• Use structured logging that does not concatenate raw headers into log lines that could be misinterpreted by downstream consumers.

Products such as the middleBrick CLI can be used to scan endpoints using Basic Auth to detect whether header injection is possible. Running middlebrick scan <url> against a Chi service that echoes headers or incorporates credentials into downstream routing can surface this class of issue, along with prioritized findings and remediation guidance mapped to frameworks such as OWASP API Top 10.