Padding Oracle in Actix with Api Keys

A padding oracle in an Actix service that uses API keys occurs when error messages or timing differences during cryptographic validation reveal whether a provided API key (or a token derived from it) decrypts correctly. This leaks information that an attacker can use to iteratively recover the plaintext or the key, even though the API key itself is not the encryption key. In Actix, this often arises when encrypted request payloads or cookies are decrypted with a key derived from an API key, and the application returns distinct HTTP status codes or response bodies for padding errors versus other failures.

Consider an endpoint that expects an API key in a header and an encrypted cookie containing session data. The server derives a decryption key using a key-derivation function that includes the API key, then decrypts and validates the cookie. If padding validation fails and the server responds with a 400 and a "padding error" message, whereas a MAC or decryption failure results in 401 or 403, an attacker can observe these differences. By supplying modified ciphertexts and observing status codes or response times, the attacker can perform a padding oracle attack to recover the plaintext. This becomes more practical when the same API key is used across sessions or when key derivation does not sufficiently isolate per-session randomness (e.g., missing or static IVs).

Insecure implementation patterns in Actix can exacerbate this. For example, returning early with a detailed error from a decryption helper, or using non-constant-time comparisons for integrity checks, makes the oracle observable. The presence of an API key does not inherently weaken cryptography, but if the API key influences key material and the application leaks validation outcomes, the attack surface expands. An attacker who cannot directly observe decryption results might still exploit timing differences in a network that introduces measurable latency on successful versus failed padding checks.

To illustrate, a vulnerable Actix handler might look like this, where a distinct error path reveals padding issues:

use actix_web::{web, HttpResponse, Result};
use openssl::symm::{decrypt, Cipher};

async fn process(data: web::Json<serde_json::Value>, api_key: web::Header<String>) -> Result<HttpResponse> {
    let ciphertext = hex::decode(data["token"].as_str().unwrap_or("")).map_err(|_| HttpResponse::BadRequest().body("invalid base64"))?;
    // Derive a key using the API key — simplistic and risky in practice
    let key = derive_key(&api_key);
    let iv = &[0u8; 16]; // static IV — also problematic
    match decrypt(openssl::symm::Cipher::aes_256_cbc(), &key, Some(&iv), &ciphertext) {
        Ok(plaintext) => Ok(HttpResponse::Ok().json(serde_json::json!({ "data": plaintext }))),
        Err(e) => {
            if e.to_string().contains("padding") {
                HttpResponse::BadRequest().body("padding error")
            } else {
                HttpResponse::Unauthorized().body("auth failed")
            }
        }
    }
}

Here, the distinction between a padding error and other decryption errors, combined with the use of a static IV and an API-key-derived key, creates a practical padding oracle. An attacker can send manipulated ciphertexts and use the response body and status code to infer validity of padding, eventually recovering plaintext.

Remediation focuses on removing information leakage and ensuring cryptographic operations do not depend on the API key in a way that creates an oracle. In Actix, this means standardizing error responses, using constant-time validation, and ensuring per-request randomness.

First, avoid branching on padding errors. Return a uniform error response for all authentication/decryption failures and use a constant-time comparison or AEAD construction that does not expose padding errors. For key derivation, do not directly use the API key as a raw key; instead, use a proper key-derivation function with a unique, random salt or nonce per request or per session. Use a random IV for each encryption and transmit it with the ciphertext (e.g., prepended), never reuse an IV with the same key.

Below is a revised Actix handler that mitigates the padding oracle by normalizing errors and using a more robust approach. It uses the data_encoding crate for hex decoding and openssl for decryption with error handling that does not distinguish padding failures:

use actix_web::{web, HttpResponse, Result};
use openssl::symm::{decrypt, Cipher};
use data_encoding::HEXUPPER;

async fn process_secure(data: web::Json<serde_json::Value>, api_key: web::Header<String>) -> Result<HttpResponse> {
    let ciphertext = HEXUPPER.decode(data["token"].as_str().unwrap_or("").as_bytes())
        .map_err(|_| HttpResponse::BadRequest().body("invalid token"))?;
    if ciphertext.len() <= 16 {
        return Ok(HttpResponse::BadRequest().body("invalid token"));
    }
    // Derive key and nonce/salt properly — here simplified; use a KDF like HKDF in production
    let (key, iv) = derive_key_and_iv(&api_key, &ciphertext[..16]);
    match decrypt(Cipher::aes_256_cbc(), &key, Some(&iv), &ciphertext[16..]) {
        Ok(plaintext) => Ok(HttpResponse::Ok().json(serde_json::json!({ "data": plaintext }))),
        Err(_) => {
            // Always return the same generic error and status to prevent oracle
            HttpResponse::Unauthorized().body("invalid token")
        }
    }
}

// Example derive_key_and_iv — in practice use a KDF with per-request salt/nonce
fn derive_key_and_iv(api_key: &str, salt: &[u8]) -> (Vec<u8>, Vec<u8>) {
    use openssl::hash::MessageDigest;
    use openssl::pkcs5::pbkdf2_hmac;
    let mut key = vec![0u8; 32];
    let mut iv = vec![0u8; 16];
    pbkdf2_hmac(api_key.as_bytes(), salt, 10000, MessageDigest::sha256(), &mut key).ok();
    pbkdf2_hmac(api_key.as_bytes(), &salt[..8], 10001, MessageDigest::sha256(), &mut iv).ok();
    (key, iv)
}

Key improvements:

• No distinction between padding errors and other failures — all map to a generic 401 with the same body.
• Per-request salt derived from the ciphertext prefix ensures unique keys/IVs even if the same API key is reused.
• IV is not static and is derived alongside the key, preventing IV reuse.
• Input validation (length checks) happens before decryption to avoid processing malformed tokens differently.

In production, prefer authenticated encryption (e.g., AES-GCM) or an AEAD mode via openssl to eliminate padding entirely. Also, ensure API keys are treated as secrets and rotated regularly; do not log them or include them in error messages.