Introduction to XPath Blinds

This article mainly introduces a special type of code injection attack: XPath blind.

If you are unfamiliar with XPath 1.0 or need to know the basics, check the W3 Schools XPath Tutorial. You can also find a lot of articles on DeveloperWorks that use XPath in a variety of locales. The examples used in this article are primarily for XPath 1.0, but can also be used for XPath 2.0. XPath 2.0 actually increases the number of problems you may encounter.

This article also provides examples of Java code for handling Java JDK 5.0. At the same time, the concepts and themes of this article are Cross-platform, and if your application uses XPath to get a special code example, you must use JDK 5.0.

Code Injection
One of the more common attacks and threats against WEB applications is some form of code injection, which Wikipedia defines as: the technique of introducing (or "injecting") code into a computer system without the assumption that its input is enforced or checked.

The purpose of injecting code is usually to bypass or modify the original target function of the program. If the bypassed functionality involves system security, the result can be catastrophic.

Quickly browsing any relevant web sites (such as Web application security Consortium or security focus) will show many attacks using some form of code injection, from JavaScript to SQL injection to other forms Code injection attack. One of the most recent threats is an XPath blind attack. This attack operates almost exactly like a SQL blind attack, and unlike SQL injection attacks, few people understand or prevent an XPath blind attack. Similar to SQL injection attacks, this threat can often be easily handled if you develop a secure application using best practices.

XPath Attack
Generally speaking, most WEB applications use relational databases to store and retrieve information.

For example, if your Web site requires authentication, you may have a users table that contains unique IDs, logins, passwords, and perhaps other information, such as roles. Retrieving a user's SQL query from the users table might resemble listing 1.

Listing 1. Retrieving a user's SQL query from the Users table

Select * from users where loginid= ' foo ' and password= ' bar '

In this query, the user must provide loginID and password as input.

If the attacker enters in the loginID field: ' or 1=1

and enter in the password: ' or 1=1 will form a query similar to Listing 2.

Listing 2. Queries formed from attackers ' input

Select * from users where loginID = ' or 1=1 and password= ' or 1=1

This condition will always match, so attackers can enter the system.

The principle of XPath injection is broadly similar. However, suppose you have not a users table, but an XML file that contains the user information as shown in Listing 3.

Listing 3. User.xml

<?xml version= "1.0" encoding= "UTF-8"?>
<users>

<user>

<firstname>Ben</firstname>

<lastname>Elmore</lastname>

<loginID>abc</loginID>

<password>test123</password>

</user>

<user>

<firstname>Shlomy</firstname>

<lastname>Gantz</lastname>

<loginID>xyz</loginID>

<password>123test</password>

</user>

<user>

<firstname>Jeghis</firstname>

<lastname>Katz</lastname>

<loginID>mrj</loginID>

<password>jk2468</password>

</user>

<user>

<firstname>Darien</firstname>

<lastname>Heap</lastname>

<loginID>drano</loginID>

<password>2mne8s</password>

</user>

</users>

In XPath, statements similar to SQL queries are shown in Listing 4.

Listing 4. XPath statements that match SQL queries

Users/user[loginid/text () = ' abc ' and Password/text () = ' test123 ']

To perform a similar attack to bypass authentication,

If the attacker enters in the loginID field: ' or 1=1

and enter in Password: ' or 1=1 you might use a method like listing 5.

Listing 5. Bypassing authentication

Users/user[loginid/text () = ' or 1=1 and password/text () = ' or 1=1]

You might have a method such as Dologin in a Java application that uses the XML document in Listing 3 to perform the authentication again. may be similar to listing 6.

Listing 6. Xpathinjection.java

Import java.io.IOException;
Import org.w3c.dom.*;
Import org.xml.sax.SAXException;
Import javax.xml.parsers.*;
Import javax.xml.xpath.*;

