Page History

XPath injection occurs when an XML document is Extensible Markup Language (XML) can be used for data storage in a manner similar to a relational database. Data is frequently retrieved from such an XML document using XPaths. XPath injection can occur when data supplied to an XPath retrieval routine to retrieve data from an XML document is used without proper sanitization. This attack is similar to SQL injection or XML injection (MSC33see IDS00-J. Prevent against SQL Injection), wherein an Sanitize untrusted data passed across a trust boundary). An attacker can enter valid SQL or XML constructs into in the data fields of the query in use. Most oftenIn typical attacks, the conditional field of the query resolves to a tautology or otherwise gives the attacker access to privileged information.

This rule guideline is a specific example of the broadly scoped rule FIO35IDS52-J. Always validate user input.Prevent code injection.

XML Path Injection Example

Consider the following XML schema.:

<users>
  <user>
    <login>Utah<<username>Utah</login>username>
    <password>C^f3<<password>e90205372a3b89e2</password>
  </user>
  <user>
    <login>Bohdi<<username>Bohdi</login>username>
    <password>C@fe<<password>6c16b22029df4ec6</password>
  </user>
  <user>
    <login>Busey<<username>Busey</login>username>
    <password>cAf3<<password>ad39b3c2a4dabc98</password>
  </user>
</users>

The passwords are hashed in compliance with MSC62-J. Store passwords using a hash function. MD5 hashes are shown here for illustrative purposes; in practice, you should use a safer algorithm such as SHA-256.

Untrusted code may attempt to retrieve a user details from this file with an XPath statement constructed dynamically from user input.

str_query = "//users/user[LoginIDusername/text()= " & login & 
            " '&LOGIN&' and password/text()=" & password & "]"
'&PASSWORD&' ]

If an attacker knows that Utah is a valid user name, he or she can specify an input such as

Utah' or '1'='1

This yields An attacker may specify input such as login = "{{' or 1=1"}} and password = "{{' or 1=1"}}, yielding the following query string.

//users/user[LoginIDusername/text()='Utah' or '1'='1'  and password/text()='xxxx'' or 1=1]
]

Because the '1'='1' is automatically true, the password is never validated. Consequently, the attacker is inappropriately authenticated as user Utah without knowing Utah's password.This may expose all the records in the XML file

Noncompliant Code Example

In this This noncompliant code example , reads a user name and password is read from the user and used uses them to construct the query string. The evaluate function call returns a set of all nodes password is passed as a char array and then hashed. This example is vulnerable to the attack described earlier. If the attack string described earlier is passed to evaluate(), the method call returns the corresponding node in the XML file, causing the login function doLogin() method to return true and bypass any authorization.

class XpathInjection {
  private boolean doLogin(String loginIDuserName, Stringchar[] password)
    throws ParserConfigurationException, SAXException, IOException, XPathExpressionException {

    DocumentBuilderFactory domFactory = DocumentBuilderFactory.newInstance();
    domFactory.setNamespaceAware(true);
    DocumentBuilder builder = domFactory.newDocumentBuilder();
    Document doc = builder.parse("users.xml");

    String pwd = hashPassword( password);

  XPathFactory factory = XPathFactory.newInstance();
    XPath xpath = factory.newXPath();
    XPathExpression expr = xpath.compile("//users/user[loginusername/text()='" + 
       userName + loginID +"'" + "and password/text()='" +password pwd + "' ]");
    Object result = expr.evaluate(doc, XPathConstants.NODESET);
    NodeList nodes = (NodeList) result;

    // printPrint first names to the console 
    for (int i = 0; i < nodes.getLength(); i++) {
    Node node = System.out.println(nodesnodes.item(i).getChildNodes().item(i1).getNodeValuegetChildNodes().item(0);}       
    System.out.println( "Authenticated: "   + node.getNodeValue());
  }

  return (nodes.getLength() >= 1);
  }
}

Compliant Solution (XQuery)

