Xpath Injection in Actix with Dynamodb

XPath Injection becomes relevant in Actix applications when user-controlled input is used to construct XPath expressions that query XML or structured data, and when the backend persists or processes that data in Amazon DynamoDB. Although DynamoDB is a NoSQL database and does not natively execute XPath, an Actix service might accept XPath-like selectors from clients for data filtering, transform them into DynamoDB queries (e.g., using condition expressions or filtering on JSON-encoded blobs), and then pass values into XPath evaluation in downstream processing. If input is concatenated directly into XPath strings without sanitization or parameterization, an attacker can inject malicious predicates such as ' or 1=1 or ' to alter logic or extract unintended data.

In a typical Actix scenario, an endpoint might accept a filter expressed as an XPath string, apply it to an XML document stored as an item attribute in DynamoDB, and return results. Consider an Actix handler that retrieves an item by an identifier and then evaluates an XPath expression provided by the caller:

use actix_web::{web, HttpResponse, Responder};
use aws_sdk_dynamodb::Client;

async fn get_filtered_item(
    client: web::Data<Client>,
    path: web::Path<(String, String)>, // (table_name, item_id)
) -> impl Responder {
    let (table_name, item_id) = path.into_inner();
    let xpath_input = web::block(move || {
        // Retrieve item from DynamoDB (attribute 'data' contains XML/structured text)
        let fut = client.get_item()
            .table_name(&table_name)
            .key("id", aws_sdk_dynamodb::types::AttributeValue::S(item_id))
            .send();
        // In a real app, you'd block_on or use actix_web::web::block correctly
        fut
    }).await.unwrap();

    // UNSAFE: directly interpolating user-provided xpath_expr into evaluation
    let xpath_expr = "//item[username='" + &xpath_input + "']";
    let result = evaluate_xpath(&xpath_expr, &item_data);
    HttpResponse::Ok().body(result)
}

If xpath_input is supplied by an attacker as ' or '1'='1, the resulting XPath becomes //item[username='' or '1'='1'], potentially bypassing intended filters and returning multiple or all items. Because DynamoDB stores the raw data, the malicious XPath can extract more data than intended when the XML is processed, leading to Data Exposure. This pattern is common in services that use XPath for in-memory transformation of DynamoDB-retrieved documents and fails to treat user input as untrusted.

The risk is compounded when combined with other checks performed by middleBrick: unauthenticated endpoints may expose these handlers directly, and improper input validation allows injection payloads to reach XPath evaluation. middleBrick’s checks for Input Validation, Data Exposure, and Unsafe Consumption would flag this pattern, while the LLM/AI Security probes would test for prompt injection variants if any AI components are involved in processing or explaining the data.

To prevent XPath Injection in Actix when working with DynamoDB, avoid constructing XPath expressions by string concatenation with user input. Instead, use parameterized approaches or limit XPath usage entirely. When data from DynamoDB must be filtered, apply filtering at the DynamoDB level using condition expressions or client-side filtering on already-retrieved items using safe methods.

1. Use DynamoDB condition expressions instead of XPath: If you only need to retrieve items matching specific attribute values, express filters directly in DynamoDB queries. This removes the need for XPath-based filtering on XML blobs.

async fn get_item_by_id(
    client: web::Data<Client>,
    table_name: String,
    item_id: String,
) -> Option<aws_sdk_dynamodb::types::Item> {
    let resp = client.get_item()
        .table_name(table_name)
        .key("id", aws_sdk_dynamodb::types::AttributeValue::S(item_id))
        .send()
        .await
        .ok()?
        .item;
    resp
}

2. Sanitize and validate XPath input if XPath processing is unavoidable: If your application must accept XPath-like expressions, use a dedicated parser or whitelist allowed axes and predicates. Never directly concatenate user input.

use regex::Regex;

fn is_safe_xpath(input: &str) -> bool {
    // Allow only simple value comparisons on known safe fields
    let re = Regex::new(r"^//item\[username='[a-zA-Z0-9_]+'\]$").unwrap();
    re.is_match(input)
}

// In handler:
if is_safe_xpath(&xpath_input) {
    let xpath_expr = format!("//item[username='{}']", xpath_input);
    let result = evaluate_xpath(&xpath_expr, &item_data);
    HttpResponse::Ok().body(result)
} else {
    HttpResponse::BadRequest().body("Invalid filter")
}

3. Encode or escape values used in XPath: If you must include dynamic values, use an XPath library that supports parameterized evaluation or properly escape quotes and special characters.

use xpath::evaluate;

fn safe_evaluate(item_data: &str, username: &str) -> Vec<String> {
    // Using a library that supports parameterized expressions avoids injection
    let result = evaluate(
        "//item[username=$username]",
        &[("username", &username)],
        item_data,
    );
    result
}

In all cases, ensure the endpoint is authenticated where required and validate input against a strict schema. middleBrick’s scans can help identify missing validation and risky data handling patterns in your Actix service, while the GitHub Action can enforce checks before deployment.