Denial Of Service in Aspnet with Hmac Signatures

In ASP.NET applications, HMAC signatures are commonly used to verify the integrity and origin of requests. A Denial of Service (DoS) vulnerability can emerge when signature validation is performed in a way that consumes disproportionate server resources before rejection, or when an attacker can force expensive computations for each request. For example, if the application computes HMAC-SHA256 on large payloads or on many concurrent requests without limits, CPU usage can spike, leading to thread pool starvation and unresponsiveness.

ASP.NET Core’s default model validation and signature verification run as part of request processing. If an endpoint accepts large JSON or form data and computes HMAC over the entire body for each request, an attacker can send many large, crafted requests to exhaust CPU. This is especially relevant when the endpoint performs expensive string operations or multiple hash computations (e.g., computing HMAC for multiple candidate keys or recomputing for logging). Even without authentication bypass, the combination of HMAC verification and high request volume can degrade service availability.

Another DoS vector arises from how ASP.NET handles model binding and custom HMAC filters. If the HMAC validation is implemented as an action filter that reads the request body stream multiple times or buffers large content synchronously, the app may block threads and increase latency under load. Real-world attack patterns include sending many requests with varying or malformed signatures to trigger repeated verification attempts, each consuming CPU cycles. In some cases, inefficient regular expressions or key derivation routines used for signature material further amplify resource consumption, aligning with broader OWASP API Top 10 categories such as Injection and Security Misconfiguration.

Consider a scenario where an endpoint expects an HMAC-SHA256 signature in a header and validates it by recomputing over the raw body. If the body is large or streamed inefficiently, each verification can block and accumulate latency. An attacker can exploit this by sending concurrent requests with large bodies, leading to thread pool exhaustion and timeouts. This pattern is detectable in scans that test unauthenticated attack surfaces, where high CPU usage correlates with specific endpoints that perform heavy cryptographic operations without rate limiting or payload size constraints.

To illustrate, a typical vulnerable implementation might compute HMAC per request without short-circuiting on obvious malformed inputs. For instance, reading the entire request body into memory and then computing the hash can be costly. In contrast, secure designs minimize work before validation, enforce size limits, and avoid expensive operations on untrusted input. MiddleBrick scans identify such risks by correlating endpoint behavior with resource-intensive patterns and flagging endpoints where HMAC verification coincides with high CPU or blocking I/O under stress.

Remediation focuses on making HMAC validation lightweight, predictable, and bounded. In ASP.NET Core, prefer asynchronous processing, early rejection of malformed requests, and limiting payload size before signature computation. Use cancellation tokens and avoid synchronous blocking calls. Below are concrete code examples that demonstrate secure patterns.

Example 1: Asynchronous HMAC validation with size limits

using System.Security.Cryptography;
using System.Text;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;

public class HmacValidationFilter : IAsyncActionFilter
{
    private const int MaxBodySize = 1024 * 1024; // 1 MB
    private static readonly TimeSpan ExpiryWindow = TimeSpan.FromMinutes(5);

    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        // Reject large payloads early to avoid expensive processing
        if (context.HttpContext.Request.ContentLength > MaxBodySize)
        {
            context.Result = new StatusCodeResult(413); // Payload Too Large
            return;
        }

        if (!context.HttpContext.Request.Headers.TryGetValue("X-API-Signature", out var signatureHeader))
        {
            context.Result = new UnauthorizedResult();
            return;
        }

        using var sha256 = SHA256.Create();
        await using var bodyStream = context.HttpContext.Request.Body;
        var computedHash = await sha256.ComputeHashAsync(bodyStream);
        var computedSignature = Convert.ToBase64String(computedHash);

        // Use a constant-time comparison to avoid timing leaks
        if (!CryptographicOperations.FixedTimeEquals(
                Convert.FromBase64String(signatureHeader), 
                Encoding.UTF8.GetBytes(computedSignature)))
        {
            context.Result = new UnauthorizedResult();
            return;
        }

        await next();
    }
}

Example 2: Controller with bounded model and short-circuit checks

using Microsoft.AspNetCore.Mvc;
using System.Security.Cryptography;
using System.Text;

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private const int MaxBodySize = 1024 * 1024;
    private readonly byte[] _secretKey;

    public OrdersController(IConfiguration config)
    {
        _secretKey = Convert.FromBase64String(config["Hmac:Secret"]);
    }

    [HttpPost]
    [RequestSizeLimit(MaxBodySize)]
    public IActionResult Create([FromBody] OrderRequest request)
    {
        if (!Request.Headers.TryGetValue("X-API-Signature", out var signature))
        {
            return Unauthorized();
        }

        var json = System.Text.Json.JsonSerializer.Serialize(request);
        using var hmac = new HMACSHA256(_secretKey);
        var hash = hmac.ComputeHash(Encoding.UTF8.GetBytes(json));
        var expected = Convert.ToBase64String(hash);

        if (!CryptographicOperations.FixedTimeEquals(Convert.FromBase64String(signature), hash))
        {
            return Unauthorized();
        }

        // Process order
        return Ok(new { Id = Guid.NewGuid() });
    }
}

public class OrderRequest
{
    public string ProductId { get; set; }
    public int Quantity { get; set; }
}

Operational best practices

• Enforce request size limits before reading the body to prevent resource exhaustion.
• Use asynchronous APIs for hashing to avoid thread pool starvation.
• Apply constant-time comparison to mitigate timing attacks.
• Rate limit endpoints that perform cryptographic validation to reduce load from bursts.
• Monitor CPU and latency metrics to detect abnormal patterns that may indicate DoS attempts.

These changes reduce the cost of HMAC validation and ensure that high request volumes do not degrade service availability. MiddleBrick can surface endpoints where HMAC processing coincides with high CPU or blocking behavior, helping you prioritize fixes.