MSXML Security Overview

Artigo
10/27/2016

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

Overview

MSXML 6.0 introduces a number of security-oriented enhancements. These enhancements, when combined with recommended practices, can significantly reduce your security exposure. For all new applications, you are encouraged to code against MSXML 6.0.

There are a number of issues to understand when securing your MSXML application:

Adequate security education is vital. Consider taking a security training class; there are a number of organizations that offer them. The book "Writing Secure Code" by Michael Howard and David LeBlanc, published by Microsoft Press, provides a great deal of information regarding securing your applications.
The issues associated with security are constantly evolving. The best practices at the time this topic was written may be outdated in the future. Building a secure MSXML application requires that you are up to date with the latest in security techniques. Read current books, research current security issues on the Internet and on the Microsoft Website, and continue your security education.
Security must be designed into your application. This process includes an analysis of your application with security in mind to identify threat targets. After identifying them, you must categorize them, rank their seriousness, and map how the threats can be exploited. Your analysis of your application cannot be considered complete until you have developed appropriate threat models. There are many resources (books, Websites, and courses) that can train you to develop appropriate threat models. One place to start is a whitepaper on the Security Development Lifecycle: https://msdn.microsoft.com/security/sdl.
After you have developed your threat models, you can then design your mitigation plans. With MSXML, sometimes mitigation means not using certain features of XML, such as DTDs or inline schemas. Other times, mitigation requires that you code your application in certain ways. For example, you should be careful when exposing MSXML error messages to untrusted users. Error messages reported from MSXML may contain information that you do not want possibly hostile users to know. Instead, when an MSXML error is generated, you should put up your own error message that does not contain the message generated from MSXML. Another example is that it is a security hole to directly pass user input that has not been validated as part of an XPath expression; attackers could possibly see parts of the XML document that they are not authorized to see. Mitigate this threat by ensuring that all user input is validated.

This document provides information that is best used in the context of a comprehensive security plan. It provides mitigation advice for specific threats related to MSXML. However, there are other types of threats, including threats that are not associated with MSXML, that this document does not address. Securing the parts of your application that work with MSXML will certainly help, but if your application is insecure in other areas, you will still be vulnerable. Therefore, it is crucial for you to have a comprehensive security plan.

This overview provides some information about the types of threats associated with MSXML, along with the appropriate mitigation. There is also a security section included with the documentation for each of the subsystems (DOM, SAX, XSD, XSLT, and Helper APIs). These topics provide detailed information about the security threats in these subsystems, along with appropriate mitigation.

Security Enhancements in MSXML 6.0

The enhancements to MSXML 6.0 fall into two categories:

Microsoft has made certain enhancements to MSXML that remove some security risks. There is nothing specific that you need to do (other than moving to MSXML 6.0) in order to take advantage of these enhancements.
Some parts of XML (such as DTDs and inline schemas) are inherently risky. In the default installation configuration of MSXML 6.0, these features have been disabled. You are free to enable these features, but first you should ensure that the security risks associated with them do not apply to you.

If you attempt to load a DTD without explicitly enabling ProhibitDTD Property, you will receive the following error:

error: DTD is prohibited.

Threats and Mitigation

This section introduces three types of threats and their mitigation, so that you can get a sense of the types of threats and how to minimize them. For a detailed list of attacks and mitigation, see the security section for each of the MSXML subsystems (DOM, SAX, XSD, XSLT, and Helper APIs).

DTDs Are Insecure

Entities in DTDs are inherently insecure. 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 (DoS) attack. Therefore, DTD processing is disabled by default in both DOM and SAX. You should not accept DTDs from untrusted sources. For information about protecting the sources of your DTDs, see DOM Security and SAX2 Security.

Inline Schemas Are Insecure

If you accept documents from an untrusted source, it is not possible to prevent denial of service attacks when allowing inline schemas. For a more secure configuration, the application should not allow the use of inline schemas. For information about disallowing inline schemas, see DOM Security and SAX2 Security.

Exception Messages Can Reveal Data

Exception messages from your application can reveal a lot about how your application works. For example, the description of an exception may reveal data such as the data being transformed. Exceptions can also reveal file names. Exception messages should not be exposed to callers that are not trusted. Catch all errors and report errors with your own custom error messages.

Compartilhar via