Xml External Entities in Echo Go with Dynamodb

An XML External Entity (XXE) vulnerability occurs when an application processes XML input that references external entities without proper restrictions. In Go services built with the Echo framework, if XML payloads are parsed using an insecure configuration and the application interacts with AWS DynamoDB, the combination can expose sensitive data or enable server-side request forgery (SSRF) against internal AWS metadata services.

Echo does not provide built-in XML parsing; developers typically use standard library packages such as encoding/xml or third-party libraries. When these parsers are configured to resolve external entities (by not disabling DOCTYPE declarations), an attacker can supply a malicious XML body that defines an external entity pointing to an internal endpoint, such as the DynamoDB API service endpoint or the EC2 instance metadata service (http://169.254.169.254/latest/meta-data/).

Consider an Echo handler that accepts an XML payload to query a DynamoDB table. If the XML parser does not disable external entities, an attacker can send a request like the following crafted XML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">]>
<request>
  <table>Users</table>
  <query>&xxe; </query>
</request>

When the Echo application unmarshals this XML, the external entity &xxe; triggers an HTTP request to the instance metadata service. If the application’s IAM role has permissions for DynamoDB, the metadata response may include temporary credentials that can be exfiltrated. Additionally, an attacker can define an external entity that references a DynamoDB endpoint with a malicious payload, attempting to probe or interact with the service based on IAM permissions.

Another scenario involves SOAP-based APIs or XML-driven configuration that references external DTDs hosted remotely. If the application fetches and parses these DTDs, it can lead to remote code execution patterns or data exfiltration via crafted responses. The DynamoDB interaction becomes a vector when parsed XML includes entity expansions that repeatedly query or write items, leading to potential abuse or information disclosure.

Because Echo is a minimal framework, the responsibility of securing XML parsing lies entirely with the developer. Failing to disable external entity processing in the XML parser allows the attack surface to extend to any backend service the application can reach—including DynamoDB and AWS metadata endpoints. This is especially dangerous in environments where the application runs with elevated IAM permissions, as is common when integrating with DynamoDB.

To remediate XXE in an Echo application that interacts with DynamoDB, you must ensure XML parsing is configured to reject external entities and external DTDs. Below are concrete, secure examples using Go’s standard library and the AWS SDK for Go v2.

Secure XML parsing with disabled external entities

Use xml.NewDecoder and set the appropriate flags to prevent entity expansion. For Go 1.18+, you can use xml.Decoder with a custom Entity resolver that returns an error.

import (
    "encoding/xml"
    "net/http"
    "github.com/labstack/echo/v4"
)

func secureHandler(c echo.Context) error {
    dec := xml.NewDecoder(c.Request().Body)
    // Disable external entity resolution
    dec.Entity = xml.HTMLEntity
    // Alternatively, use a custom resolver that returns an error for external entities
    // dec.Entity = customEntityResolver{}

    var req struct {
        Table string `xml:"table"`
        Query string `xml:"query"`
    }
    if err := dec.Decode(&req); err != nil {
        return c.JSON(http.StatusBadRequest, map[string]string{"error": err.Error()})
    }

    // Proceed with DynamoDB interaction using req.Table and req.Query safely
    return c.JSON(http.StatusOK, map[string]string{"received_table": req.Table})
}

DynamoDB interaction with AWS SDK for Go v2

After safely parsing the input, use the AWS SDK for Go v2 to interact with DynamoDB. Ensure that the SDK is configured with proper credentials and that the request payloads are validated against expected structures.

import (
    "context"
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

func queryTable(tableName string, key string) error {
    cfg, err := config.LoadDefaultConfig(context.TODO())
    if err != nil {
        return err
    }
    client := dynamodb.NewFromConfig(cfg)

    input := &dynamodb.GetItemInput{
        TableName: aws.String(tableName),
        Key: map[string]types.AttributeValue{
            "ID": &types.AttributeValueMemberS{Value: key},
        },
    }

    _, err = client.GetItem(context.TODO(), input)
    return err
}

Additional hardening

• Validate and sanitize all inputs before using them in DynamoDB queries or condition expressions.
• Apply the principle of least privilege to the IAM role associated with the Echo application, granting only necessary DynamoDB permissions.
• Use environment variables or secure secret stores for AWS credentials instead of embedding them in code.
• Consider using middleware in Echo to reject requests with unexpected Content-Type or malformed XML before parsing.

By combining secure XML parsing with cautious DynamoDB usage, you eliminate the XXE attack surface while maintaining safe interactions with AWS services.