When you use MSXML as an ActiveX control inside of Internet Explorer, the default Internet Security Manager controls security for a number of issues based on Internet Explorer’s security settings. You specify these security settings on the Security tab of the Internet Options dialog box, which is found under the Tools menu. For example, you can specify the security associated with specific URLs or classes of URLs. You can specify that certain URLs are trusted and that other URLs are part of your company’s trusted Intranet. You can restrict access to other URLs.
Internet Explorer defines four Web Content Zones for which you can explicitly control security policy: Internet, Local Intranet, Trusted Sites, and Restricted Sites. For each of these Web Content Zones you can control various aspects of security, including whether scripts can be run, whether ActiveX controls can be instantiated, and more. These settings have very specific implications for MSXML.
Note that in Internet Explorer, these zones are called Web Content Zones. In this topic, and in the C++ headers, these zones are called URL Security Zones. Web Content Zones and URL Security Zones are synonyms.
If you are writing an application that uses MSXML and XML technologies, you can implement and use your own security manager. If you do not provide your own security manager, MSXML will use the default Internet Security Manager.
There are several reasons to write your own security manager. For example, you might want to establish the URL Security Zone for MSXML before any documents are loaded. Or, you might want to write a security manager that imposes more granular security restrictions than what is available through the settings in Internet Explorer. You might also want to implement a security manager that has set security policy that cannot be overridden by user settings. For example, you could write a security manager that restricts all external document references to one particular URL and no others.
If you implement and use your own security manager correctly, you might be able to mitigate certain attacks associated with MSXML and XML technologies, and have a more secure application. Before discussing specific attacks and how they can be mitigated, it is important to understand the security considerations associated with some XML features that MSXML supports, such as external document references, ActiveX control instantiation, and scripts.
Referencing External Documents
XML allows documents to refer to other documents. There are three basic scenarios where one document can refer to another document, and if configured to do so, MSXML will automatically load and possibly use the referenced document. These scenarios are as follows:
-
A Document Type Definition (DTD) can refer to external files through external entities.
-
An XSD schema can reference an external schema through the xsd:import or xsd:include elements.
-
An XSLT stylesheet can reference an external XSLT stylesheet through the xsl:import or xsl:include elements.
Furthermore, a Web server that responds to an MSXML HTTP request with an HTTP redirect can cause MSXML to be redirected to another site.
There are two categories of access in which the relationships between the original resource and the referenced resource can compromise security:
-
Cross-domain access occurs when the referenced resource is in a different domain than the original resource.
-
Cross-zone access occurs when the referenced resource is in a different URL Security Zone than the original.
In Internet Explorer, there is no distinction between cross-domain and cross-zone access, but in MSXML there is.
In a cross-domain attack, a document from an untrusted source attempts to load data from another domain that you do not control in the same Zone. In a cross-zone attack a document from an untrusted source attempts to load an XML document that refers to a file in a different (typically more trusted) zone. As an example of the latter, if you loaded a document from a site in the Internet zone, and that document attempted to refer to a document on your company’s Intranet, this would be a cross-zone attack. When you use the Internet Security Manager to screen this data access, the possibility of cross-zone attacks is automatically reduced.
Running Scripts and ActiveX Controls
You can configure user policy, and therefore the Internet Security Manager, in such a way that scripts and ActiveX controls are allowed for one zone but disallowed for another. For example, scripts could be allowed for your company’s Intranet, but not for sites on the Internet.
MSXML contains an XSLT processor that will process an XSLT stylesheet, including scripting elements contained in an <msxsl:script> element. Scripts, in turn, can instantiate ActiveX controls. Because this programming environment is so powerful, applications that load untrusted XML documents (especially untrusted XSLT stylesheets) or untrusted data in Internet Explorer can be vulnerable to attacks. These attacks are mitigated by the security policy enforced by the Internet Security Manager. For example, if you allow scripts in the Intranet Zone, MSXML will allow scripts to be run in an XSL transformation initiated on a site on the Intranet. (Note that you can control this behavior in individual HMTL pages by setting the AllowXsltScript property.) If you disallow scripts in the Internet Zone, MSXML will not allow scripts to be run in an XSL transformation initiated on a site on the Internet (even if you set the flag in your HTML page to allow the XSLT script block). Internet Explorer’s security settings override any flags that are set by the HTML page.
Using MSXML Outside of Internet Explorer
Whether you are using MSXML inside or outside the context of Internet Explorer, MSXML always uses the Internet Security Manager. When you use MSXML within Internet Explorer, certain safety options are set according to the security settings of Internet Explorer. If you use MSXML outside of Internet Explorer, such as in the WScript scripting host, the default security manager is used and the safety options are not set, resulting in a more relaxed security mode. By implementing your own custom security manager you can enable safety options. This increases security. In this way, you can mimic the security model of Internet Explorer, or even apply a stricter model. The implementation details of how to set safety options are described in Creating a Custom Internet Security Manager for MSXML 6.0.
By default, outside the context of Internet Explorer, MSXML will use the default Internet Security Manager to control cross-zone access and the running of scripts in XSLT scenarios. Once you have loaded a document at a particular URL, MSXML determines the zone of the URL and will disallow cross-zone access, and will enforce the script-running policy of that zone.
However, there are two circumstances in which MSXML has not yet determined the URL Zone, and therefore cannot impose security constraints based on the Internet Security Manager:
-
When an application initially loads a document, the Internet Security Manager is not active. For example, you might have an application for which you want to restrict all access to the Internet zone. But if the initial document is located in the Intranet zone, MSXML will load the document. As mentioned above, if the initial document was in the Internet zone, then subsequent references to external documents will be restricted per the security policies of the Internet Security Manager.
-
If a document is first loaded into a string, and subsequently loaded though a call to the IXMLDOMDocument::loadXml method, MSXML has no information about the URL Zone of the string; it is simply a string in memory, so the Internet Security Manager cannot impose security policy.
In these situations, you can implement your own security manager. After you have implemented a security manager, you can make MSXML use it and MSXML will then delegate security decisions to it, including how to resolve references to external documents and how to acquire permissions to run scripts.
To create a custom security manager you have to write your security manager in a language, such as C++, that supports creating COM components.
See Also