Internet Explorer Object Caching

Applies To: Windows Server 2003 with SP1

In previous versions of Windows Server 2003 with Internet Explorer, some Web pages could access objects cached from another Web site. In Windows Server 2003 Service Pack 1, a reference to an object is no longer accessible when the user navigates to a new domain.

Web developers should review this feature and plan to adopt changes to their Web site.

Application developers should review this feature and plan to adopt changes in their applications.

None. Existing functionality has been extended.

For Windows Server 2003 Service Pack 1, there is now a new security context on all scriptable objects so that access to cached objects (except for ActiveX controls) is blocked. In addition to blocking access when navigating across domains, access is also blocked when navigating within the same domain. (In this context, a domain is defined as a fully qualified domain name, or FQDN.) A reference to an object is no longer accessible after the context has changed due to navigation.

Prior to Internet Explorer 5.5, navigations across HTML pages (or to subframes) purged instances of MSHTML, which is the Microsoft HTML parsing and rendering engine. With the Internet Explorer 5.5 Native Frames architecture, an instance of MSHTML lives across navigations. This introduced a new class of vulnerabilities, because objects could be cached across navigations. If an object can be cached and provide access to the contents of a Web page from another domain, there is a cross-domain hole.

Once you can get to properties on the inner document, script outside of a page’s domain can access the contents of an inner page. This is a violation of the Internet Explorer cross-domain security model.

For example, you can use this method to create scripts that listen to events or content in another frame, such as credit card numbers or other sensitive data that is typed in the other frame.

In those few classes that don’t already have them, four more bytes are added for the cached markup. There should be no noticeable impact on speed.

For most of these classes of vulnerabilities, Internet Explorer 5 would have crashed, so the application compatibility risk of resolving the exploit should be small. Other applications might need to be addressed on a case by case basis.

If your application is attempting to use a cached object, you might encounter Access Denied errors. In this instance you must recache the object before you access it using a script.

In the following example, the security context is invalidated when the designMode property is set on a document object.

Broken script example

    var d = myFrame.document;
    d.designMode = "On";
    d.open();  <-------------------------causes permission denied error

Fixed script example

    var d = myFrame.document;
    d.designMode = "On";
    d = myFrame.document;   // re-establish pointer to document object.
    d.open();

Also, when you compare the values of the two frame.frames properties of an object, the results may be incorrect, or the values may not be retained. This is because the frames object is now wrapped with a security wrapper. When the object caching feature is enabled, this security wrapper is applied. Therefore, access to all cached objects is blocked. This can cause the frames object comparison to return false even though the frames are equal. To resolve this problem, you can use the following method to compare the value of the frames:

a.name == parent.frames[1].frames.name