Last week I was
fixing issues for my pet project Scribble. I use Sonar for capturing
issues in my code. Since April this year, the Findbugs plugin for
Sonar includes rules for finding security bugs. Two of the bugs found
were related to XML processing using Java's XML APIs for Xpath and
DOM parsing. The security issue themselves were not new, both of them
were discovered some years ago. But to me they were new as I was not
aware of them at all. For my pet project they are not that critical
as it is just a framework for writing tests and no one using that
framework is kept from writing vulnerable code themselves. But for me
it was a good case for studying the issues to avoid them when it
really matters.
Xpath Injection
Xpath injection adheres to the same principle as SQL injection were parameter values that are used in an Xpath expression contain characters that are semantically bound to the Xpath syntax to break out from the path defined by the expression.The Attack
Given, you have an XML document containing sensitive data<technical-users> <user id=”reader”> <privateKey>ABC</privateKey> </user> <user id=”writer”> <privateKey>123</privateKey> </user> </technical-users>and an Xpath expression with a parameter that is filled in at runtime:
//technical-users/user[@id='”+userId+”']/privateKeyLets assume, the attacker has authenticated successfully as reader and now tries to query for the private key, manipulating it's own user id to that value:
reader']/../user[@id='writer
The Defense
The only effective defense is to sanitize the user input! Typically, a regex-pattern could help with allowing only input of a certain pattern, i.e. allowing only alphanumeric characters and within a specific length range (5 to 15 characters):if(!userId.matches([a-zA-Z0-9]{5,15}) {
throw new Exception(“Invalid Input“);
}
If reserved characters should be allowed, you may escape them:String escapedUserId = userId.replaceAll(“'“, “\\'“);
public class SanitizingVariableResolver implements XPathVariableResolver {
//create a map to contain the variable values
private Map<QName, String> variables = new HashMap<>();
//keep a list of all valid patterns
private final List<Pattern> validationPatterns;
//constructor accepting regular expression patterns
public SanitizingVariableResolver(String... regexPatterns){
this.validationPatterns = new ArrayList<>();
for(String regexPattern : regexPatterns) {
this.validationPatterns.add(Pattern.compile(regexPattern));
}
}
//method to add variable value on which the sanity check is applied
public void addVariable(String name, String value) {
for(Pattern pattern : validationPatterns){
if(pattern.matcher(value).matches()){
variables.put(new QName(name), value);
return;
}
}
//don't accept invalid values
throw new IllegalArgumentException("The value '" + value + "' is not
allowed for a variable" );
}
@Override
public Object resolveVariable(QName variableName) {
return this.variables.get(variableName);
}
}
Next, you'll have to apply this resolver to your Xpath instance
and use an Xpath expression with a variable placeholder://create new xpath instance
final XPath xp = XPathFactory.newInstance().newXPath();
//instantiate the resolver with an alpahnumeric pattern
final SanitizingVariableResolver resolver =
new SanitizingVariableResolver("[a-zA-Z0-9]{4,15}");
//add the user id value
resolver.addVariable("userId", userId);
//assign the resolver to the xpath instance
xp.setXPathVariableResolver(resolver);
//apply the xpath expression with variable
xp.evaluate("//technical-users/user[@id=$userId]/privateKey",source);
An alternative to sanitizing the input yourself, you may use alternative libraries such as Xquery that provides an abstraction layer on top of the Xpath API that provides means to sanitize parameter input.
References
-
OWASP:
Top 10 2013-A1-Injection
-
CWE-643:
Improper Neutralization of Data within XPath Expressions ('XPath
Injection')
-
CERT:
IDS09-J. Prevent XPath Injection (archive)
-
Black
Hat Europe 2012: Hacking XPath 2.0
-
Balisage:
XQuery Injection
XML External Entity (XXE)
XML document have to be well-formed and may be validated. For validation, there are two options for declaring a structure against which the document is validated: Doctype Definition (DTD) or XML Schema. A DTD may be embedded in the document itself. For XML the concepts of entities exist to describe characters or values that are parsed and replaced by the XML processor. A common example is the &-entity for describing an ampersand character ('&') because the '&' is a reserved character in Xml. Within a DTD custom entities can be declared. Values for those entities could be characters but also the content external resources indicated by an URI.The Attack
In an XXE atttack, the attacker sends a perpared XML file containing a malicious entity. The entity points to an external resource containing a secret, i.e. /etc/passwd. Depending on what the service actually does, the attacker may easily read the secret from the parsed document.A prepared XML document may be
<?xml version="1.0"?>
<!DOCTYPE document [
<!-- placeholder for the attacked file url -->
<!ENTITY xxe SYSTEM "/etc/passwd" >
]>
<document>
<!-- the external entity is replaced with the injected value -->>
<property>&xxe;</property>
</document>
When being processed by DocumentBuilder, the &xxe; is
resolved to the content of /etc/passwd and accessible as text content
of the The Defense
There are several options to fix this vulnerability. Probably the easiest one is to use XML-Schemas only for XML validation and disable the Doctype Declaration feature by setting the DocumentBuilderFactory Feature http://apache.org/xml/features/disallow-doctype-decl to true:DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
f.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
This feature however is only supported by Xerces2. If you're on Xerces 1 or you can not disable Doctype declaration, you could disable the features
Xerces 1
http://xerces.apache.org/xerces-j/features.html#external-general-entities
http://xerces.apache.org/xerces-j/features.html#external-parameter-entities
Xerces 2
http://xerces.apache.org/xerces2-j/features.html#external-general-entities
http://xerces.apache.org/xerces2-j/features.html#external-parameter-entities
Sax in general
http://xml.org/sax/features/external-general-entities
http://xml.org/sax/features/external-parameter-entities
and set on the DocumentBuilderFactory the flags
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);Oracle proposes two alternative approaches. The first is to perform the parse operation in a privileged context with a no-permission ProtectionDomain where the java security policy is effective, preventing access to restricted system files. The second is to use an EntityResolver and allow only entities that match a certain pattern.
Further attacks against DTD, Schema and Entities and how to defend against are discussed in XML "Schema, DTD, and Entity Attacks"(pdf).
References
-
CWE-611:
Improper Restriction of XML External Entity Reference ('XXE')
-
CERT:
IDS10-J. Prevent XML external entity attacks
-
OWASP.org:
XML External Entity (XXE) Processing
-
WS-Attacks.org:
XML Entity Expansion
-
WS-Attacks.org:
XML External Entity DOS
-
WS-Attacks.org:
XML Entity Reference Attack
-
Xerces2
complete features list
All examples, including JUnit tests that can be used as template to tests your own code can be found on https://github.com/gmuecke/whoopdicity/tree/master/examples
