Xml External Entities in Echo Go with Cockroachdb

XML External Entity (XXE) injection occurs when an application processes XML input that references external entities. In Go, this can manifest when using the standard encoding/xml decoder without disabling external entity resolution. When an Echo Go service accepts XML payloads and forwards or stores data in Cockroachdb, the interaction can expose or amplify XXE risks if the XML is parsed before validation or if log output or error messages reflect parsed entity content.

Consider an Echo Go handler that reads an XML request body and inserts data into Cockroachdb. If the XML parser resolves external entities, an attacker-controlled DOCTYPE can cause the parser to fetch internal resources (file:// URLs), leading to sensitive data exposure in logs or error traces. Even when Cockroachdb is not directly parsing XML, the application’s behavior—such as logging query parameters or ORM debug output—can inadvertently surface entity expansion results. For example, an external entity like &xxe SYSTEM 'file:///etc/hosts' might expand and appear in application logs, giving an attacker visibility into the filesystem. Because Cockroachdb is often accessed via parameterized queries, direct SQL injection is unlikely from XXE, but the surrounding Go code may mishandle untrusted XML before constructing those queries, creating an indirect exposure path.

The Echo framework does not alter Go’s XML parsing semantics; therefore, the responsibility lies in hardening the XML decoder. By default, Go’s xml.NewDecoder does not resolve external entities unless configured with a custom EntityResolver, but older code or third-party libraries might inadvertently enable resolution. In a microservice architecture where Echo Go routes interact with Cockroachdb through drivers like pgx or , any weakness in XML handling can affect data integrity and confidentiality before records reach the database.

An attacker might send an XML payload containing a parameter entity that references a network resource, causing the Go server to perform unintended HTTP requests during parsing. This can lead to Server-Side Request Forgery (SSRF) conditions when the application uses the expanded content to build database queries or connection strings for Cockroachdb. While Cockroachdb itself does not parse XML, the application layer’s unsafe practices—such as using the parsed output directly in SQL strings or debug endpoints—can create conditions where sensitive configuration or internal endpoints are exposed through crafted entities.

To illustrate a vulnerable pattern, an Echo Go route might decode XML without disabling DTD processing, allowing entity expansion that later influences logging or error formatting before data reaches Cockroachdb. The following example shows a minimal vulnerable handler that does not secure the XML decoder:

package main

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

type Payload struct {
    Data string `xml:"data"`
}

func unsafeHandler(c echo.Context) error {
    decoder := xml.NewDecoder(c.Request().Body)
    var p Payload
    if err := decoder.Decode(&p); err != nil {
        return c.String(http.StatusBadRequest, err.Error())
    }
    // Imagine this data is later used in a Cockroachdb query string or log
    return c.String(http.StatusOK, "Received: "+p.Data)
}

func main() {
    e := echo.New()
    e.POST("/ingest", unsafeHandler)
    e.Start(":8080")
}

In this scenario, if an attacker sends an XML body with an external entity, the decoder may resolve it depending on the Go version and any custom resolver settings. The resulting data might include file contents or trigger network calls that indirectly affect how data is stored or logged for Cockroachdb. Securing the decoder by disabling external entities and using strict element validation mitigates the risk and ensures that only intended data reaches the database layer.

Remediation focuses on preventing entity resolution during XML parsing and ensuring that any data destined for Cockroachdb is sanitized and parameterized. The following Echo Go handler demonstrates a secure approach by disabling DTD and external entity processing:

package main

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

type SafePayload struct {
    Data string `xml:"data"`
}

// secureDecoder returns an XML decoder with external entities disabled.
func secureDecoder(r io.Reader) *xml.Decoder {
    decoder := xml.NewDecoder(r)
    decoder.Entity = xml.HTMLEntity
    // Disable DTD processing to prevent external entity expansion.
    decoder.Strict = false
    decoder.AutoClose = xml.HTMLAutoClose
    decoder.ForceHTML = true
    return decoder
}

func safeHandler(c echo.Context) error {
    // Limit body size to prevent resource exhaustion.
    limitReader := io.LimitReader(c.Request().Body, 10240)
    decoder := secureDecoder(limitReader)
    var p SafePayload
    if err := decoder.Decode(&p); err != nil {
        return c.String(http.StatusBadRequest, "invalid payload")
    }
    // Validate and sanitize data before any logging or database use.
    cleanData := strings.TrimSpace(p.Data)
    if cleanData == "" {
        return c.String(http.StatusBadRequest, "missing data")
    }
    // Example parameterized usage with a Cockroachdb driver (e.g., pgx).
    // In practice, use placeholders appropriate for your driver.
    // db.Exec(context.Background(), "INSERT INTO records (data) VALUES ($1)", cleanData)
    return c.String(http.StatusOK, "safe: "+cleanData)
}

func main() {
    e := echo.New()
    e.POST("/ingest", safeHandler)
    e.Start(":8080")
}

Key practices include replacing the default XML decoder with one that does not resolve external entities, limiting request body size, and avoiding direct concatenation of XML content into SQL strings. When interacting with Cockroachdb, always use parameterized queries or prepared statements to isolate data from command syntax, which prevents injection regardless of XML handling. Logging should sanitize or omit raw XML content to avoid accidental exposure of expanded entities.

For applications that must process complex XML schemas, consider using a strict validation step against an XSD or RelaxNG schema before any data reaches the database layer. This ensures that only expected elements and attributes are accepted, reducing the attack surface introduced by external entity references. Because middleBrick scans unauthenticated attack surfaces, ensuring that XML parsing is hardened helps maintain a low risk score across authentication, data exposure, and input validation checks.

When integrating with CI/CD, tools like the middleBrick CLI can be used to validate endpoint behavior without credentials. For example, running middlebrick scan <url> against an Echo Go service helps confirm that XML endpoints do not expose entity resolution or leak sensitive data. Teams using the middleBrick GitHub Action can fail builds if insecure parsing patterns are detected in source or configuration drift, aligning with OWASP API Top 10 and compliance mappings available in higher plans.