View
 

XPath Injection

Page history last edited by Robert Auger 14 years, 10 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-39

 

XPath Injection

XPath Injection is an attack technique used to exploit applications that construct XPath (XML Path Language) queries from user-supplied input to query or navigate XML documents. It can be used directly by an application to query an XML document, as part of a larger operation such as applying an XSLT transformation to an XML document, or applying an XQuery to an XML document. The syntax of XPath bears some resemblance to an SQL query, and indeed, it is possible to form SQL-like queries on an XML document using XPath. For example, assume an XML document that contains elements by the name user, each of which contains three subelements - name, password and account. The following XPath expression yields the account number of the user whose name is "jsmith" and whose password is "Demo1234" (or an empty string if no such user exists):

 

 string(//user[name/text()='jsmith' and
 password/text()='Demo1234']/account/text())

 

If an application uses run-time XPath query construction, embedding unsafe user input into the query, it may be possible for the attacker to inject data into the query such that the newly formed query will be parsed in a way differing from the programmer's intention.

 

 

Example

Consider a web application that uses XPath to query an XML document and retrieve the account number of a user whose name and password are received from the client. Such application may embed these values directly in the XPath query, thereby creating a security hole.

Here's an example (assuming Microsoft ASP.NET and C#):

 XmlDocument XmlDoc = new XmlDocument();
 XmlDoc.Load("...");
 
 XPathNavigator nav = XmlDoc.CreateNavigator();
 XPathExpression expr =
 nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'
 and password/text()='"+TextBox2.Text+
 "']/account/text())");
 
 String account=Convert.ToString(nav.Evaluate(expr));
 if (account=="") {
        // name+password pair is not found in the XML document
 –
        // login failed.
 } else {
        // account found -> Login succeeded.
        // Proceed into the application.
 }

When such code is used, an attacker can inject XPath expressions, e.g. provide the following value as a user name:

 ' or 1=1 or ''='

This causes the semantics of the original XPath to change, so that it always returns the first account number in the XML document. The query, in this case, will be:

 string(//user[name/text()='' or 1=1 or ''='' and
 password/text()='foobar']/account/text())

Which is identical (since the predicate is evaluates to true on all nodes) to:

 string(//user/account/text())

Yielding the first instance of //user/account/text().

The attack, therefore, results in having the attacker logged in (as the first user listed in the XML document), although the attacker did not provide any valid user name or password.

 

XPath 2.0

XPath 2.0 (http://www.w3.org/TR/xpath20/) attained a W3C "Recommendation" status in 2007. It expands the XPath 1.0 language in many aspects. The above discussion assumed XPath 1.0 syntax (which is fully incorporated in XPath 2.0). Yet if XPath 2.0 is used, then additional language features can be exploited by the attacker (once the initial injection vulnerability is found). For example, in XPath 2.0, it is possible to reference not just the "current" document, but (in theory), any accessible document, by its URL (using "http"/"https" scheme of "file" scheme).

 

References

"XML Path Language (XPath) Version 1.0” W3C Recommendation, 16 Nov 1999

[1] http://www.w3.org/TR/xpath

 

"Encoding a Taxonomy of Web Attacks with Different-Length Vectors", G. Alvarez and S. Petrovic

[2] http://arxiv.org/PS_cache/cs/pdf/0210/0210026v1.pdf

 

"Blind XPath Injection", Amit Klein

[3] http://www.packetstormsecurity.org/papers/bypass/Blind_XPath_Injection_20040518.pdf

 

Failure to Sanitize Data within XPath Expressions ('XPath injection')

[4] http://cwe.mitre.org/data/definitions/643.html

Comments (0)

You don't have permission to comment on this page.