Xpath Injection with Hmac Signatures

Xpath Injection in the context of Hmac Signatures occurs when an attacker can influence an XPath expression that is constructed using data which is also used to compute an HMAC. If the application builds an XPath string by concatenating user-controlled input and then uses that XPath to retrieve a signing value or key material from an XML document, the attacker can break out of the intended node selection and change which data is signed. This changes the Hmac Signature without knowing the secret because the attacker steers the XPath to a different element or attribute that yields a predictable or attacker-supplied value.

Consider an API that signs a request using a secret key stored in an XML configuration file. The service selects the secret with an XPath expression built from an HTTP header value. A vulnerable implementation might look like this in Java with XPath and a Mac instance for Hmac-SHA256:

String userHeader = request.getHeader("X-Entity-ID");
String expr = "//secrets/entity[@id='" + userHeader + "']/hmacSecret";
String secret = evaluateXPath(expr); // returns the secret string
Mac mac = Mac.getInstance("HmacSHA256");
SecretKeySpec key = new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), "HmacSHA256");
mac.init(key);
byte[] signature = mac.doFinal(payload.getBytes(StandardCharsets.UTF_8));
// send request with signature in a header

An attacker can supply ' or 1=1 or ' as the header, transforming the XPath into //secrets/entity[@id='' or 1=1 or ''']/hmacSecret, which can select the first secret node or an attacker-injected node depending on how the XML is structured. The Hmac Signature is then computed with an attacker-known key, allowing them to forge valid signatures. In XML Signature standards that embed KeyInfo references, an attacker might also manipulate the XpathURI fragment to redirect the canonicalization and signing inputs, leading to a signature that validates under a different context than intended.

Another pattern appears when XPath is used to locate a certificate or key identifier inside an XML document that is later fed into an Hmac routine. If the identifier is user-controlled and not strictly validated, an attacker can traverse to a different key entry, compute the Hmac with that key, and impersonate another service. This maps directly to the BOLA/IDOR class of findings because the access boundary is bypassed by manipulating the path expression rather than the authentication token itself.

middleBrick detects this category by combining OpenAPI/Swagger analysis with active runtime checks. During spec parsing, the scanner looks for parameters or headers that flow into both cryptographic operations and XPath evaluations. It identifies endpoints where a user-supplied value is concatenated into an XPath expression and where an Hmac Signatures routine is invoked on data derived from an XML source.

During the scan, middleBrick runs a series of probes to detect XPath Injection. It sends crafted strings designed to alter node selection, such as quotes, boolean conditions, and path traversal sequences, then observes whether the resulting Hmac Signature changes in a way that indicates a different key or data node was used. Because middleBrick performs black-box testing, it does not need source code or credentials; it observes behavior at the API surface.

The LLM/AI Security module adds an extra layer by checking whether any endpoint that handles Hmac Signatures also exposes unauthenticated paths that return XML or key metadata. If an endpoint accepts a user-controlled XPath-like parameter and returns signed tokens, this is flagged as a high-risk configuration. middleBrick reports these findings with severity ratings, mapping them to frameworks like OWASP API Top 10 (2023) A01:2023 Broken Object Level Authorization and A05:2023 Injection, and provides remediation guidance tied to Hmac Signatures usage.

To fix Xpath Injection in Hmac Signatures workflows, keep XPath construction static and never concatenate user input into the expression. Use parameterized XPath APIs or bind variables where available, and validate input against a strict allowlist (e.g., regex for ID format). If the signing key must be selected from XML, retrieve a known set of candidates first, then use a constant-time lookup in application code instead of dynamic XPath selection.

In Java, prefer a compiled XPath with a variable binding rather than string concatenation:

XPathFactory xpf = XPathFactory.newInstance();
XPath xpath = xpf.newXPath();
// Use a parameter resolver to avoid injection
xpath.setNamespaceContext(myResolver);
InputSource src = new InputSource(new StringReader(xml));
Node secretNode = (Node) xpath.evaluate("//secrets/entity[@id=$id]/hmacSecret", src, XPathConstants.NODE);
String secret = secretNode.getTextContent();
Mac mac = Mac.getInstance("HmacSHA256");
mac.init(new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), "HmacSHA256"));
byte[] signature = mac.doFinal(payload.getBytes(StandardCharsets.UTF_8));

Additionally, enforce strict schema validation on the XML input and avoid exposing internal node structures through error messages. Rotate Hmac keys using a secure vault and ensure that the selection criteria for which key to use do not rely on attacker-controlled paths. With middleBrick Pro, you can enable continuous monitoring so that any regression in how XPath and Hmac Signatures interact is flagged promptly through GitHub Action PR gates or CI/CD pipeline checks.