Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: edit #1, needs different CS

Due to its platform independence, flexibility and relative simplicity, extensible markup language (XML) has been widely adopted in a wide variety of applications, from remote procedure calls to data storage. However, because of its versatility, XML is vulnerable to attacks which change the structure of the document. One such attack is XML injection (MSC36-J. Prevent XML Injection), in which XML tags are injected directly into data fields. A variant of this is is XPath injection, in which the attacker manipulates a query into an XML-specified document.

XPath injection occurs when an XML document is used for data storage in a manner similar to a relational database. This way, an XPath injection attack is similar to an SQL injection attack (MSC34-J. Prevent against SQL Injection), where wherein an attack attacker is able to include enter valid query logic in a data field in such a way the the into data fields. Most often, the conditional field of the query resolves as to a tautology or otherwise gives the attacker access to privileged information it should not be entitled to.

This rule is a specific example of the broadly scoped rule FIO38-J. Validate user input.

...

Consider the following XML document being used as a database:schema.

Code Blocknoformat
<users>
  <user>
    <login>Utah</login>
    <password>test123<<password>C^f3</password>
  </user>
  <user>
    <login>Bohdi</login>
    <password>password<<password>C@fe</password>
  </user>
  <user>
    <login>Busey</login>
    <password>abc123<<password>cAf3</password>
  </user>
</users>

Unsafe Unsecured code will attempt to retrieve a user from this file with an XPath statement constructed dynamically from user input.

No Formatcode
str_query = "//users/user[LoginID/text()= " & login & 
            " and password/text()=" & password & "]"

Therefore, the user may specify input such as login = "' or 1=1" and password = "' or 1=1", yielding the following query string:.

No Formatcode
//users/user[LoginID/text()='' or 1=1  and password/text()='' or 1=1]

...

Noncompliant Code Example

XML Injection may occur when:

...

Consider the following example in which a login the context of the attack illustrated above. A username and password are is read from the user and used to construct the query string, in the context of the attack illustrated above.

Code Block
bgColor#FFcccc

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

public class XpathInjectionExample {

  publicclass XpathInjection {
  private 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[login/text()='" + 
        + loginID +"'" + "and password/text()='"+password+"' ]")";
    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());}       
         
    return (nodes.getLength() >= 1);
  }
}

The evaluate function call will return a set of all nodes in the XML file, causing the login function to return true, and bypassing authorization.

...

XPath injection can be prevented with many of the same methods used to prevent SQL injection, and input sanitization in general. These methods by adopting defenses similar to SQL injection. These include:

  • Assume Treat all input may include an attack.user input as untrusted
  • When validating user input, verify the data type, length, format and contentsthe content. For example, construct use a regular expression that checks for XML tags and special characters in user input.
  • In a client-server application, perform validation at both the client and server .side
  • Extensively test applications which supply or use user input.

In similar vulnerabilities such as SQL injection, the best practice to avoid injection vulnerabilities one recommended practice is to use a technique called parameterization. In this technique, in which user-specified data is passed directly to an API as a parameter, which in turn ensures that no data specified by the user is interpreted as execution executable logic. Unfortunately, such an interface does not currently exist in Java. However, this functionality can be emulated by using an interface such as XQuery, which enables the user to effectively parameterize data by specify specifying a query statement in a separate file, and only specify data supply the query at runtime. Consider the example illustrated above, the following query specified in a text file, and the following source code.

Input File: login.qry

No Formatcode
declare variable $loginID as xs:string external;
declare variable $password as xs:string external;//users/user[@loginID=
$loginID and @password=$password]

...

Using this method, the data specified in loginID and password fields will not be interpreted as executable expressions at runtime.

...

Failing to validate user input may result in a Java application being seriously compromised. Information disclosure is possible, but most likely the attacker will be able to modify sensitive information, such as in the example above in which the attacker modifies the data in the price field. In certain cases, such as a table representing users and privileges, the attacker could be able to modify information about their user account that would allow them to run code with elevated privilegesinformation disclosure and execution of unprivileged actions.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MSC36-J-J

medium

probable

medium

P4 P8

L3 L2

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

Fortify Software VulnCat

...

Wiki Markup
\[[Fortify 08|AA. Java References#Fortify 08]\] "Input Validation and Representation: XML Injection"
\[[Sen 07|AA. Java References#Sen 07]\]
\[[Sun 06|AA. Java References#Sun 06]\] [Ensure Data Security|http://java.sun.com/developer/technicalArticles/xml/jaxp1-3/index.html#Ensure%20Data%20Security]
Wiki Markup

\[[OWASP 05|AA. Java References#OWASP 05]\] [Testing for XMLXPath Injection|http://www.owasp.org/index.php/TestingXPath_forInjection_XMLTesting_InjectionAoC]