XPath injection attacks and Prevention

 
Avoid the risk of XPath Injection
-- Be aware of risks to better protect XML applications

Robi Sen (rsen@department13.com), Vice President of service, Department13

With the development of simple XML APIs, Web Services, and Rich Internet Applications (RIAs), more organizations use XML as the data format in almost all aspects (from configuration files to remote process calls. Some people have used XML documents to replace more traditional plain text files or relational databases, but they are similar to any other application or technology that allows external users to submit data, XML applications may be vulnerable to code injection attacks, especially XPath injection attacks.

Introduction

With the emergence of new technologies and their continued use, the threat to these technologies has also increased. SQL blind injection attacks are a well-known form of code injection attacks, but there are also many other forms, some of which are not well documented and understood. One of the most recent code injection attacks is XPath injection, which utilizes the loose input and fault tolerance features of the XPath parser, attackers can attach malicious XPath queries to URLs, forms, or other methods to gain access to and modify permission information.

This article describes how to execute XPath attacks and provides a Java™And examples in the XML environment. This article discusses how to detect such threats, how to mitigate such threats, and finally how to deal with suspicious intrusions.

Getting started

This article describes a special type of code injection attacks: XPath blind injection. If you are not familiar with XPath 1.0 or need basic knowledge, see the W3 Schools XPath tutorial (see the link in references ). You can also find a lot of articles on using XPath in a variety of Language Environments on developerWorks (see references ). The examples used in this article are mainly for XPath 1.0, but can also be used for XPath 2.0. XPath 2.0 actually adds issues that you may encounter.

This article also provides examples of Java code used to process Java JDK 5.0. At the same time, the concepts and themes in this article are cross-platform. If your application uses XPath to obtain special code examples, you must use JDK 5.0.

Code Injection

A more common attack and threat to Web applications is some form of code injection. Wikipedia defines it:

...... The technology that introduces (or "injects") code to a computer system using the assumption that the system does not enforce or check its input. The purpose of code injection is usually to bypass or modify the program's initial target function. If the bypass function involves system security, the result may be disastrous.

Quick browsing of any related Web site (such as Web Application Security Consortium or Security Focus, see the link in reference) will show many attacks using some form of code injection, from JavaScript to SQL injection to other forms of code injection attacks. One of the most recent threats (originally outlined in a paper by Amit Klein in 2004) is XPath blind injection attacks (see references ). This attack operates almost exactly like SQL blind injection attacks. Unlike SQL injection attacks, almost no one knows about or prevents XPath blind injection attacks. Similar to SQL injection attacks, if you use best practices to develop secure applications, you can easily handle this threat.

XPath attacks

Generally, 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 containing a unique ID, login name, password, and other information, such as a role. Retrieving a user's SQL query from the users table may be similar to listing 1.

Listing 1. Retrieving users' SQL queries from the users table

Select * from users where loginID = foo and password = bar

In this query, you must provide the loginID and password as the input. If the attacker enters: or 1 = 1 in the loginID field and enters: or 1 = 1 in the password field, the query is similar to listing 2.

List 2. query from attacker Input

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

This condition will always match, so attackers can access the system. XPath injection works in a similar way. However, assume that you have not a users table but an XML file that contains the user information 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>
& Lt; password & gt; 123 test & lt;/password & gt;
</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 matching SQL queries

// Users/user [loginID/text () = abc and password/text () = test123]

To perform similar attacks to bypass authentication, you may use methods similar to listing 5.

Listing 5. bypass authentication

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

You may have a method such as doLogin in a Java application. Use the XML document in listing 3 to perform authentication again. It 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 first 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 ;}
}
}

For Listing 6, if you input a login and password, for example, loginID = abc and password = test123, this class returns true (and in this example, A column of first name will be printed to the console ). For example, if you pass in a value similar to or 1 = 1 or =, you will also get the true return value, because XPath will eventually find that the string looks like listing 7.

Listing 7. String

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

This string will logically enable the query to always return true and allow attackers to access the system.

Another more likely and more troublesome method of XPath attacks is that attackers can use XPath to dynamically operate XML documents in applications.

Back to Top

Extract XML document structure

Queries used to bypass authentication can also be used to extract information about XML documents. Suppose the attacker guessed that the name of the first child node in the XML document is loginID and wants to confirm it. Attackers can provide the input shown in listing 8.

Listing 8. input provided by attackers

Abc or name (// users/LoginID [1]) = LoginID or a = B

Unlike 1 = 1 in listing 7, the expression given in listing 8 checks whether the name of the first subnode is loginID. The created query is shown in listing 9.

Listing 9. Query

String (// users [LoginID/text () = abc or name (// users/LoginID [1]) =
LoginID or a = B and password/text () =])

With the try-out method, attackers can check the child nodes of the XML document and check whether the XPath expression can enable successful authentication to collect information. Attackers may then write a simple script, send various XPath injections, and extract XML documents from the system, as described in Klein's paper.

XPath injection prevention

Because XPath injection attacks are similar to SQL injection attacks, many preventive methods are similar. Most of these preventive methods can be used similarly to prevent other types of code injection attacks.

Authentication

Regardless of the application, environment, or language, the following best practices should be observed:

* It is assumed that all inputs are suspicious.
* It is not only necessary to verify the data type, but also its format, length, range, and content (for example, a simple regular expression if (/^ "* ^; & <> () ).
* Data must be verified on both the client and server because client authentication is very easy to bypass.
* Comply with the best practices of security software development and the [missing word] policy for application security (see Apache's excellent Web