Crlf Injection in Fiber with Jwt Tokens

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) sequences into HTTP headers, causing header injection or response splitting. In the Fiber web framework for Go, this risk is particularly relevant when building authentication flows that set JWT-related response headers based on user-controlled input. If an application reads a token or a callback parameter from query strings, headers, or cookies and then writes that value into a new header without validation, an attacker can inject additional headers or even split the response.

Consider a login handler that redirects with an access token provided by the client or derived from an external source. A vulnerable pattern might look like this:

// Vulnerable: directly using user input in a header
app.Get("/login", func(c *fiber.Ctx) error {
	token := c.Query("token")
	return c.Redirect("http://example.com/callback?token=" + token)
})

If the token contains a sequence like \r\nSet-Cookie: session=evil, Fiber’s Redirect may pass the header value through to the underlying HTTP stack, resulting in injected headers. Because the handler deals with JWT tokens, an attacker can attempt to inject a new Set-Cookie header that carries a forged token, bypassing intended authentication boundaries. Even when tokens are validated, reflection of untrusted data in headers creates an opportunity to manipulate the response chain.

The impact is not limited to cookies. JWT tokens often include metadata in their claims that might be reflected in custom headers such as X-Access-Token. If the server places such reflected values into response headers without sanitization, an attacker can inject additional control characters. For example, a token value ending with \r\nX-Content-Type-Options: nosniff could cause the server to add an unexpected header, potentially weakening browser security mechanisms.

Because Crlf Injection is a classic web vulnerability (CWE-93), it maps to the OWASP API Top 10 and can facilitate attacks like cache poisoning, cross-site scripting via injected headers, or authentication bypass when combined with JWT handling. While the scanner’s checks such as Input Validation and Data Exposure help surface unsafe reflection patterns, developers must ensure that any user-influenced data used in headers is strictly sanitized before being passed to Fiber’s response utilities.

Remediation centers on never directly reflecting untrusted input into HTTP headers, especially when those headers are related to JWT handling. In Fiber, this means validating and sanitizing any token or parameter before using it in redirects, custom headers, or cookies. Below are concrete, safe patterns for working with JWT tokens in Fiber handlers.

Safe redirect with token preservation: When you need to redirect after issuing or receiving a JWT, avoid concatenating raw query parameters. Instead, use a whitelisted callback URL or encode the token as a secure, HttpOnly cookie rather than a query parameter. Query strings can be logged and leaked in referrers, increasing exposure.

// Safe: using a fixed redirect target with token in secure HttpOnly cookie
app.Post("/login", func(c *fiber.Ctx) error {
	// Validate credentials and create a signed JWT (pseudocode)
	token := "signed.jwt.token"

	// Set as HttpOnly, Secure cookie to mitigate XSS and leakage
	return c.Cookie(&fiber.Cookie{
		Name:     "access_token",
		Value:    token,
		Expires:  time.Now().Add(24 * time.Hour),
		HTTPOnly: true,
		Secure:   true,
		SameSite: fiber.CookieSameSiteLaxMode,
	})
})

Header reflection with strict allow-listing: If you must reflect a JWT-related value in a custom header, validate it against a strict pattern (e.g., base64url-encoded segments without control characters) and avoid using user input verbatim.

// Safe: validate token format before using in a custom header
import "regexp"

var tokenPattern = regexp.MustCompile(`^[A-Za-z0-9\-_=]+\.[A-Za-z0-9\-_=]+\.?[A-Za-z0-9\-_.+/=]*$`)

app.Get("/token", func(c *fiber.Ctx) error {
	provided := c.Query("token")
	if !tokenPattern.MatchString(provided) {
		return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid token"})
	}
	// Safe to set a custom header with the validated token
	c.Set("X-Access-Token", provided)
	return c.JSON(fiber.Map{"ok": true})
})

Avoiding response splitting in error paths: Ensure error messages and tokens are not concatenated into header values. Use structured error responses in the body and keep headers static.

// Safe: static headers, token never part of header value construction
app.Get("/validate", func(c *fiber.Ctx) error {
	token := c.Get("Authorization")
	if token == "" || !isValidJWT(token) { // isValidJWT checks signature and structure
		return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "unauthorized"})
	}
	// Proceed with business logic
	return c.JSON(fiber.Map{"valid": true})
})

These patterns reduce the risk of Crlf Injection by ensuring that any data resembling a JWT is either strictly validated, encoded, or kept out of header contexts. They complement the scanner’s checks such as Input Validation and Data Exposure by enforcing secure handling at the code level. When in doubt, prefer cookies with appropriate flags for token transmission rather than custom headers that may be vulnerable to injection if user input is incorporated.