Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

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

...

In this noncompliant code example, a user name and password is read from the user and used to construct the query string. The evaluate function call returns a set of all nodes in the XML file, causing the login function to return true and bypassing bypass any authorization.

Code Block
bgColor#FFcccc
class 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);
  }
}

...

  • Treat all user input as untrusted
  • When validating user input, verify 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 corresponds to input validation (IDS00-J. Always validate user input).
  • In a client-server application, perform validation at both the client and the server side
  • Extensively test applications that supply, propagate or use user input

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 that no data specified by the user is interpreted as executable logic. Unfortunately, such an interface does not currently exist in Java SE. However, this functionality can be emulated by using an interface such as XQuery which that enables the user to effectively parameterize data by 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 subsequently.

...

Code Block
declare variable $loginID as xs:string external;
declare variable $password as xs:string external;//users/user[@loginID=
$loginID and @password=$password]
Code Block
bgColor#ccccff

Document doc = new Builder().build("users.xml");
XQuery xquery = new XQueryFactory().createXQuery(new File("login.xry"));

Map queryVars= new HashMap();

queryVars.put("loginid", "Utah"); // userUser name hardcoded for illustrative purposes
queryVars.put("password", "securecoding"); // passwordPassword hardcoded for illustrative purposes 

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

for (int i = 0; i < results.size(); i++) {
  System.out.println(results.get(i).toXML());
}

...

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

Wiki Markup
\[Prevention of XPath injection\] requires the following characters to be removed (ie prohibited) or properly escaped:

  • < > / ' = " to prevent straight parameter injection
  • XPath queries should not contain any meta characters (such as ' = * ? // or similar)
  • XSLT expansions should not contain any user input, or if they do, that you
    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.

...