Beast Attack in Sails with Basic Auth

A Beast Attack (Browser Exploit Against SSL/TLS) is a side-channel attack that exploits the way browsers make repeated connections to the same origin using different TLS records. When Sails applications protect API routes with Basic Auth over HTTPS, the combination can still expose information through timing differences and record-size leakage even if the cipher suite itself is not weak.

Sails is a Node.js web framework that typically terminates TLS at a reverse proxy or load balancer, then forwards requests over plain HTTP to the Sails app. If Basic Auth credentials are passed in headers on every request, an attacker controlling a browser can open many concurrent sessions to the same authenticated endpoint and observe subtle timing or length variations. These variations can correlate with whether a given request path or parameter triggers different internal logic or data access patterns.

Basic Auth sends credentials on every request as a base64-encoded string; if the Sails app does not enforce strict transport security and consistent response characteristics, an attacker may infer authorization boundaries or resource presence by measuring request durations. For example, an endpoint that conditionally returns sensitive data based on user permissions might exhibit measurable differences when a valid credential is provided versus an invalid one, especially when TLS session reuse and record fragmentation interact in the browser stack.

middleBrick scans can detect related issues under the Authentication and Data Exposure checks by analyzing unauthenticated behavior and response characteristics, helping you identify inconsistent timing or information leakage that may facilitate a Beast Attack vector in Sails with Basic Auth.

To reduce the risk of side-channel and information leakage when using Basic Auth in Sails, apply consistent response behavior, enforce TLS, and avoid branching on credential validity in timing-sensitive code paths.

1. Enforce HTTPS and HSTS

Ensure all Sails routes are served over HTTPS and that HSTS is configured at the proxy or load balancer level. Never allow cleartext HTTP for authenticated endpoints.

// config/security.js
module.exports.security = {
  // Enforce HTTPS in production
  hsts: {
    enable: true,
    maxAge: 31536000,
    includeSubDomains: true,
    preload: true
  },
  // Ensure cookies and auth headers are only sent over HTTPS
  secureCookies: true
};

2. Constant-time comparison for credentials

When validating Basic Auth credentials, avoid early exits that depend on secret data. Use a constant-time comparison to prevent timing leaks that could aid a Beast Attack.

// services/auth.js
const crypto = require('crypto');

module.exports.compareBasicCredentials = function(inputUser, inputPass, expectedUser, expectedPass) {
  const userMatch = crypto.timingSafeEqual(Buffer.from(inputUser), Buffer.from(expectedUser));
  const passMatch = crypto.timingSafeEqual(Buffer.from(inputPass), Buffer.from(expectedPass));
  return userMatch && passMatch;
};

// controllers/AuthController.js
module.exports.login = async function(req, res) {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Basic ')) {
    return res.unauthorized();
  }
  const decoded = Buffer.from(authHeader.split(' ')[1], 'base64').toString('utf8');
  const [user, pass] = decoded.split(':');
  const expectedUser = 'api_user';
  const expectedPass = process.env.BASIC_AUTH_PASS;

  const isValid = AuthService.compareBasicCredentials(user, pass, expectedUser, expectedPass);
  // Always take the same code path to avoid branching on secret data
  if (!isValid) {
    // Return a generic error with the same response shape and timing characteristics
    return res.status(401).json({ error: 'Unauthorized' });
  }
  return res.ok({ status: 'authenticated' });
};

3. Uniform response shape and headers

Make responses for authenticated and unauthenticated requests structurally similar, including consistent headers and body length, to reduce information leakage observable by an attacker.

// policies/authenticate.js
module.exports.authenticate = async function(req, res, next) {
  const authHeader = req.headers.authorization;
  const hasAuth = !!authHeader && authHeader.startsWith('Basic ');
  // Perform validation without branching on secret data
  let isValid = false;
  if (hasAuth) {
    const decoded = Buffer.from(authHeader.split(' ')[1], 'base64').toString('utf8');
    const [user, pass] = decoded.split(':');
    const expectedUser = 'api_user';
    const expectedPass = process.env.BASIC_AUTH_PASS;
    isValid = crypto.timingSafeEqual(Buffer.from(user), Buffer.from(expectedUser)) &&
              crypto.timingSafeEqual(Buffer.from(pass), Buffer.from(expectedPass));
  }
  // Attach a flag for later use but do not exit early
  req._authValid = isValid;
  return next();
};

// controllers/UserController.js
module.exports.me = function(req, res) {
  // Always produce the same shape
  const response = {
    data: req._authValid ? { id: req.session.userId, role: req.session.role } : null,
    errors: req._authValid ? [] : [{ message: 'Unauthorized' }]
  };
  return res.ok(response);
};

4. Avoid conditional logic based on auth state

Refactor controllers to avoid early returns or different serialization paths when credentials are invalid. This reduces observable differences in response size and timing that could assist an attacker in a Beast Attack scenario.

// controllers/DataController.js
module.exports.list = async function(req, res) {
  const basePayload = { data: [], errors: [] };
  if (!req._authValid) {
    // Keep structure consistent
    return res.status(401).json(basePayload);
  }
  const records = await DataService.findAllForUser(req.session.userId);
  basePayload.data = records;
  return res.ok(basePayload);
};