Timing Attack in Express with Dynamodb

A timing attack in an Express service that uses DynamoDB typically arises when response time varies based on sensitive data, such as a username or API key, rather than solely on network conditions. In Express, route handlers often perform lookups by querying DynamoDB with user-supplied identifiers. If the application uses conditional logic that short-circuits on a mismatch (for example, comparing a candidate token character-by-character in JavaScript before issuing a DynamoDB request), an attacker can infer information from subtle differences in latency.

Consider an Express route that authenticates a user by comparing an incoming token against a stored value. If the comparison stops at the first mismatching character and only then issues a DynamoDB call, an attacker can send many guesses and measure response times to deduce the correct token one character at a time. The DynamoDB request itself may have consistent latency, but the observable response time of the Express endpoint varies because the CPU work in Node.js occurs before the database call. Even when DynamoDB is the backend, the application layer introduces variability that a remote attacker can measure.

Another scenario involves user enumeration. An Express route might first check whether a username exists in DynamoDB and then, if it exists, retrieve additional details. If the response time for a valid username differs from an invalid one, an attacker can learn which usernames are valid without needing credentials. With DynamoDB as the database, the timing difference may stem from conditional checks or early exits in the application logic before the query is issued, or from variations in provisioned capacity and consumed read capacity units, though the latter is less reliable and should not be depended on for security.

In the context of the LLM/AI Security checks provided by middleBrick, timing-related anomalies in Express endpoints that interact with DynamoDB are considered because such endpoints can leak information through side channels. The scanner tests whether the unauthenticated attack surface exhibits behavior that could allow an attacker to infer sensitive data from response timing, complementing checks for input validation and authentication. Note that middleBrick detects and reports these risks but does not fix or block the endpoint; it provides findings with severity, impact description, and remediation guidance.

To illustrate a vulnerable pattern, an Express handler might look like this, where comparison is done before a DynamoDB query, creating a timing discrepancy:

const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

app.get('/profile/:token', async (req, res) => {
  const candidate = req.params.token;
  const stored = 'expectedLongTokenValue12345';
  let valid = true;
  for (let i = 0; i < candidate.length; i++) {
    if (candidate[i] !== stored[i]) {
      valid = false;
      break;
    }
  }
  if (!valid) {
    return res.status(401).send('Unauthorized');
  }
  const params = {
    TableName: 'Users',
    Key: { token: candidate }
  };
  const data = await docClient.get(params).promise();
  res.json(data.Item || {});
});

Here, the loop in Node.js introduces timing variation before the DynamoDB get call, making the endpoint potentially vulnerable to a remote timing attack. An attacker can measure response times to infer how many initial characters match, even though DynamoDB itself is not the direct source of the timing variance.

Remediation focuses on ensuring that all operations that depend on sensitive values take constant time, regardless of the input, and that control flow does not leak information through timing differences. In Express with DynamoDB, this means avoiding early exits based on secrets and making database calls with parameters that do not reveal information via timing.

First, use a constant-time comparison for any secret validation, and ensure that DynamoDB requests are issued for all paths with similar shape and latency characteristics. For example, instead of breaking on the first mismatching character, compute the result after inspecting the full input and then perform a single DynamoDB call with a key that will either return no item or a valid item without branching on the secret itself.

Below is a revised version of the earlier route that avoids branching on the token before the database call:

const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

app.get('/profile/:token', async (req, res) => {
  const candidate = req.params.token;
  // Always perform a DynamoDB get; do not branch on token content in Node.js.
  const params = {
    TableName: 'Users',
    Key: { token: candidate }
  };
  try {
    const data = await docClient.get(params).promise();
    const item = data.Item;
    if (!item) {
      return res.status(404).send('Not found');
    }
    // If you must validate a secret stored in the item, do it after the DB call
    // using a constant-time comparison to avoid leaking timing information.
    res.json(item);
  } catch (err) {
    res.status(500).send('Internal error');
  }
});

This approach ensures that the timing of the DynamoDB call is consistent for valid and invalid tokens, and any further validation occurs after the database operation so that remote timing differences do not reveal whether a token prefix was correct.

For user enumeration, avoid indicating whether a username exists through timing differences. Instead of returning different HTTP statuses or response sizes, use a uniform response and ensure the DynamoDB query path is similar for existing and non-existing users when possible. For example:

app.post('/login', async (req, res) => {
  const { username, token } = req.body;
  const params = {
    TableName: 'Users',
    KeyConditionExpression: 'username = :u',
    ExpressionAttributeValues: { ':u': username }
  };
  try {
    const data = await docClient.query(params).promise();
    // Always perform a constant-time check, e.g., HMAC verification,
    // on the retrieved secret if present, and return a generic response.
    const item = data.Items && data.Items[0];
    if (item && constantTimeVerify(item.secretToken, token)) {
      res.json({ status: 'ok' });
    } else {
      res.json({ status: 'unauthorized' });
    }
  } catch (err) {
    res.status(500).json({ error: 'internal' });
  }
});

function constantTimeVerifier(a, b) {
  if (a.length !== b.length) return false;
  let result = 0;
  for (let i = 0; i < a.length; i++) {
    result |= a.charCodeAt(i) ^ b.charCodeAt(i);
  }
  return result === 0;
}

By ensuring that the DynamoDB query structure does not vary with secrets and by moving secret validation after the database call into a constant-time routine, you reduce the risk of timing-based information leakage. middleBrick’s LLM/AI Security checks can help identify endpoints that might expose timing anomalies by analyzing patterns in authentication flows and prompt injection tests, though it does not remediate the code.