XmlLite Security
This topic describes security issues associated with XmlLite. In addition, it provides some guidance for mitigating security exposure.
Security Issues
The security issues in this topic are not presented in any particular order. All topics are important, and should be addressed.
Entities in DTDs Pose a Denial of Services Threat
XML documents may contain Document Type Definitions (DTDs) that can declare general entities that reference other files and URLs. Such entities—and therefore content of the other files and URLs—will be included in the document.
Entities in DTDs pose a serious threat in the form of a potential Denial of Service (DoS) attack on the servers that are using XML parsers. Prohibiting DTDs is one way of mitigating potential denial of service attacks. If the XmlReaderProperty_DtdProcessing property is set to DtdProcessing_Prohibit, IXmlReader will return an error when a DTD is encountered. The reader will move to an error state and no further parsing will be performed. DTDs are prohibited by default.
Another approach for mitigating this threat is to set the XmlReaderProperty_MaxEntityExpansion property. This property has a default value of 100,000. If this is not a large enough limit, you can increase this limit to a value that is suitable to your application.
If you are using DTDs, you should ensure that the DTDs referenced by the XML are loaded from trusted locations, and that the transport between the trusted location and the XmlLite reader is secure.
Implement IXmlResolver Correctly
XML can be vulnerable to cross domain and cross zone attacks, in particular with entity resolution. By default, XmlLite does not resolve external entities. When external entities are not resolved, you are not vulnerable to these types of attacks.
However, you can supply your own class that implements the IXmlResolver interface. When you do so, you should develop your implementation in such a way that cross-domain and cross-zone attacks are avoided. All cross-domain and cross-zone checking must be implemented in the user-supplied entity resolver. User-supplied resolvers should set the base URI as appropriate to ensure that relative URIs for external entities are resolved correctly. Note that XmlLite itself does not use the base URI in any way. It just passes it along to the resolver. The resolving only happens in the user-supplied resolver.
If, instead of writing your own IXmlResolver, you use an existing implementation, it should come from a trusted source.
For an example of how to write an entity resolver, see Reading an XML Document That Resolves External Entities shows. This example entity resolver does not resolve to external URIs. Instead, it shows how to resolve an entity named date to the current date.
Avoid Buffer Overruns
In general, when you pass a string as an argument to a function you do not supply the length of the string. In these cases, it is important that the string be null-terminated. For a small number of functions, such as WriteRaw and WriteRawChars, a length is also passed as an argument to the method. In these cases, the string does not have to be null-terminated.
Handle Very Large Documents Correctly
Long names, large values in spans of text, and large attribute values create memory allocation issues. Without proper mitigation, documents with these characteristics are a threat for denial of service denial of service threats. There are four approaches to mitigation:
You can implement a custom
IMallocimplementation. This implementation could limit allocation of memory to a predetermined specific amount. If you use anIMallocimplementation from another source, use only an implementation from a trustworthy source. For an example of a limitingIMallocimplementation, see Reading an XML Document Using a Limiting IMalloc Implementation.You can set XmlReaderProperty_RandomAccess to
TRUE, which can reduce memory usage. To use this feature, you must supply anIStreamimplementation that implements theSeekmethod.Seekenables random access.You can use the chunking programming interface. This allows you to read entity and attribute values in smaller chunks. For more information about chunking, see Read an Xml Document Using Chunking.
You can set up the application environment to limit the amount of memory that the thread can consume.
Limit the Depth of the XML Hierarchy
One possible denial of service attack is when a document is submitted that has excessive depth of hierarchy. If you accept untrusted documents, you can mitigate this attack by limiting the depth of hierarchy. You can limit the depth by setting the XmlReaderProperty_MaxElementDepth property. By default, XmlReaderProperty_MaxElementDepth is set to 256.
Avoid Denial of Service Attacks when You Use Long Names
Excessively long names can constitute a denial of service attack. If you are parsing untrusted documents, you can mitigate this attack in one of the following ways:
You can provide your own custom
IMallocimplementation, and limit memory usage in it.You can set up the application environment to limit the amount of memory that the thread can consume.