I wanted to cover something a bit different in this weeks blog post, specifically I decided to explain an injection based attack that isn’t SQL Injection! The huge amount of press and attention SQL Injection vulnerabilities quite rightly receive often means that other injection based attacks are either unheard of or underestimated. So I decided to give another Injection based attack its 15 minutes of fame today!
I’m going to cover XPath Injection which is very similar to SQL Injection with regards to the vulnerability it exploits (a lack of input validation) and even the methods used to exploit/test for these vulnerabilities is similar as you will see in my examples later on.
Before we jump into the explaining the vulnerability I have included a description of what XPath is below:
“XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSL Transformations [XSLT] and XPointer [XPointer]. The primary purpose of XPath is to address parts of an XML [XML] document. In support of this primary purpose, it also provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document.”
So in simple terms it is similar to SQL but instead of accessing databases you are acessing XML files.
The image below is a simple example of a website using an XML file called unames.xml to store the usernames and paswords of the website users.
The user enters their username and password into the website and clicks the submit button, the site will then execute an XPath query to see if the credentials are valid. The contents of unames.xml would be something similar to this:
If the credentials match the user is authenticated successfully.
If the website fails to validate the user supplied input it is possible to exploit this application in a very similar manner to a website with a SQL Injection vulnerability. When the website wants to check the validity of the users credentials it would execute an XPath query that looks like this:
//unames/user[loginID/text()=‘sninja’ and password/text()=‘secret’]
You can see that the syntax of the query is fairly easy to understand. It is accessing unames.xml and specifically the user node within unames.xml. The second part of the query is looking up the user supplied loginID and password values.
If a malicious user were to use this website they could execute an XPath injection attack against the authentication process as you can see in the image below:
The malicious user enters the well known injection test string of ‘ OR 1=1 into our website and in turn this is entered into our XPath query:
//unames/user[LoginID/text()=’ ‘ or 1=1 and password/text()=’ ‘ or 1=1]
This allows the malicious user to access the Ninja Test Site without having a valid username and password because 1=1 always equates to “true”.