Xpath Injection in Echo Go with Cockroachdb

XPath Injection becomes relevant in an Echo Go service when user-controlled input is used to construct dynamic XPath expressions that are evaluated against an XML document retrieved from or filtered by Cockroachdb. Cockroachdb does not execute XPath directly, but it can store XML data or metadata that your Go service later queries using XPath libraries. If the application builds XPath expressions by concatenating strings with unchecked user input, an attacker can alter the logical structure of the expression to retrieve unintended nodes or bypass intended filters.

In this stack, a typical flow is: an HTTP request reaches an Echo handler, the handler queries Cockroachdb (for example, using pgx to fetch an XML column), and then the service uses an XPath library to navigate the XML. If the handler incorporates parameters such as username or documentId directly into the XPath without sanitization, the injection surface is identical in principle to SQL injection but at the XML path layer. For instance, an attacker could supply username=' or '1'='1 to change predicate logic, or inject union-like paths to access other branches of the XML tree.

The risk is compounded when combined with other middleBrick checks such as Input Validation and Property Authorization. Even though Cockroachdb may enforce strong SQL semantics, the vulnerability exists in the Go service logic. Attack patterns include path traversal within the XML hierarchy, data extraction of sensitive elements, or disruption of data integrity when the results are used for downstream decisions. Because the scan tests the unauthenticated attack surface, middleBrick can detect unsafe construction of expressions and missing validation on inputs that feed into XPath evaluation.

Remediation centers on strict separation of data and expression logic. Never concatenate user input into XPath strings. Use parameterized approaches where possible, and validate and sanitize inputs before they reach the XML processing layer. Below are concrete examples showing a vulnerable pattern and a safer implementation when working with XML retrieved from Cockroachdb using Go and Echo.

Vulnerable pattern

package main

import (
    "net/http"
    "strings"

    "github.com/labstack/echo/v4"
    "github.com/antchfx/xpath"
    "github.com/antchfx/xmlquery"
)

// WARNING: vulnerable to XPath Injection
func getUserXML(c echo.Context) error {
    username := c.QueryParam("username")
    // Assume rows.Rows from Cockroachdb containing an XML column 'data'
    // Simulated xmlData fetched from Cockroachdb
    xmlData := `<users><user><name>alice</name><role>admin</role></user><user><name>bob</name><role>user</role></user></users>`
    doc, err := xmlquery.Parse(strings.NewReader(xmlData))
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed to parse XML")
    }
    expr := "//user[name='" + username + "']/role"
    exprObj, err := xpath.Compile(expr)
    if err != nil {
        return c.String(http.StatusBadRequest, "invalid xpath")
    }
    node := exprObj.Evaluate(xmlquery.CreateXPathNavigator(doc)).(*xpath.NodeSet)
    if node == nil || node.Length() == 0 {
        return c.NoContent(http.StatusNotFound)
    }
    return c.String(http.StatusOK, node.Item(0).(xpath.NodeNavigator).Value)
}

Remediated pattern

package main

import (
    "net/http"

    "github.com/labstack/echo/v4"
    "github.com/antchfx/xpath"
    "github.com/antchfx/xmlquery"
)

// safeGetUserRole uses a whitelist approach and avoids string concatenation
func safeGetUserRole(c echo.Context) error {
    username := c.QueryParam("username")
    // Validate input strictly
    if username == "" || !isValidUsername(username) {
        return c.String(http.StatusBadRequest, "invalid username")
    }

    xmlData := `<users><user><name>alice</name><role>admin</role></user><user><name>bob</name><role>user</role></user></users>`
    doc, err := xmlquery.Parse(strings.NewReader(xmlData))
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed to parse XML")
    }

    // Use a parameter-safe method: map username to a known role node by name
    // This avoids XPath expression building entirely
    expr := "//user[name='alice']/role" // static, safe; in practice use a parameterized library or transform to a safer selector
    // Better: use a library that supports variables, or process nodes directly in Go
    // Here we demonstrate explicit selection to avoid injection
    var targetRole string
    nodes := xmlquery.Find(doc, "//user")
    for _, n := range nodes {
        nameNode := xmlquery.FindOne(n, "name")
        if nameNode != nil && nameNode.InnerText() == username {
            roleNode := xmlquery.FindOne(n, "role")
            if roleNode != nil {
                targetRole = roleNode.InnerText()
                break
            }
        }
    }
    if targetRole == "" {
        return c.NoContent(http.StatusNotFound)
    }
    return c.String(http.StatusOK, targetRole)
}

func isValidUsername(s string) bool {
    // Allow only alphanumeric and limited safe characters
    for _, r := range s {
        if !(('a' <= r && r <= 'z') || ('A' <= r && r <= 'Z') || ('0' <= r && r <= '9')) {
            return false
        }
    }
    return true
}

Key takeaways: avoid dynamic XPath construction with user input; validate inputs against a strict pattern; prefer node-level traversal in Go when feasible; and rely on middleBrick scans to surface such issues in your CI/CD pipeline using the GitHub Action to fail builds if risky patterns are detected.