Token Leakage in Aspnet with Hmac Signatures

Token leakage in ASP.NET applications that use HMAC signatures for request authentication occurs when the signature or the token it protects is unintentionally exposed in logs, error messages, URLs, or cross-system boundaries. HMAC signatures are typically generated by combining a secret key with request data (e.g., headers, query parameters, timestamps) and then added to an Authorization header. If the implementation does not carefully control where tokens and signatures travel, the security benefit of HMAC can be undermined.

Common leakage vectors include logging full HTTP request headers without redaction, where Authorization headers containing the signature are written to application or web server logs. In ASP.NET, developers may inadvertently log the contents of HttpRequest.Headers during diagnostics, exposing both the token and the signature. Error pages that return detailed exception information can also include query string values or headers used to compute the HMAC, providing an attacker with data needed to understand or partially forge signatures.

URLs are another common leakage path. If an API endpoint accepts sensitive identifiers or tokens as query parameters and then includes those values in the HMAC computation, those values may be stored in browser history, server access logs, or referrer headers. For example, a request like GET /api/resource?token=abc123 where token is part of the HMAC input can expose the token in logs and browser history, even if the signature itself is in a header. Referrer headers from subsequent cross-origin requests can further propagate the token.

Cross-system leakage can occur when ASP.NET services forward requests to downstream services while preserving headers. If an outgoing HttpClient in ASP.NET forwards the Authorization header containing the HMAC signature and token, and that downstream service logs or mishandles the header, the sensitive material is further exposed. Similarly, telemetry or health-check endpoints that echo headers for debugging can become unintended disclosure channels if they do not strip sensitive values.

To detect these patterns, middleBrick scans unauthenticated attack surfaces and, among its 12 security checks, examines Data Exposure and Input Validation to identify places where tokens or signatures may be leaked through outputs or improper handling. By correlating OpenAPI specifications with runtime behavior, the scan can highlight endpoints where sensitive tokens are reflected in responses or logged implicitly. This is especially important when HMAC-based schemes are used, because the presence of a signature does not prevent leakage of the underlying token or the context in which it is used.

Developers should treat HMAC signatures as sensitive as the tokens they protect and ensure that neither appears in logs, URLs, or error responses. Mitigations include strict header redaction in logging, avoiding sensitive data in query strings, and ensuring that forwarded requests do not propagate Authorization headers unnecessarily. middleBrick’s LLM/AI Security checks also help by detecting system prompt leakage and insecure handling patterns that could lead to inadvertent exposure of tokens or keys in AI-integrated workflows.

Remediation focuses on preventing tokens and signatures from appearing in logs, URLs, or unintended outputs, and on ensuring that HMAC computation and transmission are handled securely in ASP.NET. Below are concrete code examples and practices tailored to ASP.NET Core.

• Do not include sensitive tokens in query strings. Use POST or other methods with body payloads, and keep tokens out of URLs to avoid logging and referrer leaks.
• Redact Authorization headers in logging. Configure logging filters in ASP.NET Core to exclude headers containing sensitive authorization data.

Example: Redacting Authorization headers in ASP.NET Core logging

// In Program.cs or Startup configuration
builder.Logging.AddFilter("Microsoft.AspNetCore.Http.HttpRequest", LogLevel.Warning);
builder.Logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);

// Add a custom filter to redact sensitive headers
builder.Services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
builder.Services.AddLogging(loggingBuilder =>
{
    loggingBuilder.AddFilter((category, level) =>
    {
        // Filter logic can be refined to exclude sensitive headers
        return level >= LogLevel.Warning;
    });
});

Example: Secure HMAC signature generation and transmission in an ASP.NET Core API

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

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private const string Secret = "your-256-bit-secret"; // store securely, e.g., Azure Key Vault or configuration with restricted access

    [HttpPost("create")]
    public IActionResult CreateOrder([FromBody] Order order)
    {
        var timestamp = DateTimeOffset.UtcNow.ToUnixTimeSeconds().ToString();
        var payload = $"{order.Id}:{order.Amount}:{timestamp}";
        var signature = ComputeHmacSha256(payload, Secret);

        // Send signature in a custom header, avoid including token in URL
        Response.Headers.Add("X-API-Signature", signature);
        Response.Headers.Add("X-API-Timestamp", timestamp);
        // Do NOT add sensitive token to response body or headers unnecessarily
        return Ok(new { orderId = order.Id });
    }

    private static string ComputeHmacSha256(string message, string key)
    {
        var keyBytes = Encoding.UTF8.GetBytes(key);
        var messageBytes = Encoding.UTF8.GetBytes(message);
        using var hmac = new HMACSHA256(keyBytes);
        var hash = hmac.ComputeHash(messageBytes);
        return Convert.ToBase64String(hash);
    }
}

Example: HttpClient usage in ASP.NET Core that avoids forwarding sensitive headers unintentionally

using System.Net.Http.Headers;
using System.Text;
using System.Security.Cryptography;

public class SecureClientService
{
    private readonly HttpClient _httpClient;
    private const string Secret = "your-256-bit-secret";

    public SecureClientService(HttpClient httpClient)
    {
        _httpClient = httpClient;
        _httpClient.BaseAddress = new Uri("https://api.example.com");
    }

    public async Task<HttpResponseMessage> SendSignedRequestAsync(Order order)
    {
        var timestamp = DateTimeOffset.UtcNow.ToUnixTimeSeconds().ToString();
        var payload = $"{order.Id}:{order.Amount}:{timestamp}";
        var signature = ComputeHmacSha256(payload, Secret);

        var request = new HttpRequestMessage(HttpMethod.Post, "/orders");
        var content = new StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(order), Encoding.UTF8, "application/json");
        request.Headers.Add("X-API-Signature", signature);
        request.Headers.Add("X-API-Timestamp", timestamp);
        request.Content = content;

        // Avoid automatically forwarding sensitive headers to downstream services unless required
        var response = await _httpClient.SendAsync(request);
        return response;
    }

    private static string ComputeHmacSha256(string message, string key)
    {
        var keyBytes = Encoding.UTF8.GetBytes(key);
        var messageBytes = Encoding.UTF8.GetBytes(message);
        using var hmac = new HMACSHA256(keyBytes);
        var hash = hmac.ComputeHash(messageBytes);
        return Convert.ToBase64String(hash);
    }
}

Additional measures include rotating secrets, validating timestamps to prevent replay, and ensuring that telemetry or debug endpoints strip sensitive headers. middleBrick’s Pro plan supports continuous monitoring and can integrate with CI/CD pipelines to flag configurations that risk token leakage, while the CLI allows quick scans from the terminal to verify that no sensitive tokens appear in observable behavior.