Cache Poisoning in Aspnet (Csharp)

Cache poisoning in an ASP.NET context occurs when an attacker causes a server or upstream cache to store malicious content keyed by attacker-controlled inputs. In ASP.NET applications that rely on response caching, if user-controlled data such as route values, query strings, or headers are used to form the cache key without validation or normalization, an attacker can craft requests that poison the cache for subsequent users.

ASP.NET’s caching mechanisms, including MemoryCache and response caching via ResponseCache or middleware, can inadvertently use untrusted inputs as part of the cache key. For example, consider an endpoint that caches responses by query parameters to serve localized or parameterized data:

// Example of vulnerable caching in ASP.NET Core
app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("/products", async context =>
    {
        var category = context.Request.Query["category"];
        var cacheKey = $"products:{category}";
        if (!_cache.TryGetValue(cacheKey, out string result))
        {
            result = await GetProductsFromSource(category);
            _cache.Set(cacheKey, result);
        }
        await context.Response.WriteAsync(result);
    });
});

If the category parameter is user-supplied and not validated or normalized, an attacker can request /products?category=../admin or inject malicious content that gets cached under a key that other users subsequently request. This can lead to sensitive data exposure or execution of unintended logic when the poisoned cache entry is served.

Moreover, ASP.NET applications that integrate with external caches (e.g., Redis) and construct cache keys from user input without canonicalization amplify the risk. An attacker may exploit differences in encoding, case sensitivity, or path traversal sequences to map multiple malicious inputs to the same cache key, effectively forcing the cache to serve attacker-chosen content.

LLM/AI Security checks in middleBrick specifically detect scenarios where untrusted inputs influence cache behavior by flagging unsafe consumption patterns and improper authorization around cached data. This is important because cache poisoning can lead to issues such as Cross-Site Scripting (XSS) when malicious scripts are cached and later served to other users, or data leakage when sensitive responses are stored under predictable keys.

Real-world attack patterns mirror classic injection and cache manipulation techniques. For instance, an attacker may probe endpoints with crafted query strings or headers to observe whether responses differ based on cache state, which can be confirmed through repeated requests and analysis of timing or content. This behavior aligns with findings from middleBrick’s 12 security checks, which include Input Validation, Property Authorization, and Unsafe Consumption to surface such risks before they impact production.

To mitigate cache poisoning in ASP.NET with C#, ensure that cache keys are deterministic, normalized, and derived from trusted sources only. Avoid directly concatenating user input into cache keys. Instead, validate and sanitize inputs, and use a combination of static segments and hashed, canonical values.

One approach is to define an allowlist of acceptable values for parameters that influence caching. For the earlier example, you can validate the category against a known set and use a secure hash to generate the cache key:

// Remediated caching in ASP.NET Core with input validation and key normalization
private static readonly HashSet<string> AllowedCategories = new HashSet<string> { "electronics", "books", "clothing" };

app.UseEndpoints(endpoints =>
{
    endpoints.MapGet("/products", async context =>
    {
        var category = context.Request.Query["category"];
        if (!AllowedCategories.Contains(category))
        {
            context.Response.StatusCode = 400;
            await context.Response.WriteAsync("Invalid category");
            return;
        }
        // Normalize and hash the category for a safe cache key
        using var sha = System.Security.Cryptography.SHA256.Create();
        var normalized = category.Trim().ToLowerInvariant();
        var hash = Convert.ToBase64String(sha.ComputeHash(System.Text.Encoding.UTF8.GetBytes(normalized)));
        var cacheKey = $"products:{hash}";
        if (!_cache.TryGetValue(cacheKey, out string result))
        {
            result = await GetProductsFromSource(normalized);
            _cache.Set(cacheKey, result);
        }
        await context.Response.WriteAsync(result);
    });
});

Additionally, when using response caching attributes, explicitly define vary-by rules to prevent unintended cache sharing. In Razor Pages or MVC, prefer data annotations or policy-based authorization rather than relying on raw query parameters for cache differentiation:

// Using VaryByQueryKeys safely with whitelisted parameters
[ResponseCache(Duration = 30, VaryByQueryKeys = new[] { "category" }, Location = ResponseCacheLocation.Any)]
public IActionResult Products(string category)
{
    if (!_allowedCategories.Contains(category))
    {
        return BadRequest("Invalid category");
    }
    // Safe to cache because category is validated
    var model = _service.GetProducts(category);
    return View(model);
}

For distributed caches, ensure that keys are constructed with consistent casing and encoding, and avoid including user-controlled segments that could be manipulated to collide with internal keys. middleBrick’s Pro plan supports continuous monitoring and can alert you if cache-related anomalies are detected across your API surface, helping you catch regressions early.

Finally, apply defense in depth by combining input validation, strict key normalization, and regular scanning. The CLI tool (middlebrick scan <url>) and GitHub Action can be integrated into CI/CD pipelines to fail builds if risky caching patterns are detected, while the MCP Server enables rapid scanning from within AI coding assistants.