Information Disclosure in Actix with Hmac Signatures

Actix web is a popular Rust framework for building HTTP services. When HMAC signatures are used to authenticate requests, implementation details can inadvertently disclose information about the server’s internal logic, keys, or user existence. Information disclosure in this context occurs when differences in response behavior, timing, or error messages reveal whether a provided HMAC signature is valid, partially valid, or associated with a known user or resource.

One common pattern is to compute an HMAC over a payload or set of parameters (including a user identifier or API key) and compare it with a value supplied by the client. If the comparison short-circuits on the first mismatched byte, an attacker can use timing differences to infer partial correctness. In Actix handlers, returning distinct HTTP status codes (e.g., 401 vs 403) or different response bodies depending on whether the user ID exists or the signature matches can leak whether a user account is valid, even when the endpoint otherwise fails authentication.

Another vector arises from how Actix applications handle deserialization and signature validation. For example, if an endpoint expects a JSON body with an api_key and an signature field, and the application first validates the existence of the key in a database before computing the HMAC, the order of operations can disclose whether a given api_key is present. An attacker can iterate over plausible keys and observe whether responses change from "key not found" to "invalid signature," effectively mapping the set of valid keys.

Insecure use of logging or debugging features in Actix middleware can compound the risk. If request metadata, headers containing the signature, or extracted user identifiers are logged in production or development modes, an attacker who gains access to logs can correlate signatures with user accounts or infer patterns used to construct valid signatures. Additionally, custom error handlers that expose stack traces or internal paths can inadvertently reveal how signatures are parsed and validated, assisting an attacker in refining injection or tampering attempts.

Real-world examples align with general API security risks cataloged in frameworks like OWASP API Security Top 10, where excessive information in responses and inconsistent error handling are common findings. For instance, returning a 404 for a missing user and a 401 for an invalid signature on an existing user provides clear signals. Even when responses use a uniform 401 status, variations in response length or wording can be measurable and exploitable.

To illustrate a typical vulnerable handler in Actix, consider an endpoint that reads api_key and signature from headers, looks up the key, and conditionally computes and compares HMAC. If the key is not found, the handler may return early with a different message than when the key exists but the signature does not match. This behavioral branching is what enables information disclosure. The remediation focuses on making validation paths consistent, avoiding early returns that expose existence, and ensuring that any cryptographic comparison is performed in a way that does not depend on secret-dependent branches observable to the network.

Remediation centers on ensuring that all validation paths produce uniform behavior, using constant-time comparison where applicable, and avoiding logging or exposing details about keys or user existence. Below are concrete Actix handler examples that demonstrate a secure approach.

Example: Uniform validation flow

Always perform the key lookup and HMAC verification even when the key is not found, and return a consistent error response. This prevents attackers from distinguishing between missing keys and invalid signatures.

use actix_web::{web, HttpResponse, Result};
use hmac::{Hmac, Mac};
use sha2::Sha256;
use std::collections::HashMap;

type HmacSha256 = Hmac<Sha256>;

// Simulated key store; in practice this would be a secure lookup service.
async fn get_key_owner(api_key: &str) -> Option<String> {
    let db: HashMap<&str, String> = [
        ("validkey123", "owner_a".to_string()),
        ("anotherkey456", "owner_b".to_string()),
    ].iter().cloned().collect();
    db.get(api_key).cloned()
}

pub async fn verify_hmac_endpoint(
    body: web::Json<serde_json::Value>,
    headers: actix_web::HttpRequest,
) -> Result<HttpResponse> {
    let signature_header = match headers.headers().get("X-API-Signature") {
        Some(v) => v.to_str().unwrap_or(""),
        None => return Ok(HttpResponse::unauthorized().json(serde_json::json!({ "error": "invalid_request" }))),
    };

    let api_key = match headers.headers().get("X-API-Key") {
        Some(v) => v.to_str().unwrap_or(""),
        None => return Ok(HttpResponse::unauthorized().json(serde_json::json!({ "error": "invalid_request" }))),
    };

    let payload = body.get("data").and_then(|v| v.as_str()).unwrap_or("");

    // Always compute expected signature if key is known; otherwise use a dummy to keep timing similar.
    let owner = get_key_owner(api_key).await;
    let computed = match &owner {
        Some(owner) => {
            let mut mac = HmacSha256::new_from_slice(format!("{}:{}", api_key, owner).as_bytes())
                .map_err(|_| actix_web::error::ErrorInternalServerError("hmac_init_error"))?;
            mac.update(payload.as_bytes());
            mac.finalize().into_bytes()
        },
        None => {
            // Use a zero-length or constant dummy signature to keep timing consistent.
            [0u8; 32].to_vec()
        }
    };

    // Constant-time comparison to avoid timing leaks.
    let received = match hex::decode(signature_header) {
        Ok(bytes) => bytes,
        Err(_) => return Ok(HttpResponse::unauthorized().json(serde_json::json!({ "error": "invalid_request" }))),
    };

    let valid = subtle::ConstantTimeEq::ct_eq(&computed, &received);
    if valid.into() {
        match owner {
            Some(o) => Ok(HttpResponse::ok().json(serde_json::json!({ "owner": o, "status": "verified" }))),
            None => // Even if key not found, return generic success shape to avoid disclosure.
                Ok(HttpResponse::unauthorized().json(serde_json::json!({ "error": "invalid_signature" }))),
        }
    } else {
        // Always return the same status and shape regardless of whether key exists.
        Ok(HttpResponse::unauthorized().json(serde_json::json!({ "error": "invalid_signature" })))
    }
}

Key remediation practices

• Use constant-time comparison (e.g., subtle::ConstantTimeEq) for HMAC bytes to prevent timing-based inference.
• Ensure that the presence or absence of a key does not change HTTP status codes, response structure, or timing characteristics in a detectable way.
• Avoid logging raw signatures, API keys, or user identifiers in production; if logging is required, redact or hash sensitive values.
• Prefer environment-based configuration for secrets and keys rather than embedding them in source; rotate keys regularly.
• Treat error messages uniformly; avoid branching logic that reveals whether a user or key exists based on early returns.

By aligning implementation with these practices, Actix services can mitigate information leakage while still using HMAC signatures effectively for request authentication.