XPath injection can be prevented by adopting defenses similar to those used to prevent SQL injection. These include:

• Treat all user input as untrusted, and perform appropriate sanitization.
• When validating sanitizing user input, verify the correctness of the data type, length, format, and the content. For example, use a regular expression that checks for XML tags and special characters in user input. This practice corresponds to input sanitization. See IDS52-J. Prevent code injection for additional details.
• In a client-server application, perform validation at both the client and the server sidesides.
• Extensively test applications that supply, propagate, or use accept user input.

An effective technique for preventing the related issue of SQL injection is parameterization. Parameterization ensures that In similar vulnerabilities such as SQL injection, an effective prevention technique is parameterization. In this technique, user-specified data is passed directly to an API as a parameter , which ensures such that no the data specified by the user is never interpreted as executable logiccontent. Unfortunately, such Java SE currently lacks an interface does not currently exist in Javaanalogous interface for XPath queries. However, this functionality an XPath analog to SQL parameterization can be emulated by using an interface such as XQuery , which enables the user to effectively parameterize data by that supports specifying a query statement in a separate file , and supply the query at runtime. This compliant solution uses a query specified in a text file by reading the format and entering values for the user name and password in a Map. The XML query is constructed from these elements subsequentlysupplied at runtime.

Input File: login.qry

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

This compliant solution uses a query specified in a text file by reading the file in the required format and then inserting values for the user name and password in a Map. The XQuery library constructs the XML query from these inputs.

private boolean doLogin(String userName, String pwd)

Document doc = new Builder().build  throws ParserConfigurationException, SAXException, IOException, XPathExpressionException {

  DocumentBuilderFactory domFactory = DocumentBuilderFactory.newInstance();
  domFactory.setNamespaceAware(true);
  DocumentBuilder builder = domFactory.newDocumentBuilder();
  Document doc = builder.parse("users.xml");

  XQuery xquery = new XQueryFactory().createXQuery(new File("login.xryxq"));

  Map queryVars = new HashMap();

  queryVars.put("loginiduserName", "Utah"userName); // user name hard coded for illustrative purposes

  queryVars.put("password", "securecoding"pwd);
 // passwordNodeList hard coded for illustrative purposes 

Nodes results nodes = xquery.execute(doc, null, queryVars).toNodes();

  // Print first names to the console
  for (int i = 0; i < resultsnodes.sizegetLength(); i++) {
    Node node = nodes.item(i).getChildNodes().item(1).getChildNodes().item(0);
    System.out.println(resultsnode.getgetNodeValue(i).toXML()));
  }

  return (nodes.getLength() >= 1);
}

Using this method, the data specified in the loginID and userName and password fields is not cannot be interpreted as executable content at runtime.

In addition, OWASP \[[OWASP 05|AA. Java References#OWASP 05]\] recommends:

Applicability

Failure to validate user input may result in information disclosure and execution of unprivileged code.

According to OWASP [OWASP 2014],

[Prevention of XPath injection] This requires the following characters to be removed (ie that is, prohibited) or properly escaped:

• < > / ' = " to  to prevent straight parameter injection.
• XPath queries should not contain any meta characters (such as as ' = * ? // or  or similar).
• XSLT expansions should not contain any user input, or if they do, that [you
  should] comprehensively test the existence of the file, and ensure that the files are within the bounds set by the Java 2 Security Policy

Risk Assessment

Failing to validate user input may result in information disclosure and execution of unprivileged code.

Related Vulnerabilities

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

References

\[[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]
\[[OWASP 05|AA. Java References#OWASP 05]\] [Testing for XPath Injection|http://www.owasp.org/index.php/XPath_Injection_Testing_AoC]

• .

Automated Detection

Bibliography

...

Image Added Image Added Image AddedMSC34-J. Prevent XML Injection      49. Miscellaneous (MSC)      MSC36-J. Understand how escape characters are interpreted when String literals are compiled