Xml External Entities in Actix with Dynamodb

An XML External Entity (XXE) issue arises in Actix when an application parses untrusted XML data and the XML document declares external entities that reference local resources or remote endpoints. In a typical Actix web service, XML payloads may be accepted for configuration, file uploads, or API integrations. If the XML parser is configured to process external entities and the application later uses data from those entities in downstream requests, an attacker can force reads from the filesystem or trigger unintended network calls.

When the parsed data is used to build requests to Amazon DynamoDB, the risk compounds. For example, an attacker-controlled external entity can inject metadata or specially crafted attribute values into a request that interacts with DynamoDB. If the application constructs a DynamoDB API call by concatenating or interpolating values from the XML into condition expressions, key names, or request parameters, the injected content may bypass validation, leak sensitive configuration, or trigger excessive operations. Because the Actix runtime does not inherently sanitize XML-derived inputs before they reach DynamoDB logic, the combination exposes data exposure and injection paths that are not evident in unit tests.

Consider an endpoint that accepts an XML document describing a record to store in a DynamoDB table. If the XML includes an external entity like "SYSTEM file:///etc/passwd", and the application embeds the entity’s expanded content into an item’s attribute before calling DynamoDB, the resulting write may store sensitive system data or overwrite critical fields. Similarly, a remote entity (dtd) can cause the parser to make HTTP requests to an attacker-controlled server, leading to server-side request forgery that maps to SSRF against DynamoDB’s endpoint if credentials are obtained via instance metadata. The interaction between Actix’s XML parsing and DynamoDB’s key-value model amplifies impact by turning a parsing weakness into a data exfiltration or unauthorized write vector.

Notably, this is not about breaking DynamoDB itself; DynamoDB is a managed service that does not parse XML. The vulnerability lives in the Actix application code that interprets XML and constructs DynamoDB requests. Inadequate parser settings, such as enabling external DTD loading or failing to disable DOCTYPE declarations, allow the exploit chain to proceed. Without strict schema validation and input sanitization before the data reaches DynamoDB calls, the attack surface remains open even if network-level protections exist.

To mitigate XXE in Actix when working with DynamoDB, ensure XML parsing is configured securely and that inputs destined for DynamoDB are validated and escaped. Use a dedicated XML parser with external entity processing disabled, and apply strict schema checks before constructing any request to DynamoDB.

1. Disable external entities in XML parsing

Configure your XML parser to disallow DOCTYPE declarations and external entities. For example, using the roxmltree crate (a safe, read-only parser) avoids the problem entirely because it does not support external entities:

use roxmltree::Document;

fn parse_safely(data: &str) -> Result<Document, roxmltree::Error> {
    // roxmltree does not process external entities
    Document::parse(data)
}

// Example usage in an Actix handler:
async fn store_item(body: String) -> Result<impl Responder, Error> {
    let doc = parse_safely(&body)?;
    // Extract fields safely and build DynamoDB items
    Ok(HttpResponse::Ok().finish())
}

2. Validate and parameterize DynamoDB requests

Do not concatenate XML-derived values into DynamoDB keys or expressions. Use the official AWS SDK for Rust to construct requests with strongly-typed structures. This prevents injected content from altering the semantics of the DynamoDB operation:

use aws_sdk_dynamodb::types::AttributeValue;
use aws_sdk_dynamodb::Client;

async fn put_item_safe(client: &Client, table: &str, user_id: String, payload: String) -> Result<(), aws_sdk_dynamodb::Error> {
    client
        .put_item()
        .table_name(table)
        .item(
            "user_id",
            AttributeValue::S(user_id),
        )
        .item(
            "data",
            AttributeValue::S(payload),
        )
        .send()
        .await?;
    Ok(())
}

In this pattern, user_id and payload must be validated and sanitized before being passed to the SDK. Reject any input containing XML markup or unexpected control characters that could indicate injection attempts.

3. Schema-based filtering and runtime checks

Define a JSON Schema or strict type for expected fields and validate incoming data before it reaches DynamoDB. For Actix, combine a validator (e.g., jsonschema or manual checks) with the SDK to ensure only clean data is used in requests:

fn validate_record(input: &str) -> Result<(String, String), &'static str> {
    // Very simplified validation: ensure no XML-like sequences
    if input.contains("<") || input.contains(">") || input.contains("&") {
        return Err("invalid characters");
    }
    // Deserialize into known structure and extract fields
    let parsed: serde_json::Value = serde_json::from_str(input).map_err(|_| "parse error")?;
    let user_id = parsed["user_id"].as_str().ok_or("missing user_id")?.to_string();
    let data = parsed["data"].as_str().ok_or("missing data")?.to_string();
    Ok((user_id, data))
}

This ensures that even if an attacker manages to smuggle XML-like content, it is rejected before any DynamoDB interaction. Combine this with the safe parser and SDK usage to create defense-in-depth.