DOM Security

This topic describes security issues associated with MSXML Document Object Model (DOM). In addition, it provides some guidance for mitigating security exposure.

Security Issues

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

There is overlap between this topic and the security topic for SAX. This is because many issues have more to do with XML, and less to do with the specific implementation (DOM or SAX).

Properties that Have Security Implications

The following list provides a short description of the security implications associated with certain DOM properties. This list might not be complete.

DTDs Are Not Secure

Entities in DTDs are inherently not secure. It is possible for a malicious XML document that contains a DTD to cause the parser to use all memory and CPU time, causing a denial of service attack. Therefore, DTD processing is turned off by default. You should not accept DTDs from untrusted sources.

An example of accepting DTDs from untrusted sources would be a Web application that allowed Web users to upload an XML file that references a DTD and a DTD file. Upon validation of the file, a malicious DTD could execute a denial of service attack on your server. Another example of accepting DTDs from untrusted sources would be to reference a DTD on a network share that also allows anonymous FTP access.

DTDs are enabled by default in MSXML 3.0 for backward compatibility. However, DTDs are disabled by default in MSXML 6.0. If you do not want to allow DTDs and you are using MSXML 3.0, you should turn off DTD processing by setting the ProhibitDTD Property to true.

If you know that all documents referencing DTDs come from secure sites, then you can allow DTD processing by setting the ProhibitDTD property to false. Following is the code in JScript that you would use to allow/disallow the use of DTDs:

To allow DTDs (in JScript):

doc.setProperty("ProhibitDTD", false);  

To disallow DTDs:

doc.setProperty("ProhibitDTD", true);  

If you attempt to load an XML document that contains a DTD while this property is set to true, you will receive an error: "Invalid at top level of the document".

Schemas Should Not Be Loaded from Untrusted Sources

There are a number of denial of service attacks associated with compiling and validating XML schemas. Users should not accept schemas from untrusted sources if denial of service is a concern.

External schemas (including DTD) are allowed and processed by default in MSXML 3.0. External schemas are not processed in MSXML 6.0 by default; you must explicitly enable them. If you are using MSXML 6.0, all of your XML documents come from a secure site, and you want to allow external schemas, you can do so by setting the resolveExternals Property to true. If you are using MSXML 3.0 and your XML documents do not come from a secure site, you can operate in a safer mode by setting the resolveExternals Property to false.

To allow external schemas (in JScript):

doc.resolveExternals = true;  

To disallow external schemas:

doc.resolveExternals = false;  

Inline Schemas Are Not Secure

If you accept documents from an untrusted source, it is not possible to prevent denial of service attacks when allowing inline schemas. Like other schemas from untrusted sources, inline schemas allow an untrusted user to change the logic that is used when validating their data.

Inline schemas are not supported in MSXML 3.0. They are supported but disabled by default in MSXML 6.0.

If you are using MSXML 6.0 and you know that all of your documents come from a secure source, you can allow inline schemas by setting the UseInlineSchema property to true.

The following is the Jscript code to allow inline schemas:

doc.setProperty("UseInlineSchema", true);  

To disallow inline schemas:

doc.setProperty("UseInlineSchema", false);  

Avoiding Cross-Zone and Cross-Domain Attacks

If you accept documents from insecure sites and you want to load external documents (using xsi:schemaLocations in the case of instance documents, and xs:imports and xs:includes in the case of schema documents), and if you are writing your application in C++, then you should set the SchemaCache site. The Site object determines the permissions of accessing externals within the document. This will mitigate cross-zone or cross-domain attacks. A cross-zone or cross-domain attack is when a document from a less trusted source references documents from a more trusted source.

For example, if an XML document is uploaded to your application, if your application has resolveExternals set to true, and if you do not have the Site object set, then that document could attempt to load or include a schema from your local machine. This type of attack may result in denial of service, information disclosure from the protected resource, or data tampering.

Setting the site requires a significant amount of code, and is possible only from C++ applications. It is not possible from scripting or Visual Basic applications that do not run inside Internet Explorer. Applications written in scripting languages, including Visual Basic for Applications (VBA) applications running in Office, should not allow loading of external documents. If external documents are allowed while using a scripting language, there is the possibility of cross-zone and cross-domain attacks.

Error Messages May Reveal Data

