Xml External Entities in Aspnet with Dynamodb

XML External Entity (XXE) injection occurs when an application processes XML input that references external entities in a way that the XML parser resolves them. In ASP.NET applications that accept XML payloads—such as SOAP services or configuration-driven deserialization—enabling external entity resolution can expose file contents, internal service endpoints, or trigger SSRF. When such an application interacts with Amazon DynamoDB, the risk pattern compounds: an attacker can leverage XXE to probe internal metadata services, reach DynamoDB endpoints that are not publicly routable, or extract IAM credentials from instance metadata, then misuse those credentials to access or manipulate DynamoDB tables.

DynamoDB itself does not parse XML, so the injection happens at the application layer before data is serialized into DynamoDB operations. For example, an ASP.NET endpoint that accepts an XML document to build a PutItem request may deserialize user-controlled XML into objects that map to DynamoDB attribute values. If the XML parser resolves external entities, an attacker-supplied DOCTYPE can read local files (e.g., appsettings.json containing AWS access keys) or force DNS requests to internal endpoints, effectively turning the application into a pivot point against AWS infrastructure.

A concrete scenario: an ASP.NET Core Web API accepts XML to create a record in a DynamoDB-backed store. The XML deserializer is configured to resolve external entities (e.g., via XmlSerializer or DataContractSerializer with permissive settings). An attacker sends a crafted XML payload with a malicious external entity referencing file:///etc/passwd or http://169.254.169.254/latest/meta-data/iam/security-credentials/. If the application uses the retrieved credentials to sign DynamoDB requests, the attacker can assume those permissions and perform unauthorized GetItem, PutItem, or Scan operations. This chain—XXE in ASP.NET leading to credential exposure leading to DynamoDB abuse—is especially dangerous when the application runs on EC2 with an overprivileged instance profile.

Because middleBrick scans the unauthenticated attack surface and runs checks in parallel for issues such as Input Validation and Data Exposure, it can surface risky XML handling behaviors and SSRF-like patterns that may facilitate access to DynamoDB metadata. Findings include concrete remediation steps to ensure XML parsers are configured to ignore external entities and that DynamoDB clients use least-privilege permissions and avoid processing untrusted XML.

Remediation focuses on two layers: secure XML parsing in ASP.NET and least-privilege, safe usage of DynamoDB. For XML, disable external entity resolution entirely. For DynamoDB, avoid processing XML-derived input for table operations, and apply strict validation and least-privilege IAM policies.

Secure XML parsing in ASP.NET

Configure the XML reader settings to prohibit DOCTYPE declarations and external references. Below are examples for XmlDocument and XmlReader.

// Example 1: Secure XmlDocument usage in ASP.NET
var doc = new XmlDocument { PreserveWhitespace = true };
var settings = new XmlReaderSettings {
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null,
    ValidationType = ValidationType.None
};
using (var reader = XmlReader.Create(new StringReader(userInput), settings)) {
    doc.Load(reader);
}
// Use doc safely; no external entities resolved

// Example 2: Secure XmlReader for streams in ASP.NET Core
public static XmlDocument LoadWithoutExternalEntities(string xml)
{
    var doc = new XmlDocument();
    var settings = new XmlReaderSettings {
        DtdProcessing = DtdProcessing.Prohibit,
        XmlResolver = null
    };
    using (var reader = XmlReader.Create(new StringReader(xml), settings)) {
        doc.Load(reader);
    }
    return doc;
}

DynamoDB client hardening in ASP.NET

Use the AWS SDK for .NET with explicit credentials and avoid dynamic attribute maps built from unchecked XML. Define a strict document model and validate inputs before constructing requests.

// Example: Safe DynamoDB PutItem with explicit model and validated input
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.DataModel;
using Amazon.DynamoDBv2.Model;

public class Product {
    [DynamoDBHashKey]
    public string Id { get; set; }
    public string Name { get; set; }
    public int Quantity { get; set; }
}

public async Task AddProductAsync(Product product, IAmazonDynamoDB client)
{
    if (product == null) throw new ArgumentNullException(nameof(product));
    if (string.IsNullOrWhiteSpace(product.Id)) throw new ArgumentException("Id required");
    // Validate Name and Quantity as needed; do not accept raw XML-derived objects

    var config = new DynamoDBOperationConfig {
        OverrideTableName = "Products"
    };
    using var db = new DynamoDBContext(client);
    await db.SaveAsync(product, config);
}

// Example: Low-level PutItem with strict attribute construction
public async Task PutItemSafeAsync(string tableName, Dictionary<string, AttributeValue> item,
    IAmazonDynamoDB client, CancellationToken ct = default)
{
    if (item == null) throw new ArgumentNullException(nameof(item));
    // Ensure keys and values are explicitly typed; do not merge unchecked XML attributes
    var request = new PutItemRequest {
        TableName = tableName,
        Item = item
    };
    await client.PutItemAsync(request, ct);
}

IAM and infrastructure guidance

Assign the minimal IAM permissions required for the DynamoDB actions your endpoints perform. Avoid instance profiles with broad PowerUser or AdministratorAccess policies. If your ASP.NET app runs on EC2 or ECS, scope the role to specific table ARNs and deny access to metadata endpoints that could enable privilege escalation.

Finally, integrate scans from middleBrick into your CI/CD pipeline using the GitHub Action to fail builds if risk scores degrade. This helps catch insecure XML handling or overly permissive DynamoDB permissions before they reach production.