Padding Oracle in Aspnet with Hmac Signatures

A padding oracle in an ASP.NET context arises when an application reveals whether decrypted padding is valid during decryption of an encrypted payload (e.g., an authentication cookie or an anti-forgery token). When HMAC signatures are used to provide integrity, the typical flow is: the message is encrypted, then a signature is computed over the ciphertext (Encrypt‑then‑Sign). If the server verifies the HMAC before decrypting, an invalid HMAC causes an early rejection that does not disclose padding validity. However, if the server decrypts first and then verifies the HMAC, and if error handling or timing behavior differs between a padding failure and a signature mismatch, an attacker can distinguish these cases.

Consider an ASP.NET application that uses HMACSHA256 to sign an encrypted payload and processes it as follows: decrypt the ciphertext using a symmetric algorithm such as AES‑CBC, then compute and compare the HMAC over the ciphertext. If the decryption routine throws distinct exceptions for invalid padding versus invalid signature, and if these exceptions result in different response times or status codes, an attacker can mount a padding oracle attack. By iteratively modifying ciphertext bytes and observing changes in server behavior (e.g., HTTP 400 vs 401, or response delays), the attacker can recover plaintext without the key. This is especially relevant when the encrypted payload contains authentication tokens or anti‑forgery cookies, because successful decryption and padding validation can lead to session takeover.

In practice, this combination is risky when:

• The server decrypts data before verifying integrity, and
• Error handling or timing leaks information about padding validity, even if an HMAC is present.

An example of a vulnerable pattern in ASP.NET Core might involve manually decrypting and then validating an HMAC, where exceptions from padding checks are not uniformly handled. For instance, if decryptUsingAes throws a CryptographicException on bad padding and the HMAC check throws a different exception or simply returns false, an attacker can infer the nature of the failure. The presence of HMAC does not prevent the oracle if the decryption step is performed before verification and its error behavior is observable.

To mitigate padding oracle risks when using HMAC signatures in ASP.NET, ensure integrity verification occurs before decryption and that error handling does not distinguish between padding and signature failures. The safest pattern is to verify the HMAC over the ciphertext first; only if the signature is valid should decryption proceed. This prevents attackers from using padding errors as an oracle because invalid ciphertexts are rejected early with a uniform error path.

Below are concrete, syntactically correct examples for ASP.NET Core using HMACSHA256 and AES‑CBC. The secure approach verifies the signature before decryption and uses a constant‑time comparison to avoid timing leaks.

Secure Encrypt‑then‑Sign flow with HMAC verification

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

public static class SecureCrypto
{
    // Constant-time comparison to avoid timing leaks
    private static bool FixedTimeEquals(byte[] a, byte[] b)
    {
        if (a.Length != b.Length) return false;
        int result = 0;
        for (int i = 0; i < a.Length; i++)
        {
            result |= a[i] ^ b[i];
        }
        return result == 0;
    }

    public static (byte[] ciphertext, byte[] hmac) EncryptAndSign(byte[] plaintext, byte[] key, byte[] hmacKey)
    {
        using var aes = Aes.Create();
        aes.Key = key;
        aes.GenerateIV();
        byte[] ciphertext;
        using (var encryptor = aes.CreateEncryptor())
        {
            ciphertext = encryptor.TransformFinalBlock(plaintext, 0, plaintext.Length);
        }

        byte[] ciphertextWithIv = new byte[aes.IV.Length + ciphertext.Length];
        Buffer.BlockCopy(aes.IV, 0, ciphertextWithIv, 0, aes.IV.Length);
        Buffer.BlockCopy(ciphertext, 0, ciphertextWithIv, aes.IV.Length, ciphertext.Length);

        byte[] hmac;
        using (var hmacSha = new HMACSHA256(hmacKey))
        {
            hmac = hmacSha.ComputeHash(ciphertextWithIv);
        }

        return (ciphertextWithIv, hmac);
    }

    public static byte[] DecryptAndVerify(byte[] ciphertextWithIv, byte[] hmac, byte[] key, byte[] hmacKey)
    {
        // Verify HMAC over ciphertext (including IV) before any decryption
        using (var hmacSha = new HMACSHA256(hmacKey))
        {
            byte[] computedHmac = hmacSha.ComputeHash(ciphertextWithIv);
            if (!FixedTimeEquals(computedHmac, hmac))
            {
                // Reject invalid HMAC uniformly; do not proceed to decryption
                throw new SecurityException("Invalid signature.");
            }
        }

        // HMAC valid: proceed with decryption
        using var aes = Aes.Create();
        aes.Key = key;
        byte[] iv = new byte[aes.IV.Length];
        byte[] ciphertext = new byte[ciphertextWithIv.Length - iv.Length];
        Buffer.BlockCopy(ciphertextWithIv, 0, iv, 0, iv.Length);
        Buffer.BlockCopy(ciphertextWithIv, iv.Length, ciphertext, 0, ciphertext.Length);
        aes.IV = iv;

        using var decryptor = aes.CreateDecryptor();
        return decryptor.TransformFinalBlock(ciphertext, 0, ciphertext.Length);
    }
}

Key points in this remediation:

• HMAC is computed over the IV plus ciphertext (Encrypt‑then‑Sign).
• Signature verification uses a constant‑time comparison to prevent timing side‑channels.
• If the HMAC is invalid, decryption is never attempted, eliminating the padding oracle.
• Exceptions from decryption are not used to signal signature failures; a single uniform rejection path is used.

For API security assessments, middleBrick can detect whether an endpoint decrypts before verifying integrity and whether error handling leaks padding information. Using the Web Dashboard or the middlebrick scan <url> CLI, you can identify such risky behaviors and validate that remediation aligns with secure Encrypt‑then‑Sign patterns. The Pro plan’s continuous monitoring helps ensure that future changes do not reintroduce these issues, and the GitHub Action can fail builds if risky API configurations are detected.