Page History

...

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

• Treat all user input as untrusted and perform appropriate sanitization.
• When validating 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 corresponds to input validation. ( See guideline IDS00-J. Always validate user input for additional details.)
• 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 An effective prevention technique for preventing the related issue of SQL injection is parameterization. In this technique, whereby user-specified data is passed directly to an API as a parameter, which ensures that no data specified by the user is thus ensuring that user-specified data is never interpreted as executable logic. Unfortunately, Java SE currently lacks such an interface does not currently exist in Java SE. However, this functionality can be emulated for XPath queries. Emulate SQL parameterization by using an interface (such as XQuery that enables the user to effectively parameterize data by ) that supports specifying a query statement in a separate file , and supplying the query that is supplied at runtime. This compliant solution uses a query specified in a text file by reading it the file in the required format and then entering values for the user name and password in a Map. The XQuery library constructs the XML query is constructed from these elements subsequently.

Input File: login.qry

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 the loginID and password fields is not cannot be interpreted as executable content at runtime.

...

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 Failure to validate user input may result in information disclosure and execution of unprivileged code.

...

\[[Fortify 2008|AA. Bibliography#Fortify 08]\] "Input Validation and Representation: XML Injection"
\[[SenMITRE 20072009|AA. Bibliography#SenBibliography#MITRE 0709]\]
\[[Sun 2006|AA. Bibliography#Sun 06]\] [EnsureCWE DataID Security643|http://javacwe.sunmitre.comorg/developerdata/technicalArticles/xml/jaxp1-3/index.html#Ensure%20Data%20Security]definitions/247.html] "Failure to Sanitize Data within XPath Expressions (aka 'XPath injection')"
\[[OWASP 2005|AA. Bibliography#OWASP 05]\] [Testing for XPath Injection|http://www.owasp.org/index.php/XPath_Injection_Testing_AoC]
\[[MITRE 2009Sen 2007|AA. Bibliography#Sen 07]\]
\[[Sun 2006|AA. Bibliography#MITREBibliography#Sun 0906]\] [CWEEnsure IDData 643Security|http://cwejava.mitre.org/data/definitions/247.html] "Failure to Sanitize Data within XPath Expressions (aka 'XPath injection')"sun.com/developer/technicalArticles/xml/jaxp1-3/index.html#Ensure%20Data%20Security]

...

IDS08-J. Prevent XML Injection      13. Input Validation and Data Sanitization (IDS)      IDS10-J. Prevent XML external entity attacks