Tải bản đầy đủ - 0 (trang)
13  Attempting XPath Injection Interactively

13  Attempting XPath Injection Interactively

Tải bản đầy đủ - 0trang

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




Amit Sethi





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() |

/users/user[username/text()='asethi']/password/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.

Testing for this vulnerability may require bypassing client-side JavaScript validation

(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

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

13  Attempting XPath Injection Interactively

Tải bản đầy đủ ngay(0 tr)