Hallucination Attacks in Aspnet with Hmac Signatures

In ASP.NET applications, a Hallucination Attack occurs when an untrusted client supplies data that the server treats as authoritative, leading to incorrect or fabricated internal state. This becomes especially risky when HMAC signatures are used to validate request integrity but are implemented inconsistently or with weak assumptions. HMAC signatures are designed to prove that a message has not been altered, yet if the server uses the signature to "confirm" the origin or correctness of data that is later processed without additional checks, an attacker can inject crafted input that the server hallucinates as valid.

Consider an API endpoint that accepts a JSON payload along with an HMAC-SHA256 signature in a header, and uses the signature to verify integrity before trusting the payload’s business fields. If the server computes the HMAC over only a subset of the transmitted data (for example, excluding certain mutable fields) or uses a weak key, an attacker can modify the excluded fields and still produce a valid signature for the subset. The server then hallucinates that the modified fields are legitimate because the signature check passes, leading to privilege escalation or unauthorized actions. This pattern is common when developers mistakenly believe that HMAC verification alone is sufficient for full request validation without corroborating data against a known source of truth.

In the context of LLM/AI Security checks that middleBrick runs, one specific risk is that hallucination-prone endpoints might be tricked into generating or exposing model prompts or sensitive outputs when fed maliciously signed requests. For instance, an attacker could send a request where the payload includes a crafted prompt or parameter that, when processed by an integrated LLM, causes the system to leak system prompts or produce unintended content. The HMAC check may pass, but the underlying logic incorrectly treats the attacker-controlled input as safe, enabling output manipulation or data exfiltration. This is relevant to the active prompt injection testing that middleBrick performs, where probes such as system prompt extraction and data exfiltration are executed against endpoints that rely on signature validation without strict input corroboration.

A concrete scenario in ASP.NET Core involves a controller that reads an HMAC header, recomputes the signature using a shared secret, and then deserializes the JSON body into a model. If the developer does not validate the model’s state independently of the signature, and instead relies on the presence of a valid signature to skip model validation, an attacker can supply a valid signature with a model containing impossible values (e.g., negative prices or out-of-range IDs). The server hallucinates these values as legitimate, potentially bypassing business rules or authorization checks. Such vulnerabilities are compounded when the endpoint also interfaces with AI components, as the hallucinated data may directly influence prompts or tool usage, increasing the risk of prompt injection or cost exploitation.

To detect these patterns, middleBrick’s LLM/AI Security checks include output scanning for PII, API keys, and executable code in LLM responses, as well as excessive agency detection for tool_calls and function_call patterns. These checks help identify endpoints where trusted-looking signatures fail to constrain downstream AI behavior. Additionally, the Inventory Management and Unsafe Consumption checks look for endpoints that accept signed input but do not reconcile it with internal state or access controls, which is a common precursor to hallucination attacks.

Developers should ensure that HMAC verification is applied consistently over the exact byte representation of the data that is ultimately used, and that any data used in security-sensitive decisions is validated against canonical sources, not just signature validity. Combining HMAC with strict model validation, anti-replay protections, and contextual authorization reduces the surface for hallucination attacks. middleBrick’s OpenAPI/Swagger spec analysis, with full $ref resolution, helps map which endpoints accept signed input and whether they correlate runtime findings with spec definitions, supporting more precise identification of these risks.

Remediation centers on ensuring that HMAC signatures cover all data that influences security-sensitive decisions, using a strong key, and validating inputs independently of signature checks. Below are concrete ASP.NET Core code examples that demonstrate secure handling of HMAC signatures.

First, define a helper to compute HMAC-SHA256 over a byte array using a secret key. Use a strong key stored securely (for example, from configuration or a key vault) and avoid hardcoding secrets in source code.

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

public static class HmacHelper
{
    public static string ComputeHmacSha256(string data, string secret)
    {
        using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(secret));
        var hash = hmac.ComputeHash(Encoding.UTF8.GetBytes(data));
        return Convert.ToBase64String(hash);
    }
}

Next, in your controller or middleware, compute the HMAC over the exact request payload bytes before model binding alters the stream. This prevents mismatches between what is signed and what is verified. For JSON payloads, read the raw body as a string or byte array, compute the HMAC, and compare it to the value provided by the client in a header (for example, X-API-Signature).

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IConfiguration _config;

    public OrdersController(IConfiguration config)
    {
        _config = config;
    }

    [HttpPost]
    public IActionResult CreateOrder([FromBody] OrderModel model)
    {
        var secret = _config["Hmac:Secret"];
        if (string.IsNullOrEmpty(secret))
        {
            return StatusCode(500, "HMAC secret not configured.");
        }

        // Read the raw request body without buffering issues
        string requestBody;
        using (var reader = new StreamReader(Request.Body))
        {
            requestBody = reader.ReadToEnd();
        }

        // Recompute HMAC over the raw body
        var computed = HmacHelper.ComputeHmacSha256(requestBody, secret);

        // Retrieve the client-provided signature (e.g., from header)
        if (!Request.Headers.TryGetValue("X-API-Signature", out var signatureValues) || signatureValues.Count != 1)
        {
            return Unauthorized("Missing signature.");
        }

        var provided = signatureValues[0];
        if (!CryptographicOperations.FixedEquals(Encoding.UTF8.GetBytes(computed), Encoding.UTF8.GetBytes(provided)))
        {
            return Unauthorized("Invalid signature.");
        }

        // After signature validation, validate model independently
        if (!ModelState.IsValid)
        {
            return BadRequest(ModelState);
        }

        // Ensure business rules are enforced regardless of signature
        if (model.Amount <= 0)
        {
            return BadRequest("Amount must be positive.");
        }

        // Proceed with order creation
        return Ok(new { OrderId = Guid.NewGuid() });
    }
}

public class OrderModel
{
    public string ProductId { get; set; }
    public decimal Amount { get; set; }
    public string CustomerId { get; set; }
}

Key points in this example:

• The HMAC is computed over the raw request body to ensure exact byte-for-byte correspondence.
• Model validation occurs after signature verification but is not skipped; invalid models are rejected independently.
• Business rules (such as positive amounts) are enforced explicitly, avoiding reliance on the signature to imply correctness.
• Use CryptographicOperations.FixedEquals to prevent timing attacks during signature comparison.

For scenarios where the request is not JSON (for example, form data or query parameters), compute the HMAC over the canonical serialized form that the client is expected to sign, and ensure the same serialization logic is used on both client and server. Avoid signing only a subset of fields; if partial signing is required for performance, corroborate the unsigned fields against server-side constraints, such as a database lookup or a whitelist.

Additionally, protect the HMAC secret using environment-specific configuration and rotate keys periodically. Combine HMAC with other protections such as replay counters or timestamps to mitigate replay attacks. middleBrick’s CLI tool (middlebrick scan <url>) and GitHub Action can help verify that your endpoints correctly validate both signatures and input, reducing the risk of hallucination attacks in production.