Xpath Injection in Aspnet with Dynamodb

XPath Injection becomes relevant in an Aspnet application when user-controlled input is used to construct XPath expressions that query data, and the backend uses Amazon DynamoDB as the persistence store. Although DynamoDB itself does not speak XPath, an Aspnet service can build XPath strings in C# code to filter or transform data before or after retrieving items from DynamoDB, for example by querying a secondary data structure or generating XML/JSON for downstream processing. If these XPath expressions concatenate untrusted input without proper escaping or validation, an attacker can alter the logic, bypass filters, or extract unintended data.

Consider an Aspnet controller that receives a user-supplied userId and builds an XPath selection to locate a user profile node in an XML document before mapping fields to a DynamoDB item:

string userId = Request.Query["userId"];
string xpath = $"/users/user[id='{userId}']";
var node = xmlDoc.SelectSingleNode(xpath);

An attacker can supply userId as ' or 1=1 or ', turning the expression into /users/user[id='' or 1=1 or ''], which may return multiple nodes or bypass intended filters. Even if the final item is fetched from DynamoDB using a key partition, the malicious XPath can disclose other users’ data or change control flow in the Aspnet layer. The scan checks for concatenation of user input into XPath-like constructs and flags the absence of parameterized XPath selection or strict input validation, which helps identify this class of issue even when DynamoDB is the datastore.

Additionally, XPath Injection can manifest when Aspnet dynamically builds filter expressions that are later translated to DynamoDB queries, such as constructing a string that mimics attribute selectors. Because DynamoDB access patterns rely on key schema design, an attacker may attempt to manipulate logical conditions to cause broader scans or unintended item retrieval if validation is weak. The 12 security checks include an Input Validation assessment that examines how user input is handled before being used in query construction, providing findings with severity and remediation guidance to prevent injection.

To prevent XPath Injection in an Aspnet application that interacts with DynamoDB, avoid building XPath expressions via string concatenation. Instead, use parameterized XPath methods or switch to safer data access patterns that do not rely on dynamic XPath construction. When working with XML data before mapping to DynamoDB items, prefer SelectNodes with XPathNavigator and compile queries, or use LINQ to XML to filter safely.

Example of a vulnerable approach:

string userId = Request.Query["userId"];
string xpath = "/users/user[id='" + userId + "']";
XmlNode node = xmlDoc.SelectSingleNode(xpath);

Remediation using parameterized XPath with XPathNavigator:

string userId = Request.Query["userId"];
XPathNavigator nav = xmlDoc.CreateNavigator();
XPathExpression expr = nav.Compile("/users/user[id=userId]");
expr.SetContext(new XPathVariable("userId", userId));
XPathNodeIterator iter = nav.Select(expr);

Alternatively, use LINQ to XML to avoid XPath entirely:

string userId = Request.Query["userId"];
var userElement = xmlDoc.Descendants("user")
                        .FirstOrDefault(u => (string)u.Element("id") == userId);

When retrieving the corresponding item from DynamoDB, always use the AWS SDK with parameterized key lookups:

var request = new GetItemRequest
{
    TableName = "Users",
    Key = new Dictionary<string, AttributeValue>
    {
        { "UserId", new AttributeValue { S = userId } }
    }
};
var response = await client.GetItemAsync(request);

Validate and sanitize userId before use—apply allowlists for expected formats and length checks. The middleBrick CLI can be run with middlebrick scan <url> to detect missing input validation and XPath concatenation issues; the GitHub Action can enforce thresholds in CI/CD, and the MCP Server enables scanning from AI coding assistants to catch such patterns early in development.