Bleichenbacher Attack in Fastapi with Hmac Signatures

A Bleichenbacher attack is a cryptographic padding oracle technique originally described for RSA PKCS#1 v1.5. In the context of FastAPI applications that use HMAC signatures, a similar timing-based oracle pattern can emerge when signature verification leaks information through response behavior or timing differences. When a FastAPI endpoint accepts a signature in a header or query parameter and performs an HMAC verification, an attacker can send many modified requests and observe subtle differences in timing or error messages to infer properties about the signature or the underlying secret.

With HMAC, the typical verification flow is: compute HMAC(secret, message) and compare it with the provided signature using a constant-time comparison. If the comparison is not constant-time, or if errors during parsing or verification are handled differently depending on the cause (e.g., malformed input vs. invalid signature), an attacker can exploit timing differences to mount a Bleichenbacher-style adaptive chosen-ciphertext attack. In FastAPI, this can occur when endpoints accept raw signature inputs and perform per-request HMAC computation without safeguards against timing attacks.

Consider a FastAPI endpoint that reads a token from a header and verifies an HMAC-SHA256 signature without constant-time comparison. An attacker can send modified tokens and measure response times; a slightly longer response may indicate a partial match in the HMAC computation, allowing the attacker to iteratively recover the signature or deduce information about the secret. This is especially relevant when the endpoint processes untrusted input and performs operations whose timing depends on the input, creating an implicit oracle.

Even when using standard libraries, subtle implementation details matter. For example, using Python’s hmac.compare_digest provides constant-time comparison, but if the endpoint raises different exceptions for malformed Base64 input versus a signature mismatch, the distinction can be probed. In an API that exposes version or debug information in error responses, an attacker correlates timing and error behavior to refine their guesses, effectively performing a Bleichenbacher-style adaptive attack against the HMAC verification path.

In a Black-box scan by middleBrick, such endpoints may surface findings related to Input Validation and Authentication, because the scanner can detect timing inconsistencies and error handling behaviors that suggest an oracle. The tool also inspects OpenAPI specs and runtime behavior; if the spec does not mandate constant-time verification or clearly describe error handling, middleBrick flags the risk and provides remediation guidance focused on mitigating timing-based oracle attacks.

To prevent Bleichenbacher-style timing oracle attacks in FastAPI when using HMAC signatures, adopt constant-time verification and ensure that error handling does not distinguish between malformed input and invalid signatures. Below are concrete, working examples that demonstrate secure implementation.

Example 1: Constant-time HMAC verification with FastAPI

Use hmac.compare_digest for signature comparison and return the same generic error for any verification failure.

from fastapi import FastAPI, Header, HTTPException, Request
import hmac
import hashlib

app = FastAPI()
SECRET = b'super-secret-key-12345'  # store securely, e.g., via secrets manager

def verify_hmac(message: bytes, received_signature: str) -> bool:
    computed = hmac.new(SECRET, message, hashlib.sha256).hexdigest()
    return hmac.compare_digest(computed, received_signature)

@app.post("/secure-endpoint")
async def secure_endpoint(request: Request, x_signature: str = Header(...)):
    body = await request.body()
    if not verify_hmac(body, x_signature):
        # Always return the same generic error to avoid leaking information
        raise HTTPException(status_code=400, detail="Invalid request")
    return {"status": "ok"}

Example 2: Validating and verifying with strict input handling

Ensure the signature is properly encoded and avoid branching on secret-dependent data. Also, normalize inputs to reduce side channels.

import base64
from fastapi import FastAPI, Header, HTTPException, Request
import hmac
import hashlib

app = FastAPI()
SECRET = b'super-secret-key-12345'

def safe_verify(message: bytes, signature_b64: str) -> bool:
    try:
        signature = base64.urlsafe_b64decode(signature_b64 + '===')
    except Exception:
        # Do not reveal why decoding failed; treat as invalid
        return False
    computed = hmac.new(SECRET, message, hashlib.sha256).digest()
    return hmac.compare_digest(computed, signature)

@app.post("/data")
async def handle_data(request: Request, x_auth_signature: str = Header(...)):
    payload = await request.body()
    if not safe_verify(payload, x_auth_signature):
        raise HTTPException(status_code=401, detail="Unauthorized")
    return {"result": "success"}

Operational and spec-level guidance

• Always use hmac.compare_digest or an equivalent constant-time comparison function; avoid naive == on strings derived from hex or base64 encodings.
• Return a uniform error response for any verification failure, and avoid exposing stack traces or detailed error messages in production.
• In your OpenAPI spec, document that the signature header is required and indicate that verification uses constant-time checks; this helps align implementation and informs automated scans like those from middleBrick.
• If you use frameworks or libraries that perform HMAC verification, verify that they do not introduce timing variability; if necessary, wrap the verification with your own constant-time logic as shown above.

By combining constant-time verification with consistent error handling, you reduce the risk of a timing oracle that could enable a Bleichenbacher-style adaptive attack against your HMAC-signed FastAPI endpoints.