Internet Explorer Object Caching

Internet Explorer Object Caching

What does Object Caching do?

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

Who does this feature apply to?

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.

What new functionality is added to this feature in Windows XP Service Pack 2?

None. Existing functionality has been extended.

What existing functionality is changing in Windows XP Service Pack 2?

Security context is invalidated upon navigation to a different domain

Detailed description

For Windows XP Service Pack 2, there is now a new security context on all scriptable objects so that access to all cached objects 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.

Why is this change important? What threats does it help mitigate?

Prior to Internet Explorer 5.5, navigations across HTML pages (or to sub-frames) 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.

What works differently? Are there any dependencies?

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.

How do I resolve these issues?

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.

What settings are added or changed in Windows XP Service Pack 2?

Do I need to change my code to work with Windows XP Service Pack 2?

If your application gets Access Denied errors, 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();