Padding Oracle in Axum with Dynamodb

A padding oracle attack occurs when an application exposes different error messages or timing behaviors depending on whether ciphertext padding is valid. In an Axum service that uses DynamoDB as a persistence layer, this often maps to how the API processes encrypted data before storing it in DynamoDB and how it reports validation problems back to the client.

Consider an endpoint that accepts an encrypted JSON blob, decrypts it, validates business rules, and then writes to DynamoDB. If the decryption step fails and the application returns distinct errors for invalid padding versus other decryption failures, an attacker can iteratively modify the ciphertext and observe differences in HTTP status codes or response times. Over many requests, the attacker can recover the plaintext without ever knowing the encryption key.

When DynamoDB is used as the backend, the presence or absence of an item can also become an oracle signal. For example, an endpoint might decrypt a ciphertext to obtain an identifier, then perform a GetItem or Query against DynamoDB. If a valid ciphertext leads to a matching item while an invalid ciphertext leads to a "not found" response, the difference becomes another side channel. Even when responses are carefully flattened to a generic error, timing differences in decryption and DynamoDB read operations can leak information under network conditions that allow precise measurement.

In Axum, handlers are typically asynchronous and composed. If decryption is performed eagerly within the handler and any padding-related exception is allowed to propagate with a detailed message or a non-2xx status, the attack surface is present. Using DynamoDB does not introduce padding oracle by itself, but the way errors are structured around DynamoDB operations can amplify or reduce the signal available to an attacker.

To illustrate, an unsafe pattern in Axum might look like a handler that decrypts a path or body parameter and then uses the result as a key for DynamoDB access. If decryption throws a padding-related error and the handler returns a 400 with a message containing the word "padding," an attacker gains useful feedback. Even when status codes are uniform, subtle timing differences between a successful decryption+fetch and a failed decryption+DynamoDB GetItem can be measurable, especially when the attacker controls network proximity or uses adaptive techniques.

Mitigations center on ensuring that all decryption outcomes map to the same HTTP status and response shape, and that timing for failed decryption does not materially differ from the path that proceeds to DynamoDB. Constant-time comparison and decryption routines, along with avoiding branching on secret-dependent data, reduce the oracle signal. In Axum, this means designing extractors and handlers so that errors are caught and transformed into a uniform response before any DynamoDB interaction, and ensuring that DynamoDB read patterns do not vary based on secret-dependent values.

Remediation in Axum with DynamoDB focuses on removing observable differences in behavior and timing between valid and invalid ciphertexts. Below is a concrete, secure handler pattern that avoids leaking padding errors and standardizes DynamoDB interactions.

use axum::{routing::post, Router, Json};
use aws_sdk_dynamodb::Client as DynamoDbClient;
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize, Serialize)]
struct EncryptedRequest {
    ciphertext: Vec<u8>,
}

#[derive(Debug, Deserialize, Serialize)]
struct ApiResponse {
    status: &'static str,
    // other non-sensitive fields
}

async fn handle_decrypt_and_dynamo(
    Json(payload): Json<EncryptedRequest>,
    dynamodb: <axum::extract::State<AppState> as Into<AppState>::Into>::dynamodb,
) -> Result<Json<ApiResponse>, (axum::http::StatusCode, Json<ApiResponse>)> {
    // 1) Perform decryption in a way that does not branch on secret-dependent data.
    // Use a constant-time decryption library or ensure errors are mapped uniformly.
    let plaintext = match decrypt_constant_time(&payload.ciphertext) {
        Ok(data) => data,
        Err(_) => {
            // Always return the same status and shape regardless of failure cause.
            return Err((axum::http::StatusCode::BAD_REQUEST, Json(ApiResponse { status: "error" })));
        }
    };

    // 2) Use a deterministic access pattern against DynamoDB to avoid timing leaks.
    // For example, always perform a GetItem with a placeholder key when the item is not needed
    // for the happy path, or ensure queries do not vary based on secret-derived values.
    let key = aws_sdk_dynamodb::types::AttributeValue::S("placeholder".to_string());
    let _ = dynamodb
        .get_item()
        .table_name("example-table")
        .set_key(Some({
            let mut m = std::collections::HashMap::new();
            m.insert("id".to_string(), key);
            m
        }))
        .send()
        .await
        .map_err(|_| (axum::http::StatusCode::BAD_REQUEST, Json(ApiResponse { status: "error" })))?;

    // 3) Return a uniform response shape for both success and failure after DynamoDB interaction.
    Ok(Json(ApiResponse { status: "ok" }))
}

// Placeholder: replace with a vetted cryptographic library that uses constant-time operations.
fn decrypt_constant_time(ciphertext: &[u8]) -> Result<Vec<u8>, crypto_error::Error> {
    // In practice, use an AEAD mode or properly handle padding in a constant-time library.
    // This function must not return different errors for padding versus other failures.
    unimplemented!()
}

pub fn app() -> Router {
    let dynamodb = aws_sdk_dynamodb::Client::new(&aws_config::load_from_env().await);
    let state = AppState { dynamodb };
    Router::new()
        .route("/secure", post(move |req| handle_decrypt_and_dynamo(req, &state)))
        .with_state(state)
}

struct AppState {
    dynamodb: DynamoDbClient,
}

Key points in this example:

• Decrypt errors are caught and mapped to a uniform HTTP status and JSON response before any DynamoDB interaction.
• The DynamoDB operation uses a fixed key pattern to avoid branching on secret-derived identifiers that could affect timing or access patterns.
• The response shape is consistent, preventing an attacker from inferring padding validity through status codes or response body differences.

For production-grade security, pair this handler with application-level encryption using authenticated encryption with associated data (AEAD) such as AES-GCM, which avoids explicit padding altogether, and ensure all cryptographic operations rely on well-audited libraries rather than custom implementations.