Tải bản đầy đủ - 0trang
13 Attempting XPath Injection Interactively
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.
Inject strings such as those shown in Example 12-28 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 12-28. 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.
If trying to subvert user authentication, attempt the techniques discussed in Recipe 12.16 using the test inputs just shown.
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 12-29 such that the application stores usernames and passwords in
the shown XML file.
12.13 Attempting XPath Injection Interactively | 259
Example 12-29. Sample XML file used to store credentials
Also, suppose that the application authenticates users by using the XPath query shown
in Example 12-30.
Example 12-30. 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 12-31 as the password.
Example 12-31. 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 12-32.
Example 12-32. Example of XPath query executed with malicious input injected
/users/user[username/text()='username' and password/text()='']/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
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.
260 | Chapter 12: Multifaceted Tests
12.14 Attempting Server-Side Includes (SSI) Injection
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.
To test for SSI injection, insert the following into input fields in a form and then submit
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 (see Recipe 3.1 for instructions on
viewing the page 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.
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
12.14 Attempting Server-Side Includes (SSI) Injection Interactively | 261
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). Testing for such attacks is
best done systematically as described in Recipe 12.15.
(see Recipe 5.1 for details).
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
12.15 Attempting Server-Side Includes (SSI) Injection
The techniques discussed in Recipe 12.14 work well when searching for “reflected SSI”
in a small number of URLs. However, it is difficult to interactively test for “stored SSI”
where an attacker injects a malicious SSI directive or to interactively test for “reflected
SSI” in a large number of URLs.
See Example 12-33.
Example 12-33. Script to systematically search for SSI injection
# Where do we put the responses received from the server?
# A file with URLs to attack, one per line
For a GET request, line should be http://:/?=
For a POST request, line should be http://:/
# If SSI Injection succeeds, a 'grep' for this string will help find it
typeset -i COUNTER
262 | Chapter 12: Multifaceted Tests