Padding Oracle in Axum with Cockroachdb

A padding oracle attack occurs when an application exposes different error messages or behaviors depending on whether a ciphertext's padding is valid before decryption. In an Axum service that uses Cockroachdb as a data store, this typically manifests when encrypted data is stored in a column (for example, a BYTEA column) and later decrypted after retrieval. If the application returns distinct HTTP status codes or response bodies for padding errors versus other decryption or database errors, an attacker can iteratively modify ciphertexts and observe responses to gradually recover plaintext without knowing the key.

Consider an Axum endpoint that fetches a user profile encrypted at rest in Cockroachdb:

// Example: Axum handler that retrieves and decrypts a field from Cockroachdb
async fn get_profile(
    Path(user_id): Path,
    db: Extension,
) -> Result, (StatusCode, String)> {
    let row = db.query_one("SELECT encrypted_data FROM profiles WHERE id = $1", &[&user_id])
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let ciphertext: Vec<u8> = row.get(0);
    let plaintext = decrypt_aes_gcm(&ciphertext, KEY) // may leak padding errors
        .map_err(|e| (StatusCode::BAD_REQUEST, e.to_string()))?;
    // ... deserialize and respond
}

If decrypt_aes_gcm returns a distinct error for invalid padding versus other decryption failures, and the handler maps that to a specific status code (for example, 400), an attacker can use this as an oracle. They can craft requests that cause the server to attempt decryption of modified ciphertexts and infer validity from HTTP responses. Storing ciphertexts in Cockroachdb does not introduce the oracle by itself, but persistent storage enables repeated, controlled experiments: an attacker can retrieve a record, modify its encrypted blob, submit it to the endpoint, and observe whether the padding is correct based on timing or status differences.

The combination of Axum's flexible error handling and Cockroachdb's reliable storage means that if the application does not normalize error responses for decryption and database failures, the oracle becomes practical. For example, returning a generic 500 for all failures would remove the distinguishing signal, whereas leaking whether a record exists or whether padding is valid creates a foothold. This is especially relevant when the same endpoint both stores and retrieves data, because an attacker can use write operations to position known ciphertexts for read-based oracle queries.

To determine whether your Axum service is vulnerable, use a scanner that includes active LLM security probing and output scanning. middleBrick runs checks across categories such as Input Validation and Data Exposure, and its findings include severity and remediation guidance rather than attempting to fix or block traffic. In a scan report, you might see a finding mapped to OWASP API Top 10 and mapped to compliance frameworks like PCI-DSS, with guidance to ensure decryption errors do not vary by padding validity.

Remediation focuses on ensuring that error handling and cryptographic operations do not reveal padding validity. The safest approach is to make all failure paths indistinguishable to the attacker and to validate or authenticate ciphertext before attempting decryption. Below are concrete Axum examples that integrate with Cockroachdb using a prepared pool and constant-time comparison where applicable.

1. Use authenticated encryption and verify before decryption

Use an AEAD scheme (for example, AES-GCM) so that decryption either succeeds and yields correct plaintext or fails entirely. Verify authentication tags before using plaintext, and avoid treating padding errors separately.

// Axum handler with authenticated decryption and uniform error handling
async fn get_profile_safe(
    Path(user_id): Path,
    db: Extension,
) -> Result, (StatusCode, String)> {
    let row = db.query_one("SELECT encrypted_data FROM profiles WHERE id = $1", &[&user_id])
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let ciphertext: Vec<u8> = row.get(0);
    match decrypt_aes_gcm_authenticated(&ciphertext, KEY) {
        Ok(plaintext) => {
            let profile: Profile = serde_json::from_slice(&plaintext)
                .map_err(|_| (StatusCode::BAD_REQUEST, "invalid data".to_string()))?;
            Ok(Json(profile))
        }
        Err(_) => {
            // Always return the same status and no detail
            Err((StatusCode::UNAUTHORIZED, "invalid token".to_string()))
        }
    }
}

2. Constant-time error responses and logging

Ensure that the timing of responses does not reveal whether a record exists or whether padding/authentication failed. Avoid branching on sensitive conditions that affect response time, and log internally with structured queries to Cockroachdb without exposing details to the client.

// Axum middleware or handler with constant-time response behavior
async fn get_profile_timing_safe(
    Path(user_id): Path,
    db: Extension,
) -> Result, (StatusCode, String)> {
    // Fetch record; treat missing and decryption errors identically
    let maybe_row = db.query_optional("SELECT encrypted_data FROM profiles WHERE id = $1", &[&user_id])
        .await
        .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let ciphertext = match maybe_row {
        Some(row) => row.get(0),
        None => {
            // Use a dummy ciphertext to keep timing similar; still run decrypt to consume time
            let dummy = vec![0u8; 128];
            let _ = decrypt_aes_gcm_authenticated(&dummy, KEY);
            return Err((StatusCode::UNAUTHORIZED, "invalid token".to_string()));
        }
    };
    // Attempt decryption; any failure yields same response
    match decrypt_aes_gcm_authenticated(&ciphertext, KEY) {
        Ok(plaintext) => {
            let profile: Profile = serde_json::from_slice(&plaintext)
                .map_err(|_| (StatusCode::UNAUTHORIZED, "invalid token".to_string()))?;
            Ok(Json(profile))
        }
        Err(_) => Err((StatusCode::UNAUTHORIZED, "invalid token".to_string())),
    }
}

3. Store and compare integrity metadata in Cockroachdb

Store a hash or authentication tag alongside the ciphertext. Before decryption, compare the expected tag in constant time. This prevents adaptive chosen-ciphertext attacks that exploit padding behavior.

// Example schema: profiles(encrypted_data BYTEA, auth_tag BYTEA)
async fn get_profile_with_tag(
    Path(user_id): Path,
    db: Extension,
) -> Result, (StatusCode, String)> {
    let row = db.query_one(
        "SELECT encrypted_data, auth_tag FROM profiles WHERE id = $1",
        &[&user_id],
    )
    .await
    .map_err(|e| (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;
    let ciphertext: Vec<u8> = row.get(0);
    let expected_tag: Vec<u8> = row.get(1);
    // Use a constant-time comparison for the tag
    if subtle::ConstantTimeEq::ct_eq(&compute_tag(&ciphertext), &expected_tag).into() {
        match decrypt_aes_gcm_authenticated(&ciphertext, KEY) {
            Ok(plaintext) => {
                let profile: Profile = serde_json::from_slice(&plaintext)
                    .map_err(|_| (StatusCode::BAD_REQUEST, "invalid data".to_string()))?;
                Ok(Json(profile))
            }
            Err(_) => Err((StatusCode::UNAUTHORIZED, "invalid token".to_string())),
        }
    } else {
        Err((StatusCode::UNAUTHORIZED, "invalid token".to_string()))
    }
}

By combining authenticated encryption, constant-time error handling, and integrity checks stored in Cockroachdb, you reduce the risk that an Axum endpoint behaves as a padding oracle. middleBrick can validate these patterns as part of its checks, mapping findings to standards such as OWASP API Top 10 and providing remediation steps rather than attempting to patch or block traffic directly.