Welcome to HBH! If you had an account on hellboundhacker.org you will need to reset your password using the Lost Password system before you will be able to login.

XPath Injection Attacks


XPath Injection Attacks

By ghostghost | 7356 Reads |
0     0

XPath Injection Attacks

PREREQUISITE -

  • Basic Programming Skills and Data manipulation in XML (Extensible Markup Language) and XPath.
  • Basic Knowledge of Web Applications’ Input Vulnerabilities and Sanitisation Methods
  • Beginner level Understanding of Client/Server Communication Protocol and Authentication Procedure

SUGGESTED KNOWLEDGE -

  • Intermediated Understanding of ASP.NET, JAVA and/or C# Code and Web Programming

PURPOSE -

  • Attack used to Extract data from XML Databases/documents
  • Manipulate Data from local/remote location to Server (Victim)

DEFINITIONS -

[1]“XPath injection is an attack targeting Web sites that create XPath queries from user-supplied data. If an application embeds unprotected data into an XPath query, the query can be altered so that it is no longer parsed in the manner originally intended. This can be done by bypassing the Web site authentication system and extracting the structure of one or more XML documents in the site.”

[2]“XPath 1.0 is a language used to refer to parts of an XML document. It can be used directly by an application to query an XML document, or as part of a larger operation such as applying an XSLT transformation to an XML document, or applying an XQuery to an XML document.”

Similar to SQL Injections, XPath injections manipulate data on XML databases. Therefore, an analogy can be created to relate the two injection methods. They share many things in common, such as the use of regex expressions, and, most importantly, their payload; in this case, to obtain data from a server locally, or in most cases remotely from the client.

Assuming, you know XML and XPATH, we’re going to dive directly into the attack Methodology by using examples of exploitable vulnerabilities.

1ST EXAMPLE: Similarities to SQL…

In SQL, we use regex expressions to “trick” the server, by passing (somewhat) malicious input to it, like:

if the login system was setup as follows: Select * from users where LoginID=’ ’ and passwd=’ ’

we can exploit as such: abc’ or 1=1 –

and we’ll have a payload or desired input query passed to the server to execute our input, thus making it be: Select * from users where LoginID = ‘abc’ or 1=1 – ‘and passwd=’ ’

we commented out the password requirement, and passed only our LoginID, which turns out to be TRUE.

The Same concept applies to XML databases/documents with a XPath Injections… That same code, when translated to XPath, becomes:

For the Insecure/exploitable Login System, accepts input as follows: String(//users[LoginID/text()=’ “ + txtLoginID.Text + “ ’ and passwd/text()=’ “+ txtPasswd.Text +” ’])

Now, we type into the LoginID: abc’ or 1=1 or ‘a’=’b

Thus, also suppressing the need to type in a password, and turns our loginID into a valid one from the database/document in XML. Like: String(//users[LoginID/text()=‘abc’ or 1=1 or ‘a’=‘b’ and passwd/text()=’’])

We get a payload/desired input query passed as: LoginID=‘abc’ or 1=1 or ‘a’=‘b’ and passwd/text()=’ ’

(which can also be represented, logically, as A OR B OR C AND D)

2ND EXAMPLE: More complex Procedure…

Insecure/Exploitable Code in XML: 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. }

for the username query, we place this injection: ’ or 1=1 or ‘’=’

As a payload, we get this code parsed and executed by the server: string(//user[name/text()=’’ or 1=1 or ‘’=’’ and password/text()=‘foobar’]/account/text())

Tada! Now, We get an output result of: string(//user/account/text())

In other words, we have an instance of //user/account/text()

What this does is log us in as the first user in the XML document.

CONCLUSION - Hope you got something from this article. I will try to write an article on XML/XPath programming in the Future (if time allows). But for now, learn at your own pace, and explore the depths of this notorious, yet esoteric attack. I also urge you to try a combination or blind injections, when you have time on your hands. For beginners, I hope this sparks your interest and hunger for more knowledge; I’d suggest learning and doing HBH’s web patching challenges, whichm by the ware, are my favourite here.

Truly doing something fishy,

  • NETFISH.

WORKS CITED: http://en.hakin9.org/attachments/xpath_new_en.pdf http://palisade.plynt.com/issues/2005Jul/xpath-injection/ http://www.webappsec.org/projects/threat/classes/xpath_injection.shtml http://www.spidynamics.com/spilabs/education/articles/code-injection.html http://searchappsecurity.techtarget.com/sDefinition/0,,sid92_gci1193384,00.html

Comments
ghost's avatar
ghost 17 years ago

nice article. this is something i wouldn't have really looked into.

ghost's avatar
ghost 17 years ago

very nice article. I have never read anything on this topic before.