public class Xpathinjectionexample {

public boolean Dologin (string loginID, string password)

Throws Parserconfigurationexception, Saxexception,ioexception,

xpathexpressionexception {

Documentbuilderfactory domfactory = Documentbuilderfactory.newinstance ();

Domfactory.setnamespaceaware (TRUE);

Documentbuilder builder = Domfactory.newdocumentbuilder ();

Document doc = Builder.parse ("Users.xml");

Xpathfactory factory = Xpathfactory.newinstance ();

XPath XPath = Factory.newxpath ();

XPathExpression expr = Xpath.compile ("//users/user[loginid/text () = ' +loginid+" '

and password/text () = ' "+password+" ']/firstname/text () ");

Object result = Expr.evaluate (doc, Xpathconstants.nodeset);

NodeList nodes = (nodelist) result;

Print the names to the console

for (int i = 0; i < nodes.getlength (); i++) {

System.out.println (Nodes.item (i). Getnodevalue ());

if (Nodes.getlength () >= 1) {

return true;

}

else{

return false;

}

}

}

XML injection (XML injection)

Like HTML script injection, XML is vulnerable to attacks where the data provided by the attacker is contained in the output. The three most common XML injection attacks are: XML data injection, Extensible Stylesheet Language Transformation (extensible Stylesheet Language transformation,xslt) injection and xpath/xquery injection. · XML data injection (XML injection)

XML is often used to store data, and if the user-supplied data is stored in XML, it is possible for an attacker to inject additional XML that may not be properly controlled by the attacker. Consider the following XML, in which an attacker can only control the attacker text text:

<?xmlversion= "1.0" encoding= "UTF-8"?>
<user role= "Guest" >attacker text</user>

If you replace attacker Text with your input, that would be an interesting test case. If developers are not cautious, they may mistakenly allow XML injection.

If you use the User1</user><user role= "admin" >user2 as input, the following XML will be generated (the user enters the bold text section):

<?xmlversion= "1.0" encoding= "UTF-8"?>
<user role= "Guest" >User1</USER>
<user role= "Admin" >User2</USER>

If the application reads this file and decides which access rights to assign to each user, User2 will get administrator privileges.

Tips If you can inject data into a part of an XML file, it is valuable to send the same elements and attributes that were present in the previous XML and that you cannot access. Some XML parsers use the last instance of the element/attribute specified, so you might be able to selectively overwrite some of the previous values.

• Extensible Stylesheet Language (XSL)

In addition to injecting data into XML, as a result of XML injection, it is possible to run the code. XSL consists of an XSL Transformation (XSL transform,xslt), an XML Path Language (XML pathlanguage,xpath) expression, and an XSL-formatted object (formatting Object,xsl-fo). and allows the use of style sheets in XML files. This style sheet can convert existing XML data into new XML data. This new XML document is typically displayed in HTML in a Web browser. In this case, the attacker was able to inject data that would cause the script to run in the browser.

For example, the following XML is part of an RSS feed (RSS feed) that references a hyperlink:

<link>AttackerText</link>

To represent the above XML, the application XSLT converts the above XML to HTML as follows and passes to the Web browser:

<ahref= "Attacker Text" >attacker text</a>

If you control the attacker text, can you think of a way to run the script? Even if the programmer HTML encodes the text provided by the attacker, the attacker could still use the Scripting protocol to run the script through input similar to Javascript:alert (). If the HTML behaves differently from the original RSS feed (RSS feed) at a site or a certain range, then this is an HTML script attack that is triggered by XML data.

Important Tips When testing XML injection, you can try to send angle brackets and quotation marks to escape the current XML attribute/tag. When the application is properly protected, it does not allow the user to provide data to turn Semantic XML tags and attributes so that you can prevent XML injection attacks. Typically, test cases that apply to script injection and Cross-site scripting also apply to XML injection.

· Xpath/xquery Injection

XPath and XQuery are languages that can query XML documents, similar to Structured Query Language (SQL). In fact, many popular databases allow the use of XPath and XQuery to query the database. In many cases, an attacker could not directly access XML data, but an attacker could use part of the data to create XPath and XQuery statements that could be used to query XML. This allows an attacker to inject arbitrary queries through carefully constructed input to obtain data that, under normal circumstances, is not allowed to be accessed by an attacker.

An XML file can include different parts or areas of information. Sometimes only a specific part of this information is exposed to the end user, for example, the following XML contains the name and social Security Number:

<?xmlversion= ' 1.0 '?>
<staff>

<author>

<name>tom gallagher</name>

<SSN>123-45-6789</SSN>

</author>

<author>

<name>bryan jeffries</name>

<SSN>234-56-7890</SSN>

</author>

<author>

<name>lawrence landauer</name>

<SSN>012-345-6789</SSN>

</author>

</staff>

This XML is stored on a Web server and is not accessible to end users directly. A Web page used to query XML on this server can be accessed by end users, and only the author's name can be displayed through the Web page. XML data can be obtained using the following XPath expressions:

*[contains (name, ' Attacker-data ')]/name

Attacker-data is the end user-specified data, as you can see, the attacker is able to control some XPath queries. By specifying data for X ')] | //*| *[contains (name, ' Y), the attacker can get the full content of this XML file. This input constructs the following XPath expression:

*[contains (name, ' x ')] | //*| *[contains (name, ' y ')]/name

Note In the above expression, the pipe symbol (|) is used to represent or manipulate, and a left slash and an asterisk (//*) represent all nodes. The above XPath expression may have the following three cases:

1. Any name that contains X

2. Any node in this XML file

3. Any name that contains Y

Because it is possible to return all nodes in the second case, the attacker can obtain all the data for the XML file.

More information For more information on XPath injection, see Amit Klien in Https://www.watchfire.com/securearea/whitepapers.aspx?id=9 The article "Blind XPath Injection" on the.

Tip The concept for Xpath/xquery injection also applies to SQL