The description of an error may reveal data such as the data being transformed. Errors may also reveal file names. Error messages should not be exposed to callers that are not trusted. You should catch all errors and report errors with your own custom error messages.

Avoid Excessive Buffer Allocation

If a malicious user submits or uploads a very large XML document, it could cause MSXML to consume excessive system resources. This might be a denial of service attack. To prevent this, you can set the MaxXMLSize property to a reasonable value for the application's expected operations, which will limit the size of an XML document to be loaded into a DOM object. A zero (0) value means no limits. A non-zero value specifies the maximum size of the XML text file or stream, in multiples of 1024 characters. The default value of MaxXMLSize is unlimited.

For example, if you know that the maximum expected size of your XML documents coming from an untrusted source will be less than 50K bytes, set MaxXMLSize to 100. This will not encumber your processing of XML documents, and at the same time it will mitigate denial of service threats where documents might be uploaded that would consume large amounts of memory.

The following JScript code sets MaxXMLSize:

doc.setProperty("MaxXMLSize", 100);  

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. The MaxElementDepth property mitigates this threat. The default value for this property is 256. If you are concerned about denial of service, you should set this property to a value that allows you to load your documents yet limits depth to a reasonable level. It is not recommended that this property be set to 0, which removes the limit. Failure to limit the depth of hierarchy leaves you open to an attack in which a relatively small XML document can cause a denial of service.

The following JSCript code sets MaxElementDepth:

doc.setProperty("MaxElementDepth", 500);  

The MaxElementDepth Property is supported for MSXML 6.0.

Validate Carefully Before Constructing Dynamic XPath Statements

If you allow XPath expressions from an untrusted source, such as user input, it is possible that users can enter an expression that is too complex, and results in a denial of service.

Instead, you should allow the user to enter appropriate selection criteria, and then validate the selection criteria carefully. One approach is to make sure that, as appropriate, you allow the user to enter only alphanumeric characters. You would specifically disallow all special characters that are part of the XPath expression syntax, such as brackets, quotation marks, the equals sign, and so on. After you have validated that no special characters are part of the user input, you can formulate an XPath expression.

One possible scenario is as follows:

You have an XML document that contains a number of complex entities. Each entity describes a book:

<catalog>  
   <book id="bk101">  
      <author>Gambardella, Matthew</author>  
      <title>XML Developer's Guide</title>  
      <genre>Computer</genre>  
      <price>44.95</price>  
      <publish_date>2000-10-01</publish_date>  
      <description>An in-depth look at creating applications   
      with XML.</description>  
   </book>  
   <book id="bk102">  
      <author>Ralls, Kim</author>  
      <title>Midnight Rain</title>  
      <genre>Fantasy</genre>  
      <price>5.95</price>  
      <publish_date>2000-12-16</publish_date>  
      <description>A former architect battles corporate zombies,   
      an evil sorceress, and her own childhood to become queen   
      of the world.</description>  
   </book>  
</catalog>  

If you allow the user to enter a book ID, and the user enters 'bk101', you can formulate an expression as follows:

"//catalog/book[@id='bk101']"  

After formulating the expression, you can call the selectNodes method method. The following is the JScript code to do this:

objNodeList =  
    xmlDoc.documentElement.selectNodes("//catalog/book[@id='bk101']");  

Before formulating the expression, you make sure that the data the user entered contains only alphanumeric characters. If the user entered anything other than alphanumeric characters, you report an error back to the user, and you do not formulate and execute the XPath expression.

Strictness in MSXML 6.0 May Prevent Some Applications from Working

Internet Explorer defines four zones - Trusted sites, Local intranet, Internet, and Restricted sites. There are a number of rules regarding how a site in one zone can reference a site in another zone. For example, a site on the Internet cannot reference a document on the Local intranet. In Internet Explorer, and for applications that set the site explicitly, MSXML 6.0 is strict about URL redirection, and may prevent some user scenarios. To work around the security restrictions, the user can add the machine doing the redirection to the list of trusted sites on the computer where the redirection is taking place.

Limit Processing Time when Downloading

Certain scenarios exist where a denial of service attack consumes all available CPU time. If you are downloading untrusted documents, you can set timeout limits for four settings: resolveTimeout, connectTimeout, sendTimeout, receiveTimeout. If you set these settings, a denial of service attack that consumes all available CPU time will trigger these timeouts and will fail. See the setTimeouts method for more information.

See Also

MSXML Security Overview