fortify scan: XPath Injection

Similar to SQL Injection, XPath Injection attacks occur when a web site uses user-supplied information to construct an XPath query for XML data. By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured, or access data that they may not normally have access to. They may even be able to elevate their privileges on the web site if the XML data is being used for authentication (such as an XML based user file).

Querying XML is done with XPath, a type of simple descriptive statement that allows the XML query to locate a piece of information. Like SQL, you can specify certain attributes to find, and patterns to match. When using XML for a web site it is common to accept some form of input on the query string to identify the content to locate and display on the page. This input must be sanitized to verify that it doesn’t mess up the XPath query and return the wrong data.

XPath is a standard language; its notation/syntax is always implementation independent, which means the attack may be automated. There are no different dialects as it takes place in requests to the SQL databases.

Because there is no level access control it’s possible to get the entire document. We won’t encounter any limitations as we may know from SQL injection attacks.

Explanation:

XPath injection occurs when:

1. Data enters a program from an untrusted source.

2. The data used to dynamically construct an XPath query.

Example 1: The following code dynamically constructs and executes an XPath query that retrieves an email address for a given account ID. The account ID is read from an HTTP request, and is therefore untrusted.

...

string acctID = Request["acctID"];

string query = null;

if(acctID != null) {

       StringBuffer sb = new StringBuffer("/accounts/account[acctID='");

       sb.append(acctID);

       sb.append("']/email/text()");

       query = sb.toString();

}

XPathDocument docNav = new XPathDocument(myXml);

XPathNavigator nav = docNav.CreateNavigator();

nav.Evaluate(query);

...

Under normal conditions, such as searching for an email address that belongs to the account number 1, the query that this code executes will look like the following:

/accounts/account[acctID='1']/email/text()

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if acctID does not contain a single-quote character. If an attacker enters the string 1' or '1' = '1 for acctID, then the query becomes the following:

/accounts/account[acctID='1' or '1' = '1']/email/text()

The addition of the 1' or '1' = '1 condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

//email/text()

This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all email addresses stored in the document, regardless of their specified owner.

Recommendations:

The root cause of XPath injection vulnerability is the ability of an attacker to change context in the XPath query, causing a value that the programmer intended to be interpreted as data to be interpreted as a command instead. When an XPath query is constructed, the programmer knows what should be interpreted as part of the command and what should be interpreted as data.

To prevent an attacker from violating the programmer's expectations, use an allow list to ensure that user-controlled values used in an XPath query are composed from only the expected set of characters and do not contain any XPath metacharacters given the context in which they are used. If a user-controlled value requires that it contain XPath metacharacters, use an appropriate encoding mechanism to remove their significance within the XPath query.

Example 2

...

string acctID = Request["acctID"];

string query = null;

if(acctID != null) {

       try {

              iAcctID = Int32.Parse(acctID);

       }

       catch (FormatException e) {

              throw new InvalidParameterException();

       }

       StringBuffer sb = new StringBuffer("/accounts/account[acctID='");

       sb.append(acctID.toString());

       sb.append("']/email/text()");

       query = sb.toString();

}

XPathDocument docNav = new XPathDocument(myXml);

XPathNavigator nav = docNav.CreateNavigator();

nav.Evaluate(query);

Tips:

1. A number of modern web frameworks provide mechanisms to perform user input validation (including ASP.NET Request Validation and WCF). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. With ASP.NET Request Validation, we also provide evidence for when validation is explicitly disabled. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.