HIGH crlf injectionadonisjsjwt tokens

Crlf Injection in Adonisjs with Jwt Tokens

Crlf Injection in Adonisjs with Jwt Tokens — how this specific combination creates or exposes the vulnerability

Crlf Injection occurs when an attacker can inject carriage return (CR, \r) and line feed (\n) characters into a header or cookie value. In AdonisJS, this risk can intersect with JWT token handling when values derived from user input are used to construct authorization headers, redirect URLs, or cookie values that later influence HTTP responses. Because JWTs are often transported via headers (e.g., Authorization: Bearer ) or cookies, unsanitized user data that ends up in these vectors can enable header manipulation, session fixation, or cache poisoning.

Consider a scenario where an AdonisJS application accepts a user-controlled redirect target and places it into a Set-Cookie header alongside a JWT stored as a cookie. If the redirect value includes CRLF sequences, an attacker can inject additional headers or split the response, causing the browser to store a malicious cookie or bypass intended scope. Even when using JWTs for stateless authentication, the framework’s response-building logic must treat all external input as untrusted. The presence of a JWT does not prevent injection; it simply shifts the impact to how the application assembles headers and cookies around the token.

Another relevant pattern occurs when logging or error messages include the raw Authorization header value. If user input is concatenated into logs or debug output and later reflected in an HTTP response, CRLF characters can alter the structure of the logged transaction or facilitate response splitting. Because JWTs often contain claims that may be echoed in logs (e.g., sub or email), developers must ensure that any rendering of headers or cookies performs strict validation and sanitization. The risk is not in the JWT format itself, but in the handling of data that reaches headers and cookies without canonicalization or strict allowlists.

Jwt Tokens-Specific Remediation in Adonisjs — concrete code fixes

Remediation centers on input validation, canonicalization, and strict separation of data and header boundaries. Never directly interpolate user input into header values or cookie attributes. Instead, use framework helpers that enforce safe serialization. For JWTs, rely on the httpOnly and Secure cookie flags, and avoid embedding user-controlled data inside the token payload that could later be reflected into headers.

Example: safely setting a JWT cookie in AdonisJS with canonicalized values:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'

export default class AuthController {
  public async login({ request, response }: HttpContextContract) {
    const { email, password } = request.all()
    // Perform authentication and sign the JWT
    const token = jwt.sign({ sub: 1, email }, process.env.JWT_SECRET!, { expiresIn: '1h' })

    // Safe cookie construction: do not inject user input into header strings
    response.cookie('auth_token', token, {
      httpOnly: true,
      secure: true,
      sameSite: 'strict',
      path: '/',
    })

    return response.json({ ok: true })
  }
}

Example: validating a redirect target before use in a header-related flow:

import { HttpContextContract } from '@ioc:Adonis/Core/HttpContext'
import { schema, rules } from '@ioc:Adonis/Core/Validator'

const redirectSchema = schema.create({
  returnTo: schema.string.optional({}, [
    rules.url({ allowedProtocols: ['http', 'https'] }),
    rules.ipAllowed({ blockPrivate: true }),
    // Ensure no CRLF sequences are present
    rules.regex({ pattern: /^[^\r\n]*$/ }),
  ]),
})

export default class LoginController {
  public async handle({ request, response }: HttpContextContract) {
    const payload = await request.validate({ schema: redirectSchema })
    const returnTo = payload.returnTo || '/dashboard'

    // Safe usage: do not embed returnTo in a raw header string
    response.redirect(returnTo)
  }
}

Additional guidance: sanitize any data that may be concatenated into HTTP responses, including log entries. Use framework-level helpers for header and cookie setting, and avoid constructing raw header strings with concatenation. When integrating third-party libraries that manipulate JWTs, verify that they do not introduce unsanitized output into response-building logic. These practices reduce the likelihood of CRLF Injection affecting authentication flows that rely on JWT tokens.

Frequently Asked Questions

Can a JWT token itself contain CRLF sequences that affect parsing?
JWTs are base64url-encoded and do not allow raw CRLF characters in their encoded structure. However, if an application decodes a JWT and directly reflects claims into HTTP headers or cookies without sanitization, CRLF injection can occur at that boundary. Always validate and canonicalize reflected values.
Does enabling strict transport security (HSTS) prevent CRLF Injection with JWTs?
HSTS enforces HTTPS but does not prevent CRLF injection. Injection risks are mitigated by input validation, canonicalization, and avoiding the concatenation of untrusted data into headers or cookies, regardless of transport security.