1. Attempting XPath Injection Interactively
1.1. Problem
XML Path Language (XPath) injection is an attack similar to SQL injection that is a potential
vulnerability when sensitive information in an application is stored in
XML files rather than in a database. XPath is a language used to select
nodes from XML documents. XPath 1.0 is currently the most popular
version, whereas XPath 2.0 (a subset of XQuery 1.0) is not as widely
used yet. Simple injection attacks such as the ones discussed in this
recipe will work in both XPath 1.0 and XPath 2.0; however, XPath 2.0
contains additional capabilities that may be interesting for attackers.
The additional features are not required for straightforward testing
such as what is discussed in this recipe; however, it is important to
keep in mind that if XPath 2.0 is being used in an application, the
impact of an exploit could be greater.
.2. Solution
Inject strings such as those shown in Example 1 into input fields in the application
suspected to be used in XPath queries and watch for unusual responses
from the server. An unusual response may be a random user record, a list
of all users, and so on. If such an unusual response is received, the
application may be vulnerable to XPath injection.
Example 1. Test inputs for finding XPath injection
1 or 1=1
1' or '1'='1' or '1'='1
1" or "1"="1" or "1"="1
|
Note that these inputs are quite similar to those we use to test
for SQL injection. To determine whether your application is vulnerable
to XPath injection or SQL injection, you should ask the development team
whether SQL queries or XPath queries are being used to process the input
in a given field.
1.3. Discussion
XPath injection shares many similarities with SQL injection and
LDAP injection. The only differences involve the query syntax and the
potential impact. If XML files are used to store sensitive information,
XPath is likely used by the application to retrieve information from the
files, and it may be possible to use XPath injection to bypass
authentication or gain access to sensitive information. Given that as a
tester you can obtain implementation details about the application
legitimately and use it to intelligently conduct specific tests, don’t
forget to ask the development team at your organization whether XPath
queries are used in the application before conducting these tests. It
would also be beneficial for you to obtain the real XPath queries being
used by the application so that you can easily generate valid test
inputs.
Consider Example 2 such that the
application stores usernames and passwords in the shown XML file.
Example 2. Sample XML file used to store credentials
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<id>1</id>
<username>asethi</username>
<password>secret123</password>
<realname>Amit Sethi</realname>
</user>
<user>
<id>2</id>
<username>admin</username>
<password>pass123</password>
<realname>Administrator<realname>
</user>
</users>
|
Also, suppose that the application authenticates users by using
the XPath query shown in Example 3.
Example 3. Example of XPath query vulnerable to XPath injection
/users/user[username/text()='username' and password/text()='password']/realname/text()
|
If the query returns a non-empty string, the user is
authenticated, and the application displays the message “Welcome
username.” Consider what would
happen if the attacker injected the string shown in Example 4 as the password.
Example 4. Example of malicious input to XPath query
']/text() | /users/user[username/text()='asethi']/password/text() | /a[text()='
|
The resulting XPath query would result in Example 5.
Example 5. Example of XPath query executed with malicious input
injected
/users/user[username/text()='username' and password/text()='']/text() |
/users/user[username/text()='asethi']/password/text() |
/a[text()='']/realname/text()
|
After executing this XPath query, the application will
successfully authenticate the user and will display the message “Welcome
secret123,” thus leaking a password to the attacker.
The impact of XPath injection is lower than the impact of SQL
injection in many cases because XPath queries can only be used to read
information from XML files. Modifying the contents of the underlying
data store is not possible with XPath injection. However, XPath
injection can be used to bypass authentication or gain access to
sensitive information such as passwords.
2. Attempting Server-Side Includes (SSI) Injection
Interactively
2.1. Problem
Server-Side Includes (SSI) is a server-side scripting language that allows inclusion
of simple dynamic content into web pages. If a server generates some
dynamic content that includes input controlled by a user and then
processes SSI directives, an attacker can cause the server to execute
arbitrary commands.
2.2. Solution
To test for SSI injection, insert the following into input fields
in a form and then submit it:
<!--%23echo var="DATE_LOCAL" -->
If the server is vulnerable to SSI Injection, it will display
something similar to the following
either on the page itself or in its source:
Saturday, 31-May-2008 23:32:39 Eastern Daylight Time
If the injected string appears verbatim in the web page’s source,
then the server is not susceptible to SSI injection for files with that
particular extension in that particular directory. For example, http://www.example.com/script.pl may not be
vulnerable to SSI injection, but http://www.example.com/page.shtml (different
extension) or http://www.example.com/samples/script.pl
(different directory) might be. Typically, the extensions .shtml, .stm, and .shtm are susceptible to such attacks.
Of course, the server may not include the user input in dynamic
content at all, which would mean that the particular input cannot be
used to carry out an SSI injection attack. The attack should be
attempted for all types of input fields including hidden fields.
2.3. Discussion
SSI injection is a powerful attack that allows the attacker to
execute arbitrary commands on the server. The test discussed is benign,
but a real attack may include SSI directives such the following:
The first one will execute any command specified by the attacker,
and the second one will reveal the contents of a file containing
potentially sensitive information to the attacker.
The attack described here is analogous to a reflected XSS attack.
There is also a similar attack that is analogous to stored XSS. In this
version of SSI, the attacker inserts the malicious commands into input
fields and may not observe any effects. However, the malicious input may
be stored on the server side and executed later when it is included in
another dynamically generated page (e.g., a log viewer).
Note that %23 is simply the
URL-encoded version of the #
character. This encoding is necessary when delivering the test input via
a GET parameter because the #
character is a fragment identifier in URLs and will cause the test input
to be interpreted incorrectly. In general, depending on the test input,
other characters may also need to be encoded.
