Time Of Check Time Of Use in Dynamodb

Time Of Check Time Of Use (TOCTOU) in DynamoDB occurs when an application performs a conditional check on an item's state, then performs an operation based on that check, but the item's state changes between these two operations. This race condition creates security vulnerabilities unique to DynamoDB's eventual consistency model and conditional write operations.

In DynamoDB, TOCTOU often appears in conditional writes where developers use ConditionExpression to verify an item's state before updating it. The application checks if an item exists or meets certain criteria, then attempts to update it. However, between the check and the write, another process could modify the item, causing the conditional write to fail or, worse, succeed with stale data.

A common DynamoDB TOCTOU pattern involves inventory management systems. Consider a shopping cart application that checks item availability before reserving stock:

async function reserveItem(cartId, itemId, quantity) {
  const params = {
    TableName: 'Inventory',
    Key: { itemId },
    ProjectionExpression: 'quantityAvailable',
    ConsistentRead: true
  };
  
  const item = await dynamo.get(params).promise();
  if (item.quantityAvailable >= quantity) {
    // TOCTOU window: state could change here
    const updateParams = {
      TableName: 'Inventory',
      Key: { itemId },
      UpdateExpression: 'set quantityAvailable = quantityAvailable - :val',
      ConditionExpression: 'quantityAvailable >= :min',
      ExpressionAttributeValues: {
        ':val': quantity,
        ':min': quantity
      }
    };
    await dynamo.update(updateParams).promise();
    return true;
  }
  return false;
}

The TOCTOU vulnerability here is that another request could modify quantityAvailable between the get and update operations, causing the conditional write to fail or succeed with incorrect assumptions about the item's state.

Another DynamoDB-specific TOCTOU scenario involves conditional deletes with optimistic locking. Developers often use version numbers or timestamps to prevent concurrent modifications:

async function deleteItemSafely(userId, itemId) {
  const params = {
    TableName: 'UserItems',
    Key: { userId, itemId },
    ProjectionExpression: 'version',
    ConsistentRead: true
  };
  
  const item = await dynamo.get(params).promise();
  if (item) {
    const deleteParams = {
      TableName: 'UserItems',
      Key: { userId, itemId },
      ConditionExpression: 'version = :ver',
      ExpressionAttributeValues: { ':ver': item.version }
    };
    // TOCTOU: version could change between get and delete
    await dynamo.delete(deleteParams).promise();
  }
}

The race condition exists because the version check and delete are separate operations. An attacker could exploit this by rapidly modifying the item's version between these operations, potentially bypassing authorization checks or causing inconsistent state.

Detecting TOCTOU vulnerabilities in DynamoDB requires analyzing both the application code patterns and the database access patterns. The most effective detection combines static code analysis with runtime scanning of DynamoDB operations.

Static analysis should look for specific code patterns that create TOCTOU windows. These include:

• Separate get and update/delete operations with conditional logic between them
• Conditional writes that don't use atomic operations
• Version-based optimistic locking implemented as separate read-modify-write cycles
• Inventory or quota management systems with separate check-and-update operations

Runtime scanning with middleBrick can identify TOCTOU vulnerabilities by analyzing the actual API endpoints that interact with DynamoDB. The scanner examines the request patterns and identifies endpoints that perform conditional operations on DynamoDB resources without proper atomicity guarantees.

middlebrick scan https://api.example.com/inventory

The scan would identify endpoints that:

• Perform separate read and write operations on DynamoDB tables
• Use conditional expressions without proper error handling for race conditions
• Implement optimistic locking patterns vulnerable to TOCTOU
• Manage inventory or quotas without atomic operations

middleBrick's DynamoDB-specific checks include analysis of conditional write patterns, version-based locking mechanisms, and inventory management operations. The scanner can detect when applications use separate operations where atomic transactions would be more appropriate.

For comprehensive detection, combine middleBrick scanning with DynamoDB's own monitoring tools. CloudWatch can reveal patterns of failed conditional writes that might indicate TOCTOU issues, while DynamoDB Streams can help identify when items are being modified in ways that could cause race conditions.

Remediating TOCTOU vulnerabilities in DynamoDB requires using the service's built-in atomic operations and conditional write capabilities correctly. The key principle is to eliminate the window between check and use by making operations atomic.

For inventory management scenarios, use DynamoDB's conditional update operations with proper error handling and retry logic:

async function reserveItemAtomic(cartId, itemId, quantity) {
  const params = {
    TableName: 'Inventory',
    Key: { itemId },
    UpdateExpression: 'set quantityAvailable = quantityAvailable - :val',
    ConditionExpression: 'quantityAvailable >= :min',
    ExpressionAttributeValues: {
      ':val': quantity,
      ':min': quantity
    },
    ReturnValues: 'UPDATED_NEW'
  };
  
  try {
    const result = await dynamo.update(params).promise();
    return result.Attributes.quantityAvailable >= 0;
  } catch (err) {
    if (err.code === 'ConditionalCheckFailedException') {
      return false; // Insufficient quantity
    }
    throw err;
  }
}

This approach eliminates the TOCTOU window by making the check and update atomic. The conditional expression ensures the operation only succeeds if sufficient quantity exists at the moment of update.

For optimistic locking scenarios, use DynamoDB's conditional writes with version numbers, but implement proper retry mechanisms:

async function deleteItemSafely(userId, itemId) {
  const maxRetries = 3;
  
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const params = {
      TableName: 'UserItems',
      Key: { userId, itemId },
      ProjectionExpression: 'version',
      ConsistentRead: true
    };
    
    const item = await dynamo.get(params).promise();
    if (!item) return false;
    
    const deleteParams = {
      TableName: 'UserItems',
      Key: { userId, itemId },
      ConditionExpression: 'version = :ver',
      ExpressionAttributeValues: { ':ver': item.version }
    };
    
    try {
      await dynamo.delete(deleteParams).promise();
      return true;
    } catch (err) {
      if (err.code !== 'ConditionalCheckFailedException') {
        throw err;
      }
      // Retry if version changed (TOCTOU detected)
      await new Promise(resolve => setTimeout(resolve, 10));
    }
  }
  return false;
}

This pattern handles the TOCTOU scenario by retrying when the conditional check fails, ensuring the operation eventually succeeds with consistent state.

For complex multi-item operations, consider using DynamoDB Transactions to ensure atomicity across multiple items:

async function transferFundsAtomic(fromId, toId, amount) {
  const params = {
    TransactWriteItems: [
      {
        Update: {
          TableName: 'Accounts',
          Key: { userId: fromId },
          UpdateExpression: 'set balance = balance - :val',
          ConditionExpression: 'balance >= :min',
          ExpressionAttributeValues: { ':val': amount, ':min': amount }
        }
      },
      {
        Update: {
          TableName: 'Accounts',
          Key: { userId: toId },
          UpdateExpression: 'set balance = balance + :val',
          ExpressionAttributeValues: { ':val': amount }
        }
      }
    ]
  };
  
  try {
    await dynamo.transactWrite(params).promise();
    return true;
  } catch (err) {
    if (err.code === 'TransactionCanceledException') {
      return false;
    }
    throw err;
  }
}

Transactions provide ACID guarantees across multiple items, completely eliminating TOCTOU vulnerabilities in multi-item operations.