XmlLite Security

This topic describes security issues associated with XmlLite. In addition, it provides some guidance for mitigating security exposure.

The security issues in this topic are not presented in any particular order. All topics are important, and should be addressed.

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.

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 While Resolving 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.

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.

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 IMalloc implementation. This implementation could limit allocation of memory to a predetermined specific amount. If you use an IMalloc implementation from another source, use only an implementation from a trustworthy source. For an example of a limiting IMalloc implementation, 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 an IStream implementation that implements the Seek method. Seek enables 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 Reading an XML Document Using Chunking.

  • You can set up the application environment to limit the amount of memory that the thread can consume.

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.

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 IMalloc implementation, and limit memory usage in it.

  • You can set up the application environment to limit the amount of memory that the thread can consume.

Show:
© 2014 Microsoft