Xpath Injection in Chi with Jwt Tokens

XPath Injection is a server-side injection technique that occurs when an application builds XPath expressions using untrusted input without proper escaping or parameterization. In the Chi web toolkit for Go, this typically arises when route path parameters, query string values, or header-derived values (such as a JWT token payload claim) are concatenated directly into XPath strings used to query an XML document or an in-memory XML structure. Because XPath has no built-in parameterized query interface in many Go libraries, developers often interpolate strings to select nodes or attributes, for example selecting a user node by a username extracted from a JWT claim.

When JWT tokens are involved, the risk surface expands if the token payload is parsed and its claims are used to construct XPath expressions without validation or escaping. Consider a scenario where a JWT contains a username claim that is decoded and used to locate an XML user record: /users/user[username='alice']. If the application builds this path via string concatenation, an attacker can supply a username such as ' or username='admin' or ', altering the predicate logic and potentially selecting unintended nodes. This can lead to unauthorized data disclosure, authentication bypass (e.g., escalating to an admin user), or other logic flaws depending on how the selected node is interpreted downstream.

Chi does not introduce XPath handling itself; integration typically involves third‑party libraries. The framework passes request-scoped data (including headers and URL parameters) to handlers where developers may parse a JWT, extract claims, and use those claims to query XML. If the developer fails to treat the JWT-derived input as untrusted, the XPath expression becomes vulnerable. Additionally, if the JWT is used to gate access (e.g., asserting a role claim before executing an XPath query), an attacker may manipulate the token to gain elevated permissions while the XPath query itself remains susceptible to injection, compounding the impact. Because XPath expressions can traverse hierarchical data and return sensitive nodes, a successful injection can expose PII or configuration details embedded in the XML.

To mitigate this specific combination, treat JWT claims as untrusted input, avoid building XPath via concatenation, and prefer parameterized approaches or safe selection methods. In Chi, this means validating and sanitizing any data derived from the token before using it in XML queries, and employing libraries that support binding or filtering rather than string assembly. MiddleBrick’s scans can detect patterns where JWT-derived values are used in endpoint logic that interacts with XML processing, highlighting places where injection or overprivileged access may occur.

Remediation focuses on two goals: ensuring JWT handling does not introduce injection paths, and ensuring XPath usage is resilient against malicious input. Below are concrete, idiomatic examples in Go using Chi and a common XPath‑style XML library (such as github.com/antchfx/xpath and github.com/antchfx/xmlquery).

1. Validate and restrict JWT claims, avoid using raw claims in XPath

Decode the JWT, validate its structure, and extract only the specific claim you need. Do not directly interpolate the raw claim into an XPath string.

import (
    "context"
    "net/http"
    "strings"

    "github.com/golang-jwt/jwt/v5"
    "github.com/labstack/chi/v5"
)

func getUsernameFromToken(r *http.Request) (string, error) {
    tokenString := strings.TrimPrefix(r.Header.Get("Authorization"), "Bearer ")
    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
        // TODO: use your actual key and validation
        return []byte("your-secret-key"), nil
    })
    if err != nil || !token.Valid {
        return "", err
    }
    if claims, ok := token.Claims.(jwt.MapClaims); ok {
        if username, ok := claims["username"].(string); ok && username != "" {
            // Apply allowlist validation: only alphanumeric and limited symbols
            var validated strings.Builder
            for _, ch := range username {
                if (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '.' {
                    validated.WriteRune(ch)
                }
            }
            return validated.String(), nil
        }
    }
    return "", http.ErrAbortHandler
}

func handler(xmldata string) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        username, err := getUsernameFromToken(r)
        if err != nil {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }
        // Proceed safely; username is validated before use
        req, _ := xpath.Compile("/users/user[username=\"" + escapeXPath(username) + "\"]")
        // Use the compiled expression with a safe evaluation context
        _ = req
        // ... further processing with safe selection
    }
}

2. Use parameterized or safe selection instead of string-built XPath

Prefer libraries that support filtering functions or DOM traversal without building raw expressions. For example, with xmlquery you can iterate and compare nodes safely.

import (
    "github.com/antchfx/xmlquery"
    "golang.org/x/net/html"
)

func findUserNode(doc *xmlquery.Node, username string) *xmlquery.Node {
    // Iterate over /users/user nodes and compare the username element safely
    users := xmlquery.Find(doc, "/users/user")
    for _, user := range users {
        un := xmlquery.FindOne(user, "username")
        if un != nil && un.InnerText() == username {
            return user
        }
    }
    return nil
}

func handlerSafe(w http.ResponseWriter, r *http.Request) {
    username, err := getUsernameFromToken(r)
    if err != nil {
        http.Error(w, "unauthorized", http.StatusUnauthorized)
        return
    }
    doc, err := xmlquery.Parse(strings.NewReader(xmldata))
    if err != nil {
        http.Error(w, "invalid data", http.StatusBadRequest)
        return
    }
    userNode := findUserNode(doc, username)
    if userNode == nil {
        http.Error(w, "not found", http.StatusNotFound)
        return
    }
    // Process userNode safely
    _ = userNode
}

3. Apply strict input validation and escaping if XPath construction is unavoidable

If you must build an XPath expression dynamically, use a library that provides escaping for string literals within predicates. For string values, wrap them in quotes and escape internal quotes appropriately.

import (
    "github.com/antchfx/xpath"
)

func escapeXPath(s string) string {
    // Use XPath function escape-string per spec when available, otherwise implement escaping
    return xpath.Escape(s)
}

// Example of safe compilation when constructing dynamic paths
expr, err := xpath.Compile("/users/user[username=\"" + escapeXPath(username) + "\"]")
if err != nil {
    // handle error
}

These steps ensure that JWT-derived claims cannot alter the structure of XPath expressions. By validating claim formats, avoiding direct concatenation, and using safe selection APIs, you eliminate the injection vector while preserving the utility of JWT-based authorization in Chi handlers.

MiddleBrick can help identify places where JWT claims are used in endpoint logic that interacts with XML processing, providing findings and remediation guidance to reduce injection risk.