Ssrf in Axum with Dynamodb

Server-Side Request Forgery (SSRF) in an Axum application that interacts with DynamoDB can occur when user-supplied data influences both HTTP requests made by the service and the parameters used to access DynamoDB. An attacker may provide a malicious URL or metadata service endpoint that causes the backend to perform unintended network requests, and poorly constructed DynamoDB operations may reflect or log those inputs in ways that amplify exposure.

Consider an Axum handler that accepts a table_name and an item_id to fetch a DynamoDB item. If the handler builds the request using unchecked user input, an attacker can supply a DynamoDB table name that references an internal AWS metadata service address (e.g., 169.254.169.254) if the SDK or runtime allows such values. While DynamoDB itself does not resolve internal endpoints, the surrounding infrastructure might, especially if the application also performs HTTP calls based on the same input. For example, the app might retrieve an item from DynamoDB and then use a field from that item (such as a URL or S3 path) to make an outbound HTTP request. If that field is controlled by an attacker and the request is not validated, SSRF occurs.

Real-world patterns include:

• An attacker provides a DynamoDB KeyConditionExpression that includes a fabricated URL-like string, which later gets used in an HTTP client call embedded in application logic.
• Misconfigured IAM permissions combined with user-controlled request parameters allow probing of the metadata service from within the host, revealing instance credentials or sensitive configuration.
• Logging or error messages that include raw user input can expose internal network layout when those messages are exfiltrated through SSRF channels.

Because middleBrick tests unauthenticated attack surfaces, it can detect SSRF risks that arise from insufficient input validation and improper handling of outbound requests, even when DynamoDB interactions appear isolated. The scanner’s checks for SSRF, Input Validation, and Unsafe Consumption are particularly relevant for this combination, ensuring that user-controlled data does not lead to unauthorized network interactions.

Remediation focuses on strict validation, whitelisting, and separation of concerns so that DynamoDB operations cannot be tricked into making unintended network calls. In Axum, this means validating all inputs before constructing requests and avoiding the use of user data in ways that affect routing, endpoints, or SDK parameters.

Use strong type definitions and validation libraries such as validator or serde_with to ensure inputs conform to expected patterns. For DynamoDB operations, prefer static table names or an allowlist, and never directly interpolate user input into key expressions.

use aws_sdk_dynamodb::types::AttributeValue;
use aws_sdk_dynamodb::Client;
use axum::extract::Query;
use serde::Deserialize;

#[derive(Deserialize)]
pub struct ItemQuery {
    pub user_id: String,
    // Only allow alphanumeric user IDs to prevent injection
    #[serde(deserialize_with = "validate_user_id")]
    pub item_id: String,
}

fn validate_user_id<'de, D>(deserializer: D) -> Result<String, D::Error>
where
    D: serde::Deserializer<'de>,
{
    let s = String::deserialize(deserializer)?;
    if s.chars().all(|c| c.is_ascii_alphanumeric()) {
        Ok(s)
    } else {
        Err(serde::de::Error::custom("invalid item_id"))
    }
}

pub async fn get_item(
    Query(params): Query<ItemQuery>,
    client: &Client,
) -> Result<impl IntoResponse, (axum::http::StatusCode, String)> {
    // Use a static table name; never derive it from user input
    let table_name = "UserProfile";

    let key = aws_sdk_dynamodb::types::AttributeValue::S(params.item_id);
    let output = client
        .get_item()
        .table_name(table_name)
        .key("user_id", key)
        .send()
        .await
        .map_err(|e| (axum::http::StatusCode::INTERNAL_SERVER_ERROR, e.to_string()))?;

    if let Some(item) = output.item() {
        Ok(axum::Json(item.clone()))
    } else {
        Err((axum::http::StatusCode::NOT_FOUND, "Item not found".into()))
    }
}

Additional measures include:

• Never use fields from DynamoDB items to construct URLs or HTTP requests without strict validation and allowlisting.
• Enforce least-privilege IAM roles so that the application cannot access sensitive AWS metadata endpoints.
• Enable DynamoDB Streams and audit logs to detect anomalous access patterns that might indicate exploitation attempts.

middleBrick’s scans for Input Validation, BOLA/IDOR, and SSRF help identify whether your Axum endpoints and DynamoDB integrations expose unsafe behaviors. The CLI (middlebrick scan <url>) and GitHub Action can automate detection of these classes of issues during development and deployment.