XPath Injection Lab: Bypass an XML Login With Query Syntax

This article explains XPath injection, an attack that exploits how web applications build XPath queries from user input to authenticate against XML user stores. The lab demonstrates how an attacker can inject XPath syntax into a login form to bypass password verification and gain unauthorized access, mirroring the structural risks of SQL injection but targeting XML query languages instead.

• XPath injection exploits string concatenation in queriesApplications that build XPath expressions by directly concatenating user input allow attackers to inject XPath operators and syntax that rewrite the query logic. When credentials are looked up via an XPath query like 'select the user whose name and password both match', an attacker can send XPath syntax in the username or password field to change which nodes the query selects, typically making the password condition always true and selecting the admin node regardless of the actual password.
• Attack neutralizes password condition with logicThe core technique involves submitting the admin username combined with XPath syntax that collapses the password comparison into an always-true statement. This is accomplished by using XPath operators or quotes to transform the AND logic between username and password checks, so the expression selects the target node based on username alone, bypassing password validation entirely.
• Root cause identical to SQL injection patternsXPath injection is structurally the same vulnerability as SQL injection—untrusted user input is concatenated directly into a query language without parameterization or escaping. The only difference is the query language involved: XPath over XML instead of SQL, making it fall under the Injection category (A03) in the OWASP Top 10 (2021).
• Parameterized XPath with variable binding prevents injectionThe primary defense is using parameterised XPath (variable binding) so user data is never interpreted as query syntax. If parameterisation is unavailable, input must be strictly escaped and validated before being concatenated into an expression, and credentials should be stored in a proper datastore with hashing rather than matched inside an XML query itself.
• Detection indicator: quotes and brackets change resultsIf stray quotes or brackets in login or search input produce different results, the application is likely concatenating user input into an XPath expression. This behavioral indicator helps identify vulnerable systems in real-world assessments.
• Affects XML-backed authentication and older SOAP servicesXPath injection appears in applications that authenticate or search against XML documents by building queries from user input, with typical victims being older SOAP services and XML-backed login systems that have not moved to parameterised query patterns.
• Generic error messages reduce attacker feedbackReturning generic authentication error messages (rather than indicating whether a username or password failed) prevents attackers from using error responses to confirm successful injection or refine their payloads during an attack.

Bottom line: XPath injection is a direct parallel to SQL injection: it exploits concatenation of untrusted input into a query language, and it is prevented by using parameterised queries with variable binding rather than string concatenation. Understanding this vulnerability is critical because any application building XPath, SQL, LDAP, or similar queries from user input faces identical injection risks if proper parameterisation is not employed.