Cache Poisoning in Aspnet with Dynamodb

Cache poisoning in an ASP.NET application that uses Amazon DynamoDB as a persistence layer typically occurs when unvalidated or attacker-influenced data is stored in a cache key, response, or downstream lookup that is later read from the cache and treated as trusted. Because ASP.NET applications often rely on in-memory or distributed caches to reduce repeated DynamoDB requests, an attacker can manipulate inputs that form cache keys or that are stored in cached objects, leading to unintended data disclosure, incorrect responses, or authentication bypass.

In this stack, a common scenario is an endpoint that accepts a user-supplied identifier (e.g., userId or tenantId), uses it to build a DynamoDB key (partition key or sort key), queries or gets an item, caches the result, and uses the same identifier to index into the cached data. If the identifier is not strictly validated, an attacker can supply values that cause cache collisions, overwrite legitimate cached entries, or force the application to retrieve a different user’s data from the cache. For example, a cache key built from an unescaped string can allow two distinct logical keys to map to the same cache entry, effectively exposing one user’s cached data to another.

DynamoDB-specific elements amplify the risk: partition key and sort key values often flow directly into cache identifiers, and conditional writes or queries that depend on user input can be manipulated to produce inconsistent cache states. If an attacker can control a component of the key used to store or retrieve cached objects, they may cause the application to serve a victim’s cached profile or pricing data, or to bypass authorization checks that rely on cached context.

Because middleBrick scans the unauthenticated attack surface and tests input validation, property authorization, and data exposure, it can surface these risks when unsafe key construction or cache-influencing parameters are detected. The scan does not fix the issue; it provides findings with severity, reproduction steps, and remediation guidance so developers can harden the ASP.NET layer and the DynamoDB access patterns.

Remediation focuses on strict input validation, canonical key construction, and isolating cache entries by design. Avoid using raw user input directly as cache keys or as components of DynamoDB keys without normalization and strict allowlists. Use deterministic, application-controlled identifiers for caching, and ensure authorization checks are re-evaluated on each request rather than relied upon cached context alone.

Use a consistent, normalized form for keys. For example, enforce lowercase usernames, trim and limit lengths, and avoid characters that affect cache or key equivalence. Implement cache key salting with a fixed application namespace to prevent collisions across different logical caches.

Example of unsafe usage to avoid:

// UNSAFE: direct user input used in cache key and DynamoDB key
var userId = httpContext.Request.Query["userId"];
var cacheKey = $"user:{userId}";
var cached = memoryCache.Get(cacheKey);
if (cached == null) {
    var response = await dynamoClient.GetItemAsync(new GetItemRequest {
        TableName = "Users",
        Key = new Dictionary<string, AttributeValue> {
            { "PK", new AttributeValue { S = $"USER#{userId}" } }
        }
    });
    memoryCache.Set(cacheKey, response.Item);
}
return cached;

Example of safer implementation with explicit key normalization and isolated cache namespaces:

// SAFE: canonical key, input validation, and namespaced cache keys
public bool TryParseUserId(string input, out string userId) {
    userId = null;
    if (string.IsNullOrWhiteSpace(input)) return false;
    var trimmed = input.Trim().ToLowerInvariant();
    if (!Regex.IsMatch(trimmed, @"^[a-z0-9._-]{3,32}$")) return false;
    userId = trimmed;
    return true;
}

public async Task<User> GetUserAsync(string rawUserId, CancellationToken ct) {
    if (!TryParseUserId(rawUserId, out var canonicalUserId)) {
        throw new ArgumentException("Invalid user identifier");
    }
    var namespacePrefix = "appname";
    var cacheKey = $"{namespacePrefix}:users:{canonicalUserId}";
    if (memoryCache.TryGetValue(cacheKey, out User cachedUser)) {
        return cachedUser;
    }
    var request = new GetItemRequest {
        TableName = "Users",
        Key = new Dictionary<string, AttributeValue> {
            { "PK", new AttributeValue { S = $"USER#{canonicalUserId}" } }
        }
    };
    var response = await dynamoClient.GetItemAsync(request, ct);
    var user = /* map response.Item to User */ null; // mapping logic
    if (user != null) {
        memoryCache.Set(cacheKey, user, TimeSpan.FromMinutes(30));
    }
    return user;
}

Additional hardening steps include: using a fixed, application-owned prefix for cache namespaces; re-verifying authorization on each request even when data is cached; avoiding caching of sensitive or high-variance data unless cache segregation is guaranteed; and monitoring DynamoDB request patterns to detect anomalies that may indicate probing for key collisions. middleBrick’s checks for input validation, property authorization, and data exposure help identify whether cache-influencing parameters are insufficiently constrained.