Integer Overflow in Aspnet with Dynamodb

When an ASP.NET application interacts with Amazon DynamoDB, integer overflow can arise from unchecked arithmetic used to compute request parameters, page sizes, or pagination tokens before values are passed to the DynamoDB client. In a black-box scan, middleBrick tests input validation and property authorization by sending oversized numeric inputs and inspecting whether the service enforces safe ranges.

DynamoDB expects numeric values such as Limit, Page, or custom sort-key offsets to fit within service-defined bounds. If an ASP.NET controller performs operations like page * size using 32-bit integers and an attacker supplies large query parameters, the resulting value can wrap around, producing a small number that bypasses expected limits. Because DynamoDB does not automatically reject a wrapped integer, the request may read or write more items than intended, enabling unauthorized data exposure or excessive consumption.

For example, consider computing an offset for a paginated query:

int page = int.Parse(context.Request.Query["page"]);
int size = int.Parse(context.Request.Query["size"]);
int offset = page * size; // vulnerable to overflow if page or size is large

If page or size is large enough that page * size exceeds int.MaxValue, the multiplication wraps to a negative or small positive number. When this value is used with DynamoDB operations such as QueryRequest, the effective limit may become incorrect, bypassing intended authorization checks.

DynamoDB’s own limits (e.g., a maximum page size of 1 MB) do not protect against application-layer integer overflow; they only constrain payload size. An attacker can craft requests where the overflowed value appears valid to the application but maps to an unintended range in DynamoDB, leading to unauthorized access across user boundaries (BOLA/IDOR) or privilege escalation via BFLA. middleBrick’s checks for BOLA/IDOR and Property Authorization specifically probe these paths by manipulating numeric identifiers and inspecting authorization outcomes.

Additionally, overflow can occur when aggregating values returned by DynamoDB, such as summing numeric attributes for reporting. If the client uses unchecked C# arithmetic, totals can wrap and be misinterpreted, potentially leading to incorrect business logic or exposure of aggregated sensitive data. Using long or System.Numerics.BigInteger and validating ranges before issuing DynamoDB requests mitigates these risks.

Remediation focuses on validating and bounding numeric inputs before they reach DynamoDB operations, using checked arithmetic, and enforcing explicit limits that align with DynamoDB constraints.

• Validate and bound inputs: ensure page and size values are within acceptable ranges before computing offsets.
• Use checked contexts or safe math libraries to detect overflow at runtime during development.
• Prefer long for offset and limit calculations to reduce overflow probability, and verify values against DynamoDB limits (e.g., max page size).
• Avoid trusting client-supplied values for critical parameters; derive server-side values where possible.

Example of a secure ASP.NET controller action with DynamoDB:

using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;
using System;

public class ItemsController : Controller
{
    private readonly IAmazonDynamoDB _ddb;
    private const int MaxPageSize = 100; // align with DynamoDB practical limits
    private const long MaxTotalItems = 10000;

    public ItemsController(IAmazonDynamoDB ddb)
    {
        _ddb = ddb;
    }

    public async Task<IActionResult> List(string userId, int page = 1, int size = 20)
    {
        // Validate inputs to prevent overflow and enforce authorization boundaries
        if (page < 1 || size < 1 || size > MaxPageSize)
        {
            return BadRequest("Invalid page or size.");
        }

        // Use long to reduce overflow risk and check against a safe total cap
        long offset = (long)page * size;
        if (offset > MaxTotalItems)
        {
            return BadRequest("Request too large.");
        }
        
        var request = new QueryRequest
        {
            TableName = "Items",
            KeyConditionExpression = "UserId = :uid",
            Limit = size,
            ExclusiveStartKey = offset > 0 ? new Dictionary<string, AttributeValue>
            {
                { "UserId", new AttributeValue { S = userId } },
                { "SortKey", new AttributeValue { N = offset.ToString() } }
            } : null,
            ExpressionAttributeValues = new Dictionary<string, AttributeValue>
            {
                { ":uid", new AttributeValue { S = userId } }
            }
        };

        var response = await _ddb.QueryAsync(request);
        return Ok(response.Items);
    }
}
In this example, inputs are bounded, offset is computed using long, and server-side caps prevent excessively large requests that could trigger overflow or unauthorized data access. For environments where unchecked contexts are possible, wrap arithmetic in checked blocks to raise exceptions on overflow during development.
middleBrick’s scans will highlight remaining weaknesses in input validation and property authorization. The Pro plan’s continuous monitoring can detect anomalous numeric patterns across scans, while the GitHub Action can fail builds if submitted payloads trigger insecure arithmetic paths.