Poodle Attack in Express with Bearer Tokens

The Poodle attack (CVE-2014-3566) exploits weaknesses in SSL 3.0, particularly its use of CBC-mode ciphers and the padding oracle that arises from error handling during decryption. When an Express service is configured to support SSL 3.0 and relies on Bearer Tokens in HTTP headers for authorization, the combination can expose both the token and session data to an active network adversary.

In this context, Express serves as the HTTP server framework, and Bearer Tokens are typically passed via the Authorization header (Authorization: Bearer ). If an attacker can position themselves on the network (e.g., as a man-in-the-middle) and force or trick a client into using SSL 3.0, they can perform a padding oracle attack by iteratively observing whether SSL handshake or API responses reveal padding errors. Successful decryption of a ciphertext block can leak the plaintext, which may include cookies or other authorization data. Even when Bearer Tokens are used instead of cookies, if any part of the request or response carries sensitive information and SSL 3.0 is enabled, the oracle can expose portions of the token or related session material through crafted requests and error differentials.

Moreover, if the Express server negotiates SSL 3.0 with a client and the token is transmitted in a header, the token’s exposure risk increases because SSL 3.0 does not protect the integrity of the encrypted records in the same way as modern TLS versions. An attacker who can inject malicious requests and observe responses may gradually decrypt blocks, revealing the token. This is especially dangerous when the token is long-lived or when the API does not enforce strict transport-layer requirements. Note: middleBrick scans for such weak protocol support as part of its Encryption checks and flags servers that still accept SSL 3.0.

Remediation centers on disabling SSL 3.0 and enforcing strong TLS settings, while continuing to use Bearer Tokens securely. Below are concrete Express examples that show both the vulnerable setup and the hardened configuration.

Vulnerable setup (do not use)

const https = require('https');
const fs = require('fs');
const express = require('express');
const app = express();

const options = {
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt'),
  // This enables SSLv3, which is unsafe
  secureOptions: require('constants').SSL_OP_ALLOW_NO_DHE_KEX,
  // Intentionally weak ciphers for demonstration of bad practice
  ciphers: 'DES-CBC3-SHA:RC4-SHA'
};

https.createServer(options, app).listen(443, () => {
  console.log('Server running on port 443');
});

app.get('/api/resource', (req, res) => {
  const token = req.headers.authorization && req.headers.authorization.split(' ')[1];
  if (!token) return res.status(401).send('Unauthorized');
  // Process request with Bearer token
  res.json({ message: 'OK' });
});

Hardened setup (recommended)

const https = require('https');
const fs = require('fs');
const express = require('express');
const app = express();

const tls = require('tls');

const options = {
  key: fs.readFileSync('server.key'),
  cert: fs.readFileSync('server.crt'),
  // Use only secure protocols; explicitly disable SSLv3
  secureOptions: tls.constants.SSL_OP_NO_SSLv3 | tls.constants.SSL_OP_NO_SSLv2,
  // Prefer modern ciphers; prioritize AEAD suites
  ciphers: [
    'TLS_AES_256_GCM_SHA384',
    'TLS_CHACHA20_POLY1305_SHA256',
    'TLS_AES_128_GCM_SHA256'
  ].join(':'),
  honorCipherOrder: true
};

https.createServer(options, app).listen(443, () => {
  console.log('Server running on port 443 with TLS only');
});

app.get('/api/resource', (req, res) => {
  const auth = req.headers.authorization || '';
  const parts = auth.trim().split(/\s+/);
  if (parts.length !== 2 || parts[0].toLowerCase() !== 'bearer') {
    return res.status(401).json({ error: 'invalid_token', error_description: 'Authorization header must be Bearer ' });
  }
  const token = parts[1];
  // Validate token format and scope as needed
  if (!isValidToken(token)) {
    return res.status(401).json({ error: 'invalid_token', error_description: 'Token validation failed' });
  }
  res.json({ message: 'OK' });
});

function isValidToken(token) {
  // Implement token validation (e.g., introspection, JWT verification)
  return typeof token === 'string' && token.length > 10;
}

Additional recommendations beyond code:

• Always use HTTP Strict Transport Security (HSTS) with a suitable max-age to prevent protocol downgrade attacks.
• Ensure your TLS certificates are valid and issued by a trusted CA; use strong key sizes (2048-bit or higher for RSA, or ECDSA P-256+).
• When validating Bearer Tokens, prefer libraries that handle JWT verification with audience and issuer checks, and avoid manual parsing when possible.
• Use middleware to reject requests that do not present a properly formatted Authorization header, and log suspicious patterns without exposing sensitive data in logs.

middleBrick’s scans include checks for weak encryption settings and can surface servers that still accept SSL 3.0 or use deprecated ciphers, helping you identify endpoints that could be leveraged in Poodle-style attacks.