One of the points I make in training is that security needn't be a 180 degree turn, instead look for ways that you can incrementally make improvements. There are many underutilized tools for securing your system, one of these is schema validation against hardened schemas.
XML can contain any number of beasties from DoS to privilege escalation to any injection family you can name. One of the best defenses against these threats, of course, is validation. The questions with validation is not so much why but how and where?
Schema validation has several advantages - first it uses native XML structures and types. Eventually these will be converted to Java or .Net types but don't you want to validate them first in native form before you convert them and execute? Thought so.
Next, we get very little security without a lot of sweat. It might take awhile to implement an access control system or crypto functionality, but in the case of XML Schema validation we get some interesting security properties for what is basically a for free operation
// Load your schema file & validate against it
SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Source source = new StreamSource(schemaFile);
Schema schema = factory.newSchema(source);
Validator validator = schema.newValidator();
validator.validate(new DOMSource(sourceElement));
}
For a few lines of code, the validator does the validation heavy lifting for us. What kind of things can the validator check for? The XML validator can assist with checking for structural vulnerabilities such as:
Limit character sets
Constrain Encoding: <?xml version="1.0" encoding="utf-8" ?>
Limit field length: <max-length>108</max-length>
Define all data types(eschew type:any): <xs:attribute name=”requestDate" type="xs:date"/>
The XML validator can be used for semantic validation as well
<xs:element name="age">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="18"/>
<xs:maxInclusive value="120"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
There are specific attacks around document size, null characters, element nesting and arrays where the schema may be your only chance to defend against content-based attacks before its too late.
Another advantage of XML Schema Validation is distribution, the same XSD schema file can easily be reused, so if you document traverses an app server, web server and ESB, they can use the same XSD and leverage consistent validation logic. This is a major reuse advantage in a distributed system. The receiving app will still need to do additional validation but validating against a XSD beforehand reduces attack surface, limits the possibility of propagating tainted data, and guards against XML specific vulnerabilities (targeting XML contexts), all for a few lines of code.
That sounds pretty easy, but now what difficult part, did I not mention yet? Well, schema validation is pretty useless if you do it against a wide open schema that, say allows type:any or doesn't set limits.
Thanks to
Dave Wichers, the energizer bunny of the application security space, for motivating me to write this post.
Comments