Ssrf in Aspnet with Hmac Signatures

Server-Side Request Forgery (SSRF) in ASP.NET applications becomes particularly risky when HMAC signatures are used to validate requests but the validation logic does not protect the full request surface. HMAC signatures are commonly employed to ensure integrity and authenticity of outbound calls or webhook notifications. In ASP.NET, you might generate a signature over selected parts of an HTTP request—such as query parameters, headers, or a JSON body—using a shared secret, and then send that signature in a header (e.g., X-Signature). If the application uses this signature only to verify that the payload was not tampered with, but still forwards user-controlled URLs or inputs to an internal HTTP client without proper SSRF mitigations, an attacker can trick the service into making arbitrary internal or external requests. The HMAC may validate successfully because the attacker can include the correct signature for a benign request, but the backend then uses that signature to authorize an additional, malicious call that the signature was never intended to cover. This mismatch between signature scope and actual request handling creates a security boundary bypass.

For example, an endpoint might accept a URL parameter url, compute an HMAC over the URL and a timestamp, and then forward the request to the provided URL after verifying the signature. If the signature verification does not ensure that the URL used for the outbound request is the same as the one signed, or if the application allows additional query parameters or headers to be appended before the request is issued, an attacker can supply a signed, benign URL that is then used as a pivot to reach internal services (e.g., http://169.254.169.254/latest/meta-data/) or internal network endpoints. The HMAC signature thus provides a false sense of security while the underlying SSRF permits unintended network interactions. In the context of OWASP API Top 10 and common cloud security concerns, this maps to broken object level authorization and excessive data exposure when internal resources are exposed through SSRF. Tools like middleBrick can detect such misconfigurations by analyzing the unauthenticated attack surface and identifying missing input validation and improper authorization controls around URL-driven requests.

In ASP.NET, developers must ensure that the data covered by the HMAC includes all inputs that affect the request destination and that the same data is used both for signing and for constructing the outbound request. Relying on partial coverage, or allowing dynamic path or host overrides after signature verification, can expose internal services to unauthorized access. Continuous scanning with middleBrick, including its OpenAPI/Swagger analysis with full $ref resolution, helps surface endpoints where user-controlled inputs reach HTTP clients without strict schema-validated constraints.

To remediate SSRF risks when HMAC signatures are used in ASP.NET, ensure that the set of data covered by the signature encompasses all inputs that affect the request destination, and enforce strict validation before performing any outbound call. Below are concrete code examples that demonstrate a safe approach.

First, define a method that computes the HMAC over a canonical string built from the parts of the request that must remain immutable. Use a strong algorithm such as HMACSHA256 and encode the result in a consistent format (e.g., lowercase hex).

using System.Security.Cryptography;
using System.Text;

public static class HmacUtils
{
    public static string ComputeHmac(string data, string secret)
    {
        using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(secret));
        var hash = hmac.ComputeHash(Encoding.UTF8.GetBytes(data));
        return BitConverter.ToString(hash).Replace("-", "").ToLowerInvariant();
    }
}

Next, when building the request to be forwarded, include all relevant inputs in the signed string and do not allow the destination to be altered after verification. For example, if you are forwarding based on a user-supplied URL, include the exact URL and selected headers in the signature, and then reconstruct the request using only those validated components.

public IActionResult ForwardRequest([FromQuery] string url, [FromQuery] string timestamp)
{
    var secret = Environment.GetEnvironmentVariable("HMAC_SECRET");
    var canonical = $"{url}|{timestamp}";
    var expectedSignature = HmacUtils.ComputeHmac(canonical, secret);

    if (!string.Equals(Request.Headers["X-Signature"], expectedSignature, StringComparison.Ordinal))
    {
        return StatusCode(401, "Invalid signature");
    }

    // Ensure the URL is not used directly for arbitrary redirects.
    // Instead, use a strict allowlist or a proxy that only targets known internal services.
    var targetUri = new Uri(url); // Validate scheme, host, and port before use
    if (!targetUri.Host.EndsWith("internal.example.com", StringComparison.OrdinalIgnoreCase))
    {
        return StatusCode(403, "Destination not allowed");
    }

    // Use a typed HttpClient with predefined policies to avoid SSRF
    // Do not append additional user-controlled data before sending
    var client = new HttpClient();
    var request = new HttpRequestMessage(HttpMethod.Get, targetUri);
    request.Headers.Add("X-Original-Timestamp", timestamp);
    var response = await client.SendAsync(request);
    return Content(await response.Content.ReadAsStringAsync());
}

Additionally, validate and restrict the destination host and scheme, and avoid allowing the URL path to be dynamically appended after signature verification. For higher assurance, use the middleBrick CLI (middlebrick scan ) or the GitHub Action to integrate checks into your CI/CD pipeline, ensuring that endpoints consuming user-controlled URLs for outbound calls are flagged before deployment. These steps align with findings mapped to frameworks such as OWASP API Top 10 and PCI-DSS.