2023-03-07 17:16:47 +01:00

61 lines
2.0 KiB
Plaintext

== How to fix it in Java SE
=== Code examples
The following noncompliant code is vulnerable to XPath injections because untrusted data is
concatenated to an XPath query without prior validation.
==== Noncompliant code example
[source,java,diff-id=1,diff-type=noncompliant]
----
public boolean authenticate(HttpServletRequest req, XPath xpath, Document doc) throws XPathExpressionException {
String user = request.getParameter("user");
String pass = request.getParameter("pass");
String expression = "/users/user[@name='" + user + "' and @pass='" + pass + "']";
return (boolean)xpath.evaluate(expression, doc, XPathConstants.BOOLEAN);
}
----
==== Compliant solution
[source,java,diff-id=1,diff-type=compliant]
----
public boolean authenticate(HttpServletRequest req, XPath xpath, Document doc) throws XPathExpressionException {
String user = request.getParameter("user");
String pass = request.getParameter("pass");
String expression = "/users/user[@name=$user and @pass=$pass]";
xpath.setXPathVariableResolver(v -> {
switch (v.getLocalPart()) {
case "user":
return user;
case "pass":
return pass;
default:
throw new IllegalArgumentException();
}
});
return (boolean)xpath.evaluate(expression, doc, XPathConstants.BOOLEAN);
}
----
=== How does this work?
As a rule of thumb, the best approach to protect against injections is to
systematically ensure that untrusted data cannot break out of the initially
intended logic.
include::../../common/fix/parameterized-queries.adoc[]
In the example, a parameterized XPath query is created, and an `XPathVariableResolver` is used to securely insert untrusted data into the query, similar to parameterized SQL queries.
include::../../common/fix/validation.adoc[]
For Java, OWASP's Enterprise Security API offers https://www.javadoc.io/doc/org.owasp.esapi/esapi/latest/org/owasp/esapi/Encoder.html#encodeForXPath-java.lang.String-[`encodeForXPath`] which sanitizes metacharacters automatically.