Bleichenbacher Attack in Strapi with Bearer Tokens

A Bleichenbacher attack is a padding oracle attack against RSA encryption, where an attacker submits many ciphertexts and observes differences in error messages or response behavior to gradually decrypt data or recover the private key. In Strapi, if Bearer Tokens are handled in a way that an attacker can distinguish between invalid token formats and valid-but-wrong tokens based on distinct server responses, a padding oracle condition can arise when encrypted tokens (or token-derived secrets) are processed insecurely.

Consider a scenario where Strapi issues encrypted Bearer Tokens or uses encrypted payloads (for example, a JWT encrypted with RSAES-OAEP) and returns different errors for malformed ciphertext versus padding errors. An attacker who can intercept or forge token ciphertexts can automate requests—each request revealing one bit of information about the plaintext token. Over many requests, this allows recovery of the token or the ability to forge valid tokens without knowing the private key.

Specifically for Strapi, if your authentication flow accepts an encrypted Bearer Token in an Authorization header and the server’s error handling leaks whether a token failed format checks versus decryption/padding checks, the unauthenticated attack surface includes this oracle behavior. The 12 security checks in middleBrick—especially Input Validation, Authentication, and Data Exposure—would flag inconsistent error responses and missing token integrity checks that enable such an oracle. Even without direct access to encrypted token internals, a misconfigured Strapi instance that exposes stack traces or distinct HTTP status codes for decryption failures can facilitate a Bleichenbacher attack on Bearer Tokens.

Real-world examples involve RSA-based token encryption schemes where PKCS#1 v1.5 padding is used and error messages differ between padding failures and valid decryption. In the API Security context, this maps to OWASP API Top 10:2023 Broken Object Level Authorization (BOLA) and Security Misconfiguration. middleBrick’s scan would surface findings like Missing Rate Limiting on authentication endpoints and Untrusted Inputs in token handling, which are prerequisites for making oracle attacks practical.

An attacker workflow might involve:

• Intercepting a Bearer Token ciphertext (e.g., from an insecure mobile app or a misconfigured client).
• Sending modified ciphertexts to Strapi endpoints with Authorization: Bearer <ciphertext>.
• Observing differences in HTTP status codes, response body content, or timing to infer padding validity.
• Iterating this process to decrypt or forge a valid token.

middleBrick’s LLM/AI Security checks are not directly designed to detect Bleichenbacher attacks, but the scanner’s focus on Input Validation, Authentication, and Data Exposure helps identify weak token handling that could enable oracle behavior. For compliance, this aligns with PCI-DSS requirements on cryptographic operations and OWASP API Top 10’s A01:2027 Broken Object Level Authorization.

Remediation focuses on ensuring that Bearer Token validation does not leak information via error paths and that tokens are cryptographically robust. Below are concrete steps and code examples for Strapi v4.

1. Standard JWT Bearer Token (stateless) — consistent error handling

Use a single catch-all error response for invalid tokens to prevent padding-oracle-style differentiation. Configure Strapi’s auth.js to return the same HTTP status and body shape for any token validation failure.

// ./src/middlewares/authentication.js
module.exports = (config, { strapi }) => {
  return async (ctx, next) => {
    try {
      await next();
    } catch (err) {
      // Normalize all auth errors to 401 with a generic message
      if (err.name === 'TokenExpiredError' || err.name === 'JsonWebTokenError' || err.name === 'NotBeforeError') {
        ctx.status = 401;
        ctx.body = { error: 'Unauthorized', message: 'Invalid or expired token' };
        return;
      }
      // Re-throw non-JWT errors for other handlers
      throw err;
    }
  };
};

Ensure your JWT verification uses strong algorithms and rejects none/simple. In config/server.js, set the JWT settings to RS256 with adequate key size (2048+ bits) and avoid allowing none algorithm.

2. Encrypted Bearer Tokens (if used) — constant-time checks and uniform failures

If you must handle encrypted tokens (e.g., encrypted JWTs), perform decryption and validation in constant time and avoid early exits that reveal padding errors. Use a library like node-rsa with proper error mapping.

// Example: decrypt and verify without leaking padding errors
const NodeRSA = require('node-rsa');
const publicKeyPem = process.env.TOKEN_PUBLIC_KEY; // store securely
const key = new NodeRSA(publicKeyPem);
key.setOptions({ encryptionScheme: 'pkcs1' }); // or 'oaep' for stronger security

// In your auth middleware
module.exports = (config, { strapi }) => {
  return async (ctx, next) => {
    const auth = ctx.request.header.authorization;
    if (!auth || !auth.startsWith('Bearer ')) {
      ctx.status = 401;
      ctx.body = { error: 'Unauthorized', message: 'Invalid or expired token' };
      return;
    }
    const token = auth.split(' ')[1];
    try {
      // Decrypt using constant-time patterns where possible; avoid branching on padding validity
      const decrypted = key.decrypt(token, 'utf8'); // Ensure this call uses OAEP when possible
      // Validate claims, audience, issuer uniformly
      const payload = JSON.parse(decrypted);
      if (!payload.sub || !payload.iat) {
        throw new Error('invalid_token');
      }
      ctx.state.user = payload;
      await next();
    } catch (err) {
      // Always return the same generic failure
      ctx.status = 401;
      ctx.body = { error: 'Unauthorized', message: 'Invalid or expired token' };
    }
  };
};

Note: node-rsa’s decrypt may still have timing variance; for high-security scenarios prefer JWTs with asymmetric signatures (RS256) rather than encrypted tokens, and rely on middleware that does not expose padding errors.

3. Transport and key management

Always serve Strapi over HTTPS to prevent token interception. Rotate RSA key pairs regularly and store public keys in environment variables or a secrets manager; never commit private keys to source control. Enforce strong token entropy and short lifetimes where feasible.

4. Additional hardening

• Enable rate limiting on authentication endpoints to slow down adaptive oracle attacks.
• Audit logs: record token validation failures without exposing details that could aid an attacker.
• Apply input validation to reject tokens with unexpected formats early (but ensure error paths do not distinguish between format vs crypto failures).

After applying these fixes, re-run a middleBrick scan to verify that Authentication, Input Validation, and Data Exposure findings are resolved and that error handling no longer leaks validation details.