Part -1 explained previous attacks and emphasized that the weakly configured XML parsers are enablers for attacks.To be secure against attacks, XML parsers need to be hardened. Hardening is a process where a component is setup in the most minimal and secure configuration required to run the application.
From security stand-point, support needs to be added for XML parser component to validate schema features, Avoid external entity attacks, disallow doctype declarations, avoid resolving of external XML schema locations, limit number of nodes and entity expansions, check XML against local server-side schemas and DTDs.
Any framework or library implementer working to enable secure working with XML, DTD and schemas needs to be aware that most application programmers parsing XML documents are not XML experts. They do not understand the risks of external entities or possibility of attacks during simple parsing of data that happens to be serialized in XML.
Recommended library implementers to minimize the set of advanced XML features made available by default. While advanced features are made available,design shall drive advanced features to be disabled by default. Developers can enable as per need. Make sure to document the risk associated with each feature in library documentation
Programming practices provide different levels of counters against XML based attacks. These attacks differ based on the underlying support available in programming language or framework to counter the attacks. I have taken some .Net programming based counters that can work against the abuse of XML entities and in processing of DTD.
Developers use reader instances Create() method available as part of the implementation of abstract class (XmlReader). One parameters of Create() method is XmlReaderSettings class, used to set properties of the reader instance. It is important to verify that readers or methods have not become obsolete with new versions of .Net Framework (like XmlValidatingReader).
Counter against the abuse of XML entities
XmlReader and its underlying concrete implementations support stream-based reads and relies on the XmlResolver class to resolve external data sources identified by a URL. They provide an abstraction to access data sources on the Internet and files on the file system using default resolver XmlUrlResolver, which supports file, http, and other schemes and also process elements found in XSL stylesheets and XSD schemas.
An attacker may deliver an XML payload to a vulnerable application and subsequently retrieve resources by triggering the resolver to process external entities. A sample attack can be
Whenever the XML parser encounters the entity “&windowsfile;” it will substitute the entity with the content of the file from the local host and then place it in the response. XmlSecureResolver class restricts access to resources based on a set of permissions, to be explicitly declared in developer’s code and assigned to the instantiated object. If permissions are not declared, the behavior is similar to XmlUrlResolver class with unrestricted access to resources. The permissions set can be used to define an access control. For example, one can employ a rule restricting access to particular Internet sites or zones.
Counter against the abuse of DTD Handling
XmlTextReader enables DTD processing by default and resolve references to external resources. In .NET 4.0 framework and later, DTD processing can be influenced using new DtdProcessing property values, which can either be set to : Prohibit, Ignore, or Parse.
- setting to Prohibit and if XML contains <!DOCTYPE> element, there is an XmlException is thrown at runtime
- setting to Ignore causes the DOCTYPE element to be ignored and the XML to be parsed normally afterwards, in which case it will not throw an exception
- Setting to Parse enables DTD processing. If DTD parsing needs to be enabled in the application, then utilize the XmlSecureResolver to restrict resources that an XmlReader can access.
The default settings for the XmlTextReader class is to enable DTD processing using DtdProcessing.Parse while the default settings is to disable processing using DtdProcessing.Prohibit. On processing with XmlTextReader, if the DtdProcessing property is not explicitly set, then the ProhibitDtd can take effect.
Exceptions thrown by XmlTextReader can include path information which can bubble up to the application. Therefore, developers must write their code to catch these exceptions and process them accordingly to avoid information leakage.
NET has feature to limit the size of expanded entities by setting MaxCharactersFromEntities property of XmlReaderSettings object that sets cap on the number of characters generated through the entity expansions.