Internet Explorer Object Caching
Applies To: Windows Server 2003 with SP1
|The Microsoft Windows Server 2003 Internet Explorer Enhanced Security Configuration component (also known as Microsoft Internet Explorer hardening) reduces a server’s vulnerability to attacks from Web content by applying more restrictive Internet Explorer security settings that disable scripts, ActiveX components, and file downloads for resources in the Internet security zone. As a result, many of the security enhancements included in the latest release of Internet Explorer will not be as noticeable in Windows Server 2003 Service Pack 1. For example, the new Internet Explorer Information Bar and Pop-up Blocker features will not be used unless the site is in a zone whose security setting allows scripting. If you are not using the enhanced security configuration on your server, these features will function as they do in Windows XP Service Pack 2.|
What does Object Caching do?
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.
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 Server 2003 Service Pack 1?
None. Existing functionality has been extended.
What existing functionality is changing in Windows Server 2003 Service Pack 1?
Security context is invalidated upon navigation to a different domain
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.
Why is this change important? What threats does it help mitigate?
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.
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 Server 2003 Service Pack 1?
Internet Explorer Object Caching
|Setting name||Location||Previous default value||Default value||Possible values|
HKEY_LOCAL_MACHINE (or Current User)\Software \Microsoft \Internet Explorer\Main \FeatureControl \FEATURE_OBJECT_CACHING
0 - Off
1 - On
Do I need to change my code to work with Windows Server 2003 Service Pack 1?
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.frames.name