Ssrf in Actix with Dynamodb

Server-Side Request Forgery (SSRF) in an Actix web service that interacts with Amazon DynamoDB can occur when user-supplied input is used to construct HTTP requests or to form DynamoDB endpoint configurations. In a black-box scan, middleBrick tests unauthenticated attack surfaces and checks whether the API permits an attacker to direct internal network traffic from the application. Because DynamoDB endpoints are typically internal or restricted to specific VPCs, SSRF can expose metadata services or internal resources that should never be reachable from user-controlled paths or parameters.

An Actix API that deserializes untrusted input into a URL or host and then uses that to call DynamoDB—for example, to proxy requests or to dynamically select a region/endpoint—creates a chain where SSRF becomes viable. middleBrick’s checks for SSRF include verifying whether inputs can influence outbound connections and whether responses disclose internal metadata or private IPs. If an endpoint accepts a table name or key schema derived from user input and uses it to build a request that resolves to an internal address, the scan will flag this as a high-severity finding under SSRF and may surface related risks such as excessive agency when functions are misused to reach unintended services.

DynamoDB-specific exposure in Actix often involves SDK configuration where endpoints or credentials are derived from request data. For instance, if an Actix handler parses a query parameter to set the AWS region or the base URI for the DynamoDB client, an attacker can supply an internal IP or a metadata service address (e.g., http://169.254.169.254). Because middleBrick tests unauthenticated attack surfaces, it can probe such endpoints without credentials and observe whether internal resources respond. Finding patterns like open redirects to internal endpoints or information leakage from AWS metadata responses will be surfaced in the report, along with remediation guidance tied to input validation and strict endpoint configuration.

To remediate SSRF in Actix when working with DynamoDB, ensure that all user-controlled input is strictly validated and never used to construct endpoint URLs or region selectors for the AWS SDK. Use allowlists for table names and key patterns, and configure the DynamoDB client with a fixed endpoint and region rather than values derived from requests. The following examples show secure patterns in Rust using the official AWS SDK for Rust integrated with Actix web.

use actix_web::{web, HttpResponse};
use aws_sdk_dynamodb::Client;
use aws_config::BehaviorVersion;
use aws_sdk_dynamodb::types::AttributeValue;

// Secure: endpoint and region are fixed, not derived from user input.
async fn get_item_handler(
    client: web::Data,
    path: web::Path<(String,)>,
) -> HttpResponse {
    let table_name = &path[0];
    // Validate table name against an allowlist or strict pattern.
    if !is_valid_table_name(table_name) {
        return HttpResponse::BadRequest().body("Invalid table name");
    }
    // Use a hardcoded key; never forward raw user keys without strict validation.
    let key = vec![("id", AttributeValue::S("user-123".to_string()))];
    match client.get_item()
        .table_name(table_name)
        .set_key(Some(key.into()))
        .send()
        .await {
        Ok(output) => {
            if let Some(item) = output.item {
                HttpResponse::Ok().json(item)
            } else {
                HttpResponse::NotFound().finish()
            }
        }
        Err(e) => HttpResponse::InternalServerError().body(e.to_string()),
    }
}

fn is_valid_table_name(name: &str) -> bool {
    // Allow only alphanumeric and hyphens; prevent path traversal or injection.
    name.chars().all(|c| c.is_ascii_alphanumeric() || c == '-')
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Configure SDK with a fixed region and default provider chain.
    let config = aws_config::load_defaults(BehaviorVersion::latest()).await;
    let client = Client::new(&config);

    actix_web::HttpServer::new(move || {
        actix_web::App::new()
            .app_data(web::Data::new(client.clone()))
            .route("/items/{table}", actix_web::web::get().to(get_item_handler))
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

In this example, the DynamoDB client is instantiated once with a default configuration that does not allow runtime overrides of the endpoint or region. The handler validates the table name using a strict allowlist approach, preventing attackers from injecting internal addresses or metadata service URLs. middleBrick’s checks will validate that inputs are properly constrained and that no SSRF vectors exist by attempting to probe endpoints with malicious payloads; following these coding practices will reduce the likelihood of such findings.

Additionally, ensure that the application does not log or echo user input in a way that might expose internal identifiers or URLs. Use middleware to reject requests that contain suspicious patterns (e.g., IP-like strings in path parameters) and enforce network-level restrictions so that the service cannot reach internal AWS metadata endpoints. These measures align with the remediation guidance that middleBrick provides, translating scan findings into concrete code and configuration changes.