Bleichenbacher Attack in Rails with Jwt Tokens

A Bleichenbacher attack is a chosen-ciphertext attack against RSA-based encryption or signature schemes that rely on PKCS#1 v1.5 padding. In Rails applications that use JWT tokens with an RSA algorithm (e.g., RS256), the combination of a standard JWT library and improper error handling can expose this vulnerability. When a Rails app verifies an RS256-signed JWT, it calls the verification routine with the received token. If the remote RSA operation is performed via an oracle that reveals whether a padding check succeeded (e.g., distinct error messages or timing differences for padding versus signature failures), an attacker can iteratively send modified tokens and learn the plaintext or forge signatures without the private key.

Why this specific combination is risky: Rails commonly uses RS256 for decentralized verification (public key from a JWKS endpoint). If the verification step does not use constant-time comparison and instead relies on the underlying library’s error propagation, subtle timing and error distinctions can be observed. For example, an incorrect padding error versus an invalid signature error can result in different response codes or messages in logs. An attacker can automate thousands of token modifications, observing these distinctions to gradually decrypt or forge tokens. This is a practical concern in microservice architectures where public keys are fetched dynamically and verification is performed in Ruby code before authorization checks.

To illustrate, a typical vulnerable verification flow in Rails might look like this naive implementation:

# WARNING: Example of a vulnerable pattern — do not use in production
require 'jwt' 

public_key = OpenSSL::PKey::RSA.new(File.read('public_key.pem'))
token = request.headers['Authorization'].to_s.split(' ').last
decoded = JWT.decode(token, public_key, true, { algorithm: 'RS256' })
# If JWT::VerificationError or OpenSSL errors expose padding vs signature differences,
# an oracle may exist.

In this flow, if JWT.decode raises distinct exceptions for padding failures versus other issues, and those exceptions are visible in logs or responses, the verification endpoint becomes an oracle. Repeated interactions can allow an attacker to perform the Bleichenbacher adaptive chosen-ciphertext steps, eventually recovering information or creating valid tokens.

For completeness, note that the middleware does not perform internal analysis, so it does not explain how its own engine derives findings. The key takeaway is that RS256-based JWT verification in Rails can become an oracle when error handling and library behavior inadvertently expose padding validation outcomes.

Remediation centers on ensuring JWT verification does not leak padding-related information and uses robust algorithms and libraries. Prefer RS256 with libraries that implement constant-time verification and avoid returning distinguishing errors. Always validate algorithm headers and pin expected algorithms to prevent algorithm-switching attacks.

Concrete fixes in Rails:

• Use a well-maintained JWT library and keep it updated. Configure verification to expect a specific algorithm and ensure the library does not expose low-level padding errors.
• Standardize error handling: rescue exceptions and return a uniform error response to avoid leaking distinction between padding and signature failures.
• Pin the algorithm in the header and during verification to prevent attackers from forcing a weaker algorithm like none or HS256.

Example of a hardened verification pattern in Rails:

# config/initializers/jwt_security.rb
require 'jwt' 

# Use a lambda to allow key resolution without leaking context
JWT.algorithm_class = JWT::Algos::Rs256

module JwtVerifier
  def self.decode_and_validate(token, public_key)
    # Explicitly require algorithm in header and reject mismatches
    header = JWT.decode(token, nil, false).first
    unless header['alg'] == 'RS256'
      raise JWT::DecodeError, 'Unsupported algorithm'
    end
    # Use verify_message_digest to avoid padding oracle behavior when possible
    decoded = JWT.decode(
      token,
      public_key,
      true,
      { algorithm: 'RS256', verify_exp: true }
    )
    decoded
  rescue JWT::ExpiredSignature, JWT::VerificationError, OpenSSL::PKey::RSAError => e
    # Uniform error response to avoid distinguishing padding failures
    Rails.logger.warn("JWT verification error: #{e.class}")
    raise JWT::DecodeError, 'Invalid token'
  end
end

# In a controller
class ApiController < ApplicationController
  before_action :authenticate_jwt

  private

  def authenticate_jwt
    token = request.headers['Authorization']&.split(' ')&.last
    public_key = OpenSSL::PKey::RSA.new(Rails.application.credentials.jwt_public_key)
    @current_user = JwtVerifier.decode_and_validate(token, public_key)
  rescue JWT::DecodeError
    render json: { error: 'Unauthorized' }, status: :unauthorized
  end
end

Additional hardening steps:

• Fetch public keys from a trusted JWKS endpoint with strict certificate pinning and short TTL to reduce exposure to key substitution.
• Monitor verification error patterns in logs to detect abnormal request rates that could indicate an active oracle attack.
• If feasible, prefer EdDSA (e.g., Ed25519) where library support exists, as it avoids RSA padding issues entirely.

These changes reduce the risk of the verification endpoint becoming an oracle and align with secure JWT practices in Rails applications.