Exportar (0) Imprimir
Expandir Tudo
EN
Este conteúdo não está disponível em seu idioma, mas aqui está a versão em inglês.

Part 5: Enhanced Browsing Security

Published: August 09, 2004 | Updated: September 15, 2004
By Starr Andersen, Technical Writer; Vincent Abella, Technical Editor

This document is Part 5 of “Changes to Functionality in Microsoft® Windows® XP Service Pack 2,” and provides detailed information about the technologies included in Windows XP Service Pack 2 that help to make Web browsing safer. These technologies are designed to help to provide improved security when compared to previous versions of Internet Explorer. You can obtain the other parts of the paper in the Microsoft Download Center, at http://go.microsoft.com/fwlink/?LinkId=28022.

This document applies to Microsoft Windows XP Service Pack 2 (SP2) for the 32-bit versions of Windows XP Professional and Windows XP Home Edition. It does not describe all of the changes that are included in the service pack, but instead highlights those changes that will have the most impact on your use of Windows XP SP2 and provides references to additional information that may be available.

Bb457150.3squares(en-us,TechNet.10).gif
On This Page

Download, Attachment, and Authenticode Enhancements
Internet Explorer Add-on Management and Crash Detection
Internet Explorer Binary Behaviors Security Setting
Do I need to change my code to work with Windows XP Service Pack 2?
Internet Explorer BindToObject Mitigation
Internet Explorer Information Bar
Internet Explorer Using Feature Control Registry Settings with Security Zone Settings
Internet Explorer Feature Control Settings in Group Policy
Internet Explorer UrlAction Security Settings in Group Policy
Internet Explorer Local Machine Zone Lockdown
Internet Explorer MIME Handling Enforcement
Internet Explorer Object Caching
Internet Explorer Pop-up Blocker
Internet Explorer Untrusted Publishers Mitigations
Internet Explorer Window Restrictions
Internet Explorer Zone Elevation Blocks
Internet Explorer Network Protocol Lockdown

Download, Attachment, and Authenticode Enhancements

What do the download, attachment and Authenticode enhancements do?

In Windows XP Service Pack 2, the prompts that are used for file downloads, mail attachments, shell process execution, and program installation have been modified to be more consistent and clearer than they were in Service Pack 1 for Windows XP.  In addition, the publisher information will be shown before a file type that is signable and can potentially harm the user’s machine is opened. (Common examples of signable file types that can potentially harm the user’s machine are .exe, .dll, .ocx, .msi, and .cab.)

There is a new application programming interface (API) which allows application developers to make use of this new user interface. For more information regarding the API, see “AES API Integration”, in the section of this document on changes to e-mail features in Windows XP Service Pack 2.

Who does this feature apply to?

Application developers will be able to call the new Attachment Execution Service (AES) dialog box from their Windows applications by using the API that is described in “AES API Integration,” earlier in this document.

Application developers should also be aware that, in certain scenarios, such as attempting to open an attachment or downloading a file that is potentially dangerous, file types that can potentially harm a user’s computer will have their digital signatures checked before they are opened. The signature information is presented to the user to help inform them of the file’s publisher.

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

Internet Explorer File Download Prompt

Detailed description

When a user uses Internet Explorer to download a file, the dialog box that appears has the following changes:

  • A file handler icon has been added.

  • A new information area has been added to the bottom of the dialog box that provides slightly different information, depending on whether the downloaded file type is of higher or lower risk.

All file types that are signable and that can potentially harm a user’s computer are checked for publisher information. This information will be shown to the user before opening the file.

The publisher information is shown before opening a file type that is signable and that can potentially harm the user’s computer. The Authenticode dialog box presents this information to the user, who can then make a more informed decision about running the file.

Why is this change important?

This change helps bring consistency and clarity to the experience of downloading files and code to a user’s computer. The publisher check provides crucial information when a signature is found in a file and provides a systematic way to prevent files that are from suspicious publishers from compromising the security of a computer.

What works differently?

Files with blocked publishers are not allowed to run.

How do I resolve these issues?

You can unblock a publisher of an add-on by using Manage Add-ons in Internet Explorer. To unblock a publisher to enable the download of a specific file, you can remove the publisher from the Untrusted Publishers list. To do this, in Internet Explorer, on the Tools menu, click Options, click the Content tab, and then remove the publisher’s name from the Untrusted Publishers list.

Outlook Express E-mail Attachment Prompt

Detailed description

The Outlook Express e-mail attachment prompt uses the same procedures as file downloads. E-mail attachments in Outlook Express show the publisher information for files types that can potentially harm a user’s computer, and any file whose publisher has been blocked will not be allowed to run.

Why is this change important?

This change helps bring consistency and clarity to the experience of downloading files and code to a user’s computer. The publisher check provides crucial information when a signature is found and provides a systematic way to prevent files that are from suspicious publishers from compromising the security of a computer.

What works differently? Are there any dependencies?

Files that have a blocked publisher will not be allowed to run.

How do I resolve these issues?

You can unblock a publisher of an add-on by using Manage Add-ons in Internet Explorer. If you want to unblock a publisher to enable the download of a specific file, you can remove the publisher from the Untrusted Publishers list. To do this, in Internet Explorer, on the Tools menu, click Options, click the Content tab, and then remove the publisher’s name from the Untrusted Publishers list.

Add-on Install Prompt

Detailed description

The Internet Explorer add-on install prompt has been simplified and only displays the file name and publisher information from the digital signature. It provides a warning about the risk associated with installing the add-on in order to help the user make a good decision about installing the add-on. Also, additional functionality was added to the prompt so that users always block a publisher, indicating that Windows XP should never trust anything from the publisher. This blocks the publisher from running code on the computer.

Why is this change important?

This change helps bring consistency and clarity to the experience of downloading files and code to a user’s computer. In addition, the user can choose not to trust a publisher when the user is prompted to install the add-on. This gives users more control over their experience.

What works differently? Are there any dependencies?

When you install an add-on, the user interface is more clear and concise.

How do I resolve these issues?

By default, Internet Explorer will not allow users to run invalid or unsigned ActiveX controls. The Information Bar will provide an alternative way for the user to choose to install a blocked control. For more information about the Internet Explorer Information Bar, see the information later in this document.

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

Users now have the ability to block a publisher from running code on their machine.

Internet Explorer Add-on Management and Crash Detection

What does Internet Explorer Add-on Management and Crash Detection do?

These are two new, closely-related features that are included in Internet Explorer.

Internet Explorer Add-on Management allows users to view and control the list of add-ons that can be loaded by Internet Explorer with more detailed control than before. It also shows the presence of some add-ons that were previously not shown and could be very difficult to detect.

Internet Explorer Add-on Crash Detection attempts to detect crashes in Internet Explorer that are related to an add-on. When the add-on is successfully identified, this information is presented to the user. The user has the option of disabling add-ons to diagnose crashes and improve the overall stability of Internet Explorer.

Who does this feature apply to?

Users will be able to view, enable, and disable the add-ons used by Internet Explorer, and identify add-ons that might be related to Internet Explorer crashes. Administrators can enforce a list of add-ons that are allowed or disallowed and restrict the ability of users to manage add-ons.

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

Internet Explorer Add-on Management

Detailed description

Internet Explorer Add-on Management allows users to view and control the list of add-ons that can be loaded by Internet Explorer with more detailed control than before. It also shows the presence of some add-ons that were previously not shown and could be very difficult to detect. These add-ons might provide undesired functionality or services and, in some cases, might present a security risk.

For example, a user might unintentionally install an add-on that secretly records all Web page activity and reports it to a central server. Previously, specialized software and deep technical knowledge might have been required to identify and remove that add-on. Internet Explorer Add-on Management provides an easier way to detect and disable that add-on.

Add-ons include:

  • Browser help objects

  • ActiveX controls

  • Toolbar extensions

  • Browser extensions

Add-ons can be installed from a variety of locations and in several ways, including:

  • Download and installation while viewing Web pages.

  • Installation by the user by way of an executable program.

  • As pre-installed components of the operating system.

  • As pre-installed add-ons that come with the operating system.

Manage Add-ons

Users can enable and disable each add-on individually and view information about how often the add-ons have been used by Internet Explorer. To do this, use the following procedure to open Manage Add-ons.

  1. Click Start, and then click Internet Explorer.

  2. Click Tools, and then click Manage Add-ons.

You can also open Manage Add-ons through Control Panel by following these steps:

  1. Click Start, and then click Control Panel.

  2. Double-click Internet Options.

  3. Click the Programs tab, and then click Manage Add-ons.

Manage Add-ons has several options that allow you to change your add-on configuration.

You can use Show to control the way in which the add-ons list is displayed. It has two options:

  • Add-ons currently loaded in Internet Explorer. This option lists the add-ons that have been instantiated (or loaded into memory) within the current Internet Explorer process and those which have been blocked from instantiating. This includes ActiveX controls that were used by Web pages that were previously viewed within the current process.

  • Add-ons that have been used by Internet Explorer. This option lists all add-ons that have been referenced by Internet Explorer and are still installed.

The list of add-ons shows all installed add-ons of the types mentioned earlier in this document. To enable or disable an installed add-on, click the add-on in the list, then click Enable or Disable.

If you click an ActiveX control in the list, then click Update ActiveX, Windows searches for an update at the location where the original control was found. If a newer version is found at that location, Internet Explorer attempts to install the update.

The list of add-ons also contains signed add-ons that were blocked from installation because their publisher was untrusted. After selecting one of these controls, the user can unblock the control by clicking Allow. Caution should be exercised when doing this, because clicking Allow removes the publisher from the Untrusted list.

Blocked Add-on status bar icon

A Blocked Add-on icon appears in the status bar when a Web page attempts to instantiate an ActiveX control that is disabled or blocked because its publisher is untrusted. You can double click the icon to open Manage Add-ons. The status bar icon is accompanied by a balloon tip the first five times it appears.

Add-on notification balloon tip

When a Web page attempts to instantiate a disabled add-on and there is no current Blocked Add-on status bar icon, a message appears to tell the user that the current Web page is requesting an add-on that is disabled. The user can click the message for more details on blocking add-ons.

You can use Control Panel to suppress the message. This option is described later in this document.

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

Windows Error Reporting data has shown that add-ons are a major cause of stability issues in Internet Explorer. These add-ons significantly affect the reliability of Internet Explorer. These add-ons can also pose a security risk, because they might contain malicious and unknown code.

Many users are unaware of the add-ons they have installed on their computer. Some add-ons are loaded whenever Internet Explorer is started, but cannot be detected unless the user searches the registry. When users experienced crashes, there was no easy way to diagnose whether the issue was related to an add-on. Even if they suspected that the problem stemmed from recently-installed software, it was difficult to isolate the cause and often impossible to resolve if the software did not provide an uninstall option.

Internet Explorer Add-on Management, together with Add-on Crash Detection, gives users the ability to improve the security and stability of their systems by identifying and disabling problematic add-ons. Administrators are also provided with a powerful administrative tool to control add-on use in their organization.

What works differently?

Behavior when add-ons are disabled

Disabling an add-on does not remove it from the computer. It only prevents Internet Explorer from instantiating the object and executing its code. There is no guarantee that the disabled add-on will never be loaded, since an add-on that is considered by Internet Explorer to be disabled can still be used by another component in the system. The behavior that is displayed by disabling different object types varies.

  • If an ActiveX control is disabled, Web pages that rely on the control might not work as expected. They behave as if the user has uninstalled the control from the computer and declined to install it. Users are not prompted to upgrade controls that have been disabled.

  • If a browser helper object is disabled, functionality that depends on the object is not available, and there is no visual indication that a component is disabled.

  • If a browser extension is disabled, toolbar buttons and menu entry points are not shown for that extension. Internet Explorer behaves as if the extension was not installed.

  • If a toolbar extension is disabled, the toolbar does not appear in Internet Explorer and, on the View menu, the Toolbars item is disabled. Internet Explorer behaves as if the toolbar was not installed.

The concept of a disabled add-on only applies to instances of Internet Explorer (Iexplore.exe) and Windows Explorer (Explorer.exe) by default. Currently, other programs based on Internet Explorer components, such as the WebBrowser control, do not respect the disabled state. However, you can use the featurecontrol key to extend this functionality to other applications.

Some software programs depend on a combination of multiple add-ons to work correctly, and disabling any one of them might cause problems. Caution should be exercised when deciding to disable one or more add-ons.

Uninstallation

If the user disables a non-ActiveX add-on and subsequently uninstalls and then re-installs it, the add-on might remain in a disabled state. This is because Internet Explorer is not notified of application installations and does not detect any application state changes. However, if Internet Explorer is started while the add-on is not installed, it detects a change and automatically clears the disabled state.

If the user disables an ActiveX control and then uninstalls it, the next time a Web page attempts to use the control, Internet Explorer detects that the control is no longer present and clears the disabled state. However, if the ActiveX control is reinstalled using an executable file (as opposed to a Web page download) before there are any attempts to instantiate the control, then it remains disabled. This is because Internet Explorer does not detect a state change.

How do I resolve these issues?

In the event that disabling an add-on causes a lack of functionality, it can be restored by enabling the add-on in Manage Add-ons. Internet Explorer must be restarted for new settings to take effect, with the exception of ActiveX controls, where reloading the affected page might be sufficient.

Internet Explorer Add-on Management for Administrators

Detailed description

Disabling Crash Detection

To disable the Crash Detection feature of Add-on Management, see "What settings are added or changed in Windows XP Service Pack 2?" below. When Crash Detection is disabled, a crash in Internet Explorer exhibits previous behavior, which is usually to invoke Windows Error Reporting. All policies for Windows Error Reporting continue to apply.

Disabling Add-on Management user interface

To disable the Add-on Management user interface, see "What settings are added or changed in Windows XP Service Pack 2?" below. When the Add-on Management user interface is disabled, the Enable and Disable options are unavailable in Manage Add-ons.

Deny all add-ons unless specifically allowed in the Add-on List

This policy setting allows administrators to ensure that any Internet Explorer add-ons not listed in the Add-on List policy setting will be denied.

To set this policy, an administrator can modify the RestrictToList registry key in either of the following locations:

HKEY_CURRENT_USER\SOFTWARE\Microsoft
\Windows\CurrentVersion\Policies\Ext\

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Policies\Ext\

Name: RestrictToList

Type: DWORD

Value:

  • 1 (Anything not on the Add-on list is considered disabled.)

  • 0 (Anything not on the Add-on list works as it would without policy.)

Add-on List

Administrators can control the use of specific add-ons through the add-on list policy. Administrators can choose to enable or disable an add-on as well as allow a specific add-on to be managed by the user.

To set this policy, an administrator can create a registry value based on the GUID of the add-on in either of the following keys and then set the desired value:

HKEY_CURRENT_USER\SOFTWARE\Microsoft
\Windows\CurrentVersion\Policies\Ext\CLSID

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Policies\Ext\CLSID

Each add-on is a value in this registry key with following properties:

Name: GUID of add-on

Type: REG_SZ

Value:

  • 0 - Add-on is disabled and cannot be managed by the end user.

  • 1 - Add-on is allowed and cannot be managed by the end user.

  • 2 - Add-on is allowed and can be managed by the end user.

The Add-on (CLSID) lists are empty by default.

Behavior of Management UI when policies are applied

When an Add-on Manager policy is in effect, and the user selects an add-on from the management list that is disabled by policy, Enable and Disable are unavailable.

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

This feature allows administrators to control the usage of the new features.

What works differently? Are there any dependencies?

The new features for allowing and disallowing add-ons work in conjunction with existing policies for managing ActiveX controls. Add-on disabling is applied on top of existing checks and does not replace other security restrictions that might be in place. For example, if an ActiveX control is blocked by its ActiveX compatibility flags, it will always be blocked, regardless of the add-on management settings.

The effect of disabling an add-on is described earlier in this document.

How do I resolve these issues?

In the event that adding these policies removes needed functionality, remove the policies that were applied and restart Internet Explorer.

Internet Explorer Add-on Crash Detection

Detailed description

Whenever Internet Explorer stops unexpectedly, Windows starts the Add-on Crash Detection program. Add-on Crash Detection is an error analysis program that examines the state of the Iexplore.exe (Internet Explorer) process. It collects the list of dynamic link libraries (DLLs) that are loaded, and the value of the instruction pointer register (EIP) at the time of the crash. Add-on Crash Detection then attempts to find the DLL whose memory range the EIP lies within. This DLL is often the cause of the crash.

If a DLL is found, it is not a system DLL, and the DLL is the COM server for an Internet Explorer add-on, the Internet Explorer Add-on Crash Detection dialog box appears. This dialog box contains information that indicates which add-on caused the crash, the name of the company associated with the add-on, and the description of the DLL file that contains the add-on code. To display Manage Add-ons, which you can then use to disable the identified add-on, click Advanced. (For more information about this window and its options, see “Manage Add-ons,” earlier in this document.) After you review the information and click Continue, the standard Windows Error Reporting window opens.

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

For this information, see “Internet Explorer Add-on Management for Users,” earlier in this document.

What works differently? Are there any dependencies?

Since this feature only runs when Internet Explorer stops operating, there should be no changes to normal operation.

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

Setting name

Location

Default value

Possible values

Disable Crash Detection

HKEY_CURRENT_USER {or HKEY_LOCAL_MACHINE} \Software\Policies
\Microsoft\Internet Explorer \Restrictions

Name: NoCrashDetection

Type: DWORD

0

0 — Off,

1 — On

Deny all add-ons unless specifically allowed in the Add-on List

HKEY_CURRENT_USER {or HKEY_LOCAL_MACHINE} \Software\Microsoft
\Windows\CurrentVersion
\Policies\Ext\

Name: RestrictToList

Type: DWORD

0

0 — Off,

1 — On

Add-on List

HKEY_CURRENT_USER {or HKEY_LOCAL_MACHINE} \SOFTWARE\Microsoft\Windows
\CurrentVersion\Policies\Ext\CLSID

Name: GUID of the control

Type: REG_SZ

N/A

0 – Add-on is disabled and cannot be managed by the end user.

1 – Add-on is allowed and cannot be managed by the end user.

2 – Add-on is allowed and CAN be managed by the end user.

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

No. Your code does not need to change to work with Internet Explorer Add-on Crash Detection or Add-on Management.

Internet Explorer Binary Behaviors Security Setting

What does Binary Behaviors Security Setting do?

Internet Explorer contains dynamic binary behaviors: components that encapsulate specific functionality for HTML elements to which they were attached. These binary behaviors are not controlled by any Internet Explorer security setting which allows them to work on Web pages in the Restricted Sites zone. In Windows XP Service Pack 2, there is a new Internet Explorer security setting for binary behaviors. This new setting disables binary behaviors in the Restricted Sites zone by default. This new binary behaviors security setting provides a general mitigation to vulnerabilities in Internet Explorer binary behaviors.

For more information on binary behaviors, such as how they work, and how to implement them, see “Cutting Edge: Binary Behaviors in Internet Explorer 5.5” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=21862. Note that binary behaviors, which are defined in C++ and compiled, are different from Attached Behaviors and Element Behaviors, which are defined in script.

Who does this feature apply to?

Application developers whose applications use Internet Explorer functionality in the Restricted Sites or Local Machine zones should review this feature to plan to adopt changes in their applications. For example, e-mail applications that render HTML e-mail in the Restricted Sites zone might need to be modified.

Users can only be impacted by applications that do not completely render HTML content with this new setting. These applications will typically alert the user that some active behavior has been blocked from display. For example, when Outlook Express encounters this situation, it informs the user that it has restricted active content in the e-mail.

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

New Internet Explorer Security Setting

Detailed description

A new URLaction setting, Binary Behaviors, is in each Internet Explorer security zone. The default value for this setting is Enable for all zones except the Restricted Sites zone. In the Restricted Sites zone, the default value is Disable.

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

This new setting helps mitigate attacks in which binary behaviors were being used maliciously and allows the user to control the use of binary behaviors on a per-zone basis.

What works differently?

Any use of any binary behaviors for HTML rendering from the Restricted Sites zone is blocked.

How do I resolve these issues?

To use binary behaviors from the Restricted Sites zone, an application will have to implement a custom security manager. (For more information, see the “Creating a Customized URL Security Manager” section in “Introduction to URL Security Zones” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=21863.)

When the binary behaviors URL action is exercised from a custom security manager, the URL action will pass in a string representation of the particular binary behaviors that can be enabled by that custom security manager as needed for application compatibility. The following process takes place when this URL action is exercised:

  • Internet Explorer calls into a custom security manager (if available), using the ProcessUrlAction method with a dwAction of URLACTION_BEHAVIOR_RUN.

  • The pContext parameter points to a LPCWSTR that contains the behavior that a policy is being queried for. For example, #default#time.

  • You set *pPolicy = URLPOLICY_ALLOW for your smartTag behavior, from within your custom security manager, as appropriate.

  • In the absence of the custom security manager, the default action is to disallow running behaviors in the Restricted zone.

If you are a desktop administrator you can decide which Binary Behaviors to allow in the Locked-down Local Machine Zone. To enable a behavior in the Locked-down Local Machine Zone, you can add it to the list of administrator-approved behaviors as follows, replacing the namespace and behavior variables as appropriate to your environment:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Internet Settings\AllowedBehaviors

# % Namespace % #%Behavior%=dword:00000001 

Behaviors that are defined in this list will also be used for any other zone where the Binary Behavior restriction setting is configured to “Admin-Allowed” (65536).

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

None. This is only a setting to turn on or off the existing binary behaviors functionality.

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

Setting name

Location

Previous default value (if applicable)

Default value

Possible values

*

HKEY LOCAL MACHINE [or Current User] \Software\Microsoft
\Internet Explorer\Main
\Feature Control \FEATURE_BINARY_
BEHAVIOR_LOCKDOWN

None

1

0 - Off

1 - On

2000

HKEY_CURRENT_USER \Software \Microsoft \Windows \CurrentVersion \Internet Settings\Zones \3\

None

3 - Disabled (for Restricted sites zone)

65536 - Admin-approved (for the Locked-down Local Machine zone)

0 - Enabled (for all other zones)

3 - Disabled

65536 - Admin-approved

0 - Enabled

Note that the binary behaviors setting can also be modified through Group Policy as part of the Internet Explorer Security Zones and Content Ratings setting.

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

If your code uses binary behaviors in the Restricted Sites zone, then you will need to change your code by implementing a custom security manager for your application. For more information, see the "Creating a Customized URL Security Manager" section in "Introduction to URL Security Zones" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=21863.

Internet Explorer BindToObject Mitigation

What does BindToObject Mitigation do?

In Windows XP Service Pack 2, the ActiveX security model is applied in all cases where URL binding is used to instantiate and initialize an object. The ActiveX security model allows controls to be marked as “safe for scripting” and “safe for initialization” and provides users with the ability to block or allow ActiveX controls by security zone, based on those settings. This allows greater flexibility and control of active content in Internet Explorer.

Who does this feature apply to?

  • Web developers and network administrators need to be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.

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

  • Users could be impacted by sites that are not compatible with these stricter rules.

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

None. Existing security functionality is being extended.

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

ActiveX Security Model applied to URL object initializations

Detailed description

The most effective way to remove ActiveX safety vulnerabilities is to apply security policies consistently at the source of the URL binding: URLMON.  Declaring an ActiveX control in an HTML page using the <object> tag and CODEBASE attribute is one commonly known example of using BindToObject. The same functionality is used by any component that wants to resolve an URL and get back a stream or object. The ActiveX security model is now applied to all object initializations with a URL as a source.

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

In the case of ActiveX controls, the ActiveX security model allows controls to be marked as “safe for scripting” or “safe for initialization” and provides users with the ability to block or allow ActiveX controls by zone, based on those settings. In earlier versions of Windows, this security framework was not applied in all cases where URL binding took place. Instead, the calling code was responsible for assuring the integrity and security of the control, which could often result in security vulnerabilities. There are now a number of public exploit variations that expose this exact issue by going through Internet Explorer to compromise vulnerabilities in the calling code.

What works differently? Are there any dependencies?

The ActiveX security model is applied to all object initializations with an URL as a source, and the “Safe for initialization” tag is applied to all objects. This mitigation only applies to cases where Internet Explorer resolves an URL and assigns it to an object.

How do I resolve these issues?

Application compatibility problems should be minimal. Applications can opt-out if they have their own security manager. For more information on opting out of this security model, see “Security Considerations: URL Security Zones API,” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=21814.

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

None.

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

You might need to change your code. For more information, see “How do I resolve these issues?” in this section.

Internet Explorer Information Bar

What does the Information Bar do?

The Internet Explorer Information Bar in Windows XP Service Pack 2 replaces many of the common dialog boxes that prompted users for information in previous versions and provides a prominent area for displaying information that users may want to view or act upon. Examples of dialog boxes that have been replaced by Information Bar notifications include blocked ActiveX installs, pop-ups, downloads and active content. The Information Bar will provide information similar to the notification area in Outlook 2003, which informs users of blocked content.

Who does this feature apply to?

This feature applies to the following audiences:

  • Users who need to understand how the new behavior will affect their Web browsing experience.

  • System Administrators, who need to know how to turn this functionality on or off for the client computers in their organization.

  • Designers of Web sites that rely on add-ons, which will provide a different user experience.

  • Developers of Web-based applications who need to understand how their experience changes. For example, this affects the development of ActiveX controls. ActiveX controls which are updates to controls that are currently installed on other computers will only be treated as updates if the GUID of the new control matches the current GUID.

  • Developers of applications hosting the Web browser control will need to know how to use the new application programming interface (API) to take advantage of this new functionality.

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

Information Bar User Interface

Detailed description

The Information Bar looks and acts in a similar way to the Outlook 2003 blocked content notification area. It appears below Internet Explorer toolbars and above the Web page in view when a notification is present and disappears on the next navigation. The text in the Information Bar varies, depending on the notification that is provided, and wraps to two lines if the text exceeds the bounds of the notification area. If a user controls the focus (or, which object in the browser can receive input) by using the TAB key, the Information Bar gets focus after the toolbar and before the Web page.

Either clicking or right-clicking on the Information Bar brings up a menu that relates to the notification that is presented. This menu always contains a link to Information Bar Help, which provides more detailed information about the notification. Additional menu items related to the notification appear above the Help menu item.

Users can configure the Information Bar to play a sound when it appears; the default setting for the sound is On. When the Information Bar appears, the Windows trust icon appears in place of the Error on page notification on the status bar.

In certain cases, more than one action can be blocked. For example, a pop-up window may be blocked at the same time that an add-on install is blocked. In those cases, the text becomes more generic and the menus merge to show each action blocked at the top level, with each action’s menus in a submenu.

There is a custom security zone setting for the Information Bar that enables users to change the settings of the Information Bar by security zone. Users can choose to be notified with the Information Bar or to go back to the behavior of Windows XP Service Pack 1 and get a less prominent notification for file and code downloads.

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

In Windows XP Service Pack 2, Internet Explorer may block content that is necessary to complete certain online tasks. The Information Bar provides a prominent notification that informs users how to get Web pages they trust working again without the more intrusive prompt that was provided in Windows XP Service Pack 1.

What works differently?

For this information, see the next section, “What existing functionality is changing in Windows XP Service Pack 2?”

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

Add-on Install Prompts

Detailed description

In Windows XP Service Pack 1, when a Web page refers to an ActiveX control that is not currently on the computer, users are asked whether they want ActiveX controls to be downloaded. In Windows XP SP2, this is displayed in the Information Bar. The following table describes the elements in the Information Bar. Text in italics will be replaced by the specific items appropriate to the situation.

Information Bar Element

Message Text

Information Bar Text

This site might require the following ActiveX control: Control_Name from Publisher_Name. Click here to install...

Short Text

Installation Blocked

Menu Options

Install ActiveX Control...

What’s the risk?

Trusted publishers will work as they did in Windows XP SP1. The controls that are provided by these publishers install without requiring additional configuration.

Blocked publishers display the status bar icon. The control provided by these publishers will not install on the computer and do not go into the Information Bar.

Add-on upgrades work as they did in Windows XP SP1. Internet Explorer uses the following criteria when determining whether the control is an upgrade:

  • The file that is registered as the ActiveX control must be signed with Authenticode™ technology. (This file is referenced from HKEY_CLASSES_ROOT\CLSID\Control_clsid\InProcServer32, where Control_clsid is the CLSID specified by the OBJECT tag.)

  • The publisher name in the digital signature of the new control matches the publisher name in the digital signature of the existing control.

  • If the ActiveX control is packaged in a CAB file, the CAB file must be signed. The DLL or OCX to be installed should also be signed in order for subsequent upgrades to bypass the Information Bar.

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

Providing add-on install prompts in the Information Bar rather than a dialog box reduces the occurrences of users inadvertently installing code on their computer.

What works differently?

Certain Web pages currently rely on users installing code to function correctly. Some sites redirect the user to a separate page that explains how to install the ActiveX control. If a site automatically redirects the page without providing the control on the new page, the Information Bar will appear on the redirect page to offer the opportunity to install the control. If, however, the site closes the window that attempted to install the ActiveX control, the customer might not get a chance to install the control.

How do I resolve these issues?

Web authors should ensure that the ActiveX control is also available on the page to which the user is redirected. This will ensure that users have ample opportunity to install the control.

Web page authors should not suggest that users lower their security settings, because it will not help in this situation. For additional guidance for Web authors on Windows XP SP2, see "Fine-Tune Your Web Site for Windows XP Service Pack 2" on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=32775.

Pop-up Blocked Notification

Detailed description

Windows XP SP2 displays a notification in the Information Bar when a pop-up is blocked. This becomes a more obvious entry point to the Pop-up Blocker functionality, such as replaying the pop-up, adding the site to an “allow” list for pop-ups, or navigating to Pop-up Blocker settings. The Information Bar also provides a top level entry point to turn off the Information Bar for pop-ups if the user decides the notification is too big for this event.

Information Bar Element

Display

Information Bar Text

Pop-up blocked. To see this pop-up or additional options, click here...

Short Text

Pop-up Blocked

Menu Options

Temporarily Allow Pop-ups

Allow Pop-ups for this Site

Settings

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

Showing the pop-up blocked notification in the Information Bar gives higher priority to that notification. Users have a better understanding of where to go to see a blocked pop-up window or to see their Pop-up Blocker settings.

What works differently?

Turning off the Information Bar for the Pop-up Blocker causes the Pop-up Blocker to return to notifying users with the status bar icon. All the same menu items are accessible from this status bar icon if the bar is disabled for pop-ups. For more information, see “Internet Explorer Pop-up Blocker,” later in this document.

Automatic Download Prompts

Detailed description

File download prompts that are launched automatically now appear in the Information Bar.

The Information Bar includes descriptive text that explains why the action was taken and provides a context sensitive menu that you can use to respond to the notification. The following table identifies the text that will appear in the Information Bar and the actions that you can select from the menu.

Information Bar Element

Display

Information Bar Text

To help protect your security, Internet Explorer blocked this site from downloading files to your computer. Click here for more options...

Friendly Notification Text

File Download Blocked

Menu Options

Download Software...

What’s the Risk?

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

By moving download prompts to the Information Bar, users can be prevented from installing unwanted code on their computers. Previously, sites could overwhelm users with file download prompts and, as a result, users could accidentally run unwanted software on their computer. With this change, file download prompts that are launched automatically are more likely the result of a user’s deliberate click and not an accidental action.

What works differently?

Any time a site refers to a file download prompt without a user action, such as clicking on an element of the page, the prompt appears in the Information Bar.

How do I resolve these issues?

Web authors should ensure there is a link on the Web page that a user can click to get to the file download. If you use a script to navigate to the resource, the script should run synchronously within the context of the OnClick event handler for the link.

For additional guidance for Web authors on Windows XP SP2, see "Fine-Tune Your Web Site for Windows XP Service Pack 2" on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=32775.

Active Content Blocked

Detailed description

When active content is blocked from running in the Local Machine zone, the Information Bar will appear.

The Information Bar includes descriptive text that explains why the action was taken and provides a context sensitive menu that you can use to respond to the notification. The following table identifies the text that will appear in the Information Bar and the actions that you can select from the menu.

Information Bar Element

Display

Information Bar Text

To help protect your security, Internet Explorer has restricted this file from showing active content that could access your computer. Click here for options...

Short Text

Active Content Blocked

Menu Options

Allow Blocked Content...

What’s the Risk?

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

In Windows XP SP2, Internet Explorer sometimes blocks active content which may be necessary to complete certain tasks. This new user interface element ensures that there is a notification that allows people to complete these tasks on Web pages they trust.

What works differently?

The Local Machine zone mitigation will now use the new Information Bar.

For more information, see “Internet Explorer Local Machine Zone Lockdown,” later in this document.

ActiveX Blocked Due to Security Settings

Detailed description

Windows XP SP2 no longer shows the prompt ActiveX Blocked Due to Security Settings. Internet Explorer shows this notification in the Information Bar.

The Information Bar includes descriptive text that explains why the action was taken and provides a context sensitive menu that you can use to respond to the notification. The following table identifies the text that will appear in the Information Bar and the actions that you can select from the menu.

Information Bar Element

Display

Information Bar Text

Your security settings do not allow ActiveX controls to run on this page. This page may not display correctly. Click here for more options...

Short Text

Software Blocked

Menu Options

More Information

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

The Windows XP SP1 prompt makes browsing with heightened security settings difficult. Displaying this prompt in the Information Bar allows users to more easily browse with high security settings without seeing the prompt.

What works differently?

This does not cause further application compatibility issues, other than when browsing the Internet zone with the security slider set to High.

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

For information on the registry keys pertaining to this feature, see “Feature Control Security Zone Settings,” later in this document.

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

Web page authors should try to avoid redirects or closing the window that the user opened, based on whether or not they install an add-on.

Web page authors that launch automatic file download prompts should ensure that there is a link to those downloads on their sites.

Add-on publishers should ensure that upgrades to previous controls use the same Globally Unique Identifier (GUID) to ensure that users do not get the Information Bar for those upgrades.

For additional guidance for Web authors on Windows XP SP2, see "Fine-Tune Your Web Site for Windows XP Service Pack 2" on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=32775.

Internet Explorer Using Feature Control Registry Settings with Security Zone Settings

What do Feature Control Registry Settings and Security Zone Settings do?

Feature Control registry settings are provided in Windows XP SP 2 so that a specific process can be configured to opt-in to a particular security feature. In the following example, Internet Explorer has been configured to use the Windows Restrictions security feature:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Internet Explorer\Main\FeatureControl
\FEATURE_WINDOWS_RESTRICTIONS] iexplore.exe=1

Once a process has been configured to use a security feature, the security feature is running and security zone settings can be applied for more precision, if implemented for that feature. In the Security Settings tab of Internet Options, the user can adjust these settings for many of the new Windows XP SP2 feature controls. If you select Enable, it lowers the security settings and allows the behavior to run less securely, or in the same manner as it did in Windows XP Service Pack 1. For example, if Windows Restriction is set to Enable in the Intranet zone, Windows Restrictions will not be applied — script-initiated windows can be opened as freely as in Windows XP SP1. The Windows XP SP2 restrictions can be applied again by setting the security zone setting to Disable, which blocks the less-secure behavior while the feature control is enabled for that process.

For example, if the feature is turned on for Windows Restrictions, this feature:

  • Forces the status bar to be present in script-initiated Internet Explorer windows with the title bar [those that were created with window.open()].

  • Constrains the size and positioning of script-initiated Internet Explorer windows that have title and status bars to ensure that the title bar and the status bar in these windows is always visible to the user.

  • Constrains script-initiated popup windows with no title or status bar or other frame, so that they:

    • Do not extend above the top or below the bottom of the parent Web Object Control (WebOC) window.

    • Are smaller in height than the parent WebOC window.

    • Overlap the parent horizontally.

    • Stay with the parent window if it moves.

    • Are positioned above its parent in “z” order, so other windows cannot be obscured.

Each of the Feature Controls is discussed in more detail later in this document. For more information about URL Action settings and how they relate to security zones, see “About URL Security Zones Templates” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=26001.

Using security zone settings for a feature provides additional precision in control for security features that are introduced in Windows XP SP2 and can help manage application compatibility for organizational intranet applications. A user or administrator can select different behaviors based on risk. For example, in the Internet zone, suppose that http://www.contoso.com has the Windows Restrictions feature applied by default. One aspect of this feature enforces the status bar for Internet Explorer windows created with the window.open method. This security feature was added to guard against the user assuming a window was from a trusted source when it was not. However, the Windows Restrictions feature is turned off by default for http://contoso on the intranet, where the risk is lower, due to the typical level of corporate security. Intranet applications will continue to operate as they did in Windows XP SP1 and will not be affected by compatibility issues due to additional security restrictions.

Who does this feature apply to?

Web application developers need to be aware that the new Windows XP SP2 security settings are dependent on the zone in which an application is run. Therefore, you should assign security zones carefully; this should be a part of your information security considerations. The security zones that you use should also be considered when assessing application compatibility.

Administrators of Group Policy may want to adjust the default values for each zone to suit the particular environments in their organization.

Unless prevented by policies in Group Policy, users can manage the values for these security zone settings (or URL actions) for each zone through Internet Options in Control Panel. Note that the Local Machine Zone is not available through Control Panel. To access the security settings for a zone, click Start, click Control Panel, click Internet Options, click the Security tab, click a Web security zone, and then click Custom Level.

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

Feature control registry settings

Detailed description

Windows XP Service Pack 2 introduces new feature control registry settings.

For many of these features, when the registry setting is on, users can configure the security settings (also known as URL action flags) to fine tune the feature control in each individual security zone

  • If you choose Enable as the action to take for an Internet Explorer feature control, the zone is secured as it was for Service Pack 1 for Windows XP. Relevant security control features will not apply in this zone; the security zone will run without the added layer of security provided by this feature.

  • If you choose to disable the security zone setting, the actions that may be harmful cannot run; this Internet Explorer security feature will be turned on in this zone, as dictated by the feature control setting for the process.

Security settings are often applied to a zone by a URL security zone template. The Windows XP SP2 default values for the security settings and the settings by zone template are listed section “Internet Explorer URLaction Security Setting in Group Policy” later in this document.

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

As originally envisioned, each feature control setting would either be on or off for all security zones. Customer feedback indicated that more precise tuning with the settings was necessary for some features. For example, the internal workflow of some organizations depends on intranet applications. A feature control that protects users in the Internet zone may cause an intranet application to stop working. Because of this, Microsoft has incorporated the ability to control many security settings by zone.

What works differently?

Adding security settings by zone provides more flexibility in applying the new security features. This flexibility will provide a more manageable implementation of this new security feature, particularly in intranet scenarios.

How do I resolve these issues?

If the feature control setting is suspected of causing problems for an application, changing the feature control setting in the zone where the application is running to Enable allows the administrator or user to return to Windows XP SP1 behavior in that zone for that specific feature while maintaining the more secure behavior in other security zones. For some security settings, additional configuration options such as Prompt and Admin-approved are available, as well as Enable and Disable.

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

The following table provides three of the new URLaction security settings in Internet Explorer 6.0 in Windows XP Service Pack 2 as an example. More detailed setting information will be provided in individual sections later in this document.

Setting name

Location

Default value

Possible values

URLACTION _
FEATURE_
MIME_SNIFFING

HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft
\Windows\CurrentVersion
\Internet Settings\Zones

HKEY_CURRENT_USER
\SOFTWARE\Microsoft
\Windows\CurrentVersion
\Internet Settings\Zones

Set per zone

Enable

Disable

URLACTION_
FEATURE_
ZONE_ELEVATION

HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft
\Windows\CurrentVersion
\Internet Settings\Zones

HKEY_CURRENT_USER
\SOFTWARE\Microsoft
\Windows\CurrentVersion
\Internet Settings\Zones

Set per zone

Enable

Disable

Prompt

URLACTION _
FEATURE_
WINDOW_RESTRICTIONS

HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft
\Windows\CurrentVersion
\Internet Settings\Zones

HKEY_CURRENT_USER
\SOFTWARE\Microsoft
\Windows\CurrentVersion
\Internet Settings\Zones

Set per zone

Enable

Disable

Do I need to change my code to work with Windows XP SP2?

If the code uses the default URLmon security manager, the developer must call CoInternetIsFeatureEnabledForURL to check the security settings for a particular zone.

Internet Explorer Feature Control Settings in Group Policy

What does Internet Explorer Feature Control Settings in Group Policy do?

Windows XP Service Pack 2 introduces new registry keys and values for Internet Explorer security features called Feature Control. The specific behavior of the new feature control registry settings is discussed with each security feature throughout this section.

A modified Inetres.adm file contains new feature control settings as policies. Administrators can manage the new feature control policies by using Group Policy objects (GPO). When Internet Explorer is installed, the default preferences settings for these feature controls are registered on the computer in HKEY_LOCAL_MACHINE. In Group Policy, the Administrator can set them in either HKEY_LOCAL_MACHINE (Computer Configuration) or HKEY_CURRENT_USER (User Configuration).

Who does this feature apply to?

Group Policy administrators can uniformly configure the new Internet Explorer Feature Control settings for the computers and users that they manage.

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

Group Policy Internet Explorer Settings

Detailed description

The new feature control policies are:

  • Binary Behavior Security Restriction

  • MK Protocol Security Restriction

  • Local Machine Zone Lockdown Security

  • Consistent Mime Handling

  • Mime Sniffing Safety Feature

  • Object Caching Protection

  • Scripted Window Security Restrictions

  • Protection From Zone Elevation

  • Information Bar

  • Restrict ActiveX Install

  • Restrict FileDownload

  • Add-on Management

  • Network Protocol Lockdown

In the Group Policy Management Console, the local computer policies for Feature Controls are in \Computer Configuration\Administrative Templates
\Windows Components\Internet Explorer\Security Features.

The current user policies for Feature Controls are in \User Configuration\Administrative Templates
\Windows Components\Internet Explorer\Security Features.

The policy for the feature needs to be enabled for the process—for example, IExplore.exe — before the zones’ individual security setting policies or preferences will be applied. For more about the behavior of Feature Control keys and setting them for a process, see the section on each feature and the section on “Internet Explorer Using Feature Control Settings with Security Zone Settings” later in this document. For more information about specific security settings by zone, see the “Internet Explorer UrlAction Security Settings in Group Policy” section, later in this document.

Administrators of Group Policy can manage these new policies in the Administrative Templates extension to the Group Policy Management Console. When configuring these policies, the administrator can enable or disable the security feature for explorer processes (Internet Explorer and Windows Explorer), for executable processes that they defined, or for all processes that host the WebOC.

Users cannot see the feature control policies or preference settings through the Internet Explorer user interface, except for Local Machine Zone Lockdown Security. Feature control policies can only be set using the Group Policy Management Console, and feature control preference settings can only be changed programmatically or by editing the registry.

Configuring Policies and Preferences

Group Policy is the recommended tool for managing Internet Explorer for client computers on a corporate network. Internet Explorer supports Group Policy management for all new IE feature controls in Windows XP Service Pack 2, and for Security page settings or urlActions. Administrators of Group Policy can manage these new policy settings in the Administrative Templates extension of the Group Policy Management Console.  

When implementing policy settings, it is recommended to configure template policy settings in one Group Policy object (GPO) and configure any related individual policy settings in a separate GPO. You can then use Group Policy management features (for example, precedence, inheritance, or enforce) to apply individual settings to specific client computers.

Policies can be read by users but can only be changed by Group Policy management or by an administrator. Preference settings can be changed programmatically, by editing the registry, or in the case of urlActions, by using Internet Explorer. Note that settings that are associated with policies will take precedence over settings specified using Internet Explorer preferences.

IEAK/IEM

For operating systems prior to Windows XP SP2 and previous Internet Explorer versions, Internet Explorer Administration Kit (IEAK) 6 Service Pack 1 remains the recommended tool for solution providers and application developers to customize Internet Explorer for their end users. IEAK support and the IEAK/IEM process does not change for Internet Explorer versions prior to Windows XP Service Pack 2. The process also has not changed for using IEAK/IEM to set user setting preferences in Internet Explorer versions prior to and including Windows XP Service Pack 2. This includes the new IE6 in XPSP2 preference settings. However, the true policy settings introduced by this feature can only be managed within Group Policy. For more information about IEAK, see “Microsoft Internet Explorer 6 Administration Kit Service Pack 1” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=26002.

Windows XP SP 2 will mark the start of two key changes for IEM/IEAK:

  • Upgrades to IE will only be available via Windows Service Packs and major Windows releases.

  • Starting with Windows XP SP 2, customers will no longer be able to redistribute IE binaries with their IEAK packages. Custom packages that are generated from IEAK 6 SP1 will transparently apply settings to Internet Explorer running on Windows XP SP2, but will not install any binaries.

In summary, the IEAK can still be used as before for all Internet Explorer versions prior to Windows XP Service Pack 2, and is still the tool to use for branding in Windows XP Service Pack 2. IEM/IEAK can be still be used to set user preference settings in Windows XP Service Pack 2, and now true policies can be set using the GPMC.

Frequently asked questions for existing users of the IEAK

I currently use the IEAK with a Corp license to configure Internet Explorer on desktops computers and I don’t have Active Directory in my organization. How can I configure Internet Explorer if the IEAK doesn’t work with XP SP2?

You can still use Group Policy to configure settings even if you don’t use Active Directory. You can use Group Policy to create a local Group Policy object (GPO) with your settings and then deploy that GPO. Once you have configured your GPO for Internet Explorer, you can deploy it using your standard deployment methods. For example, you might use startup or logon scripts, Systems Management Server scripts, or you might send links to users in e-mail.

I currently use the IEAK with a Corp license to configure Internet Explorer on desktops and I don’t have Active Directory in my organization. What happens if I keep running my IEAK 6 SP1 packages against Windows XP SP2?

If you install an IEAK 6 SP1 package on a Windows XP SP2 computer, the settings from IE 6 SP1 will be updated, but the new Windows XP SP2 security settings will not be configurable, since IEAK 6 SP1 wasn’t designed to deploy the new settings for Windows XP SP2.

I currently use the IEAK with an ISP license to brand Internet Explorer bits and setup connections for my ISP customers. Will my IEAK 6 SP1 packages still be able to apply settings on Windows XP SP2?

The branding settings in your ISP license IEAK 6 SP1 package should be applied correctly.

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

By adding the new Internet Explorer Feature Control policies to Group Policy, administrators can manage these true policies to establish standard security settings for all the computers that they configure.

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

Windows XP Service Pack 2 adds new policies to Group Policy but does not change how policies are managed. Developers need to be aware of how each feature control setting affects security-related behavior for their applications. The effects of the new behavior on application development are discussed within this document in the specific sections for each feature.

Internet Explorer UrlAction Security Settings in Group Policy

What does Internet Explorer UrlAction Settings in Group Policy do?

Windows XP Service Pack 2 introduces true policies for the configurable actions in the Internet Explorer Security tab settings. These actions can be set to allow less secure behavior within a security zone. In Windows XP Service Pack 1, the user could change these actions using the Internet Explorer user interface, which would then write the registry settings in the preferences hives. The administrator could then distribute standard settings for these actions using the IEM/IEAK snap-in to Group Policy. In this release, these security settings are managed using the Group Policy Management Console and, if set, can only be changed by a Group Policy object (GPO) or by an administrator.

An updated Inetres.adm file contains the same list of urlAction settings as policies that are found in the Internet Explorer user interface as preferences. Administrators can manage the new feature control policies by using Group Policy objects (GPOs). When Internet Explorer is installed, the default HKEY_CURRENT_USER preferences settings for these urlAction settings are registered on the computer as they were in previous versions. The Administrator has to use the Group Policy Management Console (GPMC) snap-in to add urlActions as policies.

Who does this feature apply to?

Group Policy administrators can uniformly configure the new Internet Explorer urlAction security setting policies for the computers and users that they manage. If the administrator chooses to set selected urlActions and not all urlActions, it is important to inform the end-user which actions are controlled by policy, as these actions will not respond to user preference settings.

Note   The Internet Option control panel will display policy settings when opened and users can interact with user interface and appear to change their preferences. However, these preferences will not actually override Group Policy settings, which may cause a confusing user experience. The administrator can also set a policy to disable to Security page user interface so that it is more clear to the user that these settings are not available to be changed.

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

Group Policy Internet Explorer Security Settings

Detailed description

The following definitions apply to Internet Explorer settings for Windows XP Service Pack 2:

  • Security zones: Internet, Intranet, and Local Machine. There are also special zone settings: Locked-Down Local Machine Zone, Trusted Sites, and Restricted Sites.

  • Templates: Standard settings for all urlActions in a security zone. Templates can be applied in any zone, and settings will provide a range of choices from low security, medium-low, medium, and up to high security for the zone.

  • urlActions: Security settings in the registry that identify the action to take for that feature in the security zone where the URL resides. urlAction settings include enable, disable, prompt, and others as appropriate.

  • urlAction policies: urlAction policies can be added individually by enabling the desired urlAction policy, then selecting the setting for the policy registry key value. They can also be set by zone template.

Internet Explorer will look for a policy in the following order:

  • HKEY_LOCAL_MACHINE policy hive

  • HKEY_CURRENT_USER policy hive

  • HKEY_CURRENT_USER preference hive

  • HKEY_LOCAL_MACHINE preference hive

If Internet Explorer finds a policy in HKEY_LOCAL_MACHINE, it stops and does not continue; that is the setting it respects. If Internet Explorer does not find a policy in HKEY_LOCAL_MACHINE, it looks in the HKEY_CURRENT_USER policy hive, and so on. The administrator can set a policy for one or more urlActions in one or more zones, and allow the end user to manage preferences for urlActions that do not require policy-level security management.

Policy values for urlAction

The new urlAction policies have the same numeric values as their related preference keys. The following table provides a reference to these urlActions:

UrlAction Flag Name

Security Setting User UI

Numeric Name

URLACTION_DOWNLOAD_
SIGNED_ACTIVEX.

Download signed ActiveX controls

1001

URLACTION_DOWNLOAD_
UNSIGNED_ACTIVEX

Download unsigned ActiveX controls

1004

URLACTION_ACTIVEX_RUN

Initialize and script ActiveX controls not marked as safe

1201

URLACTION_ACTIVEX_
OVERRIDE_OBJECT_SAFETY

Run ActiveX controls and plugins

1200

URLACTION_SCRIPT_RUN

Active scripting

1400

URLACTION_SCRIPT_
JAVA_USE

Scripting of Java applets

1402

URLACTION_SCRIPT_
SAFE_ACTIVEX

Script ActiveX controls marked safe for scripting

1405

URLACTION_CROSS_
DOMAIN_DATA

Access data sources across domains

1406

URLACTION_SCRIPT_PASTE

Allow paste operations via script

1407

URLACTION_HTML_
SUBMIT_FORMS

Submit non-encrypted form data

1601

URLACTION_HTML_
FONT_DOWNLOAD

Font download

1604

URLACTION_HTML_
USERDATA_SAVE

Userdata persistence

1606

URLACTION_HTML_
SUBFRAME_NAVIGATE

Navigate sub-frames across different domains

1607

URLACTION_HTML_
META_REFRESH

Allow META REFRESH

1608

URLACTION_HTML_
MIXED_CONTENT

Display mixed content

1609

URLACTION_SHELL_
INSTALL_DTITEMS

Installation of desktop items

1800

URLACTION_SHELL_
MOVE_OR_COPY

Drag and drop or copy and paste files

1802

URLACTION_SHELL_
FILE_DOWNLOAD

File download

1803

URLACTION_SHELL_VERB

Launching applications and files in an IFRAME

1804

URLACTION_SHELL_
POPUPMGR

Use Pop-up blocker

1809

URLACTION_
NETWORK_MIN

Logon

1A00

URLACTION_CLIENT_
CERT_PROMPT

Don't prompt for client certificate selection when no certificates or only one certificate exists

1A04

URLACTION_JAVA_
PERMISSIONS

Java permissions

1C00

URLACTION_CHANNEL_
SOFTDIST_PERMISSIONS

Software channel permissions

1E05

URLACTION_BEHAVIOR_RUN

Script and Binary Behaviors

2000

URLACTION_MANAGED_
SIGNED

Run .NET Framework-reliant components signed with Authenticode

2001

URLACTION_MANAGED_
UNSIGNED

Run .NET Framework-reliant components not signed with Authenticode

2004

URLACTION_FEATURE_
MIME_SNIFFING

Open files based on content, not file extension

2100

URLACTION_FEATURE_
ZONE_ELEVATION

Web sites in less privileged Web content zones can navigate into this zone

2101

URLACTION_FEATURE_
WINDOW_RESTRICTIONS

Allow script-initiated windows without size or position constraints

2102

URLACTION_AUTOMATIC_
DOWNLOAD_UI

Automatic prompting for file downloads

2200

URLACTION_AUTOMATIC_
ACTIVEX_UI

Automatic prompting for ActiveX controls

2201

URLACTION_ALLOW_
RESTRICTEDPROTOCOLS

Allow active content over restricted protocols to access my computer

2300

For more information about using URLaction flags, see “URL Action Flags” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=32776.

The following table provides a reference to the setting options available for each urlAction:

Name

urlAction policy setting options

1001

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1004

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1200

"Administrator approved"=0x00010000

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1201

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1400

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1402

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1405

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1406

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1407

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1601

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1604

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1606

"Enable"=0x00000000

"Disable"=0x00000003

1607

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1608

"Enable"=0x00000000

"Disable"=0x00000003

1609

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1800

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1802

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1803

"Enable"=0x00000000

"Disable"=0x00000003

1804

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

1809

"Enable"=0x00000000

"Disable"=0x00000003

1A00

"Anonymous logon"=0x00030000

"Automatic logon only in Intranet zone"=0x00020000

"Automatic logon with current user name and password"=0x00000000

"Prompt for user name and password"=0x00010000

1A04

"Enable"=0x00000000

"Disable"=0x00000003

1C00

"High safety"=0x00010000

"Medium safety"=0x00020000

"Low safety"=0x00030000

"Custom"=0x00800000

"Disable Java"=0x00000000

1E05

"High Safety"=0x00010000

"Medium Safety"=0x00020000

"Low Safety"=0x00030000

 

 

2000

"Enable"=0x00000000

"Administrator approved"=0x00010000

"Disable"=0x00000003

2001

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

2004

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

2100

"Enable"=0x00000000

"Disable"=0x00000003

2101

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

2102

"Enable"=0x00000000

"Disable"=0x00000003

2200

"Enable"=0x00000000

"Disable"=0x00000003

2201

"Enable"=0x00000000

"Disable"=0x00000003

2300

"Enable"=0x00000000

"Disable"=0x00000003

"Prompt"=0x00000001

Key for numeric translation of URLpolicy settings

Value

Dword

Setting

0

0x00000000

Enable

1

0x00000001

Prompt

3

0x00000003

Disable

65536

0x00010000

High Safety

131072

0x00020000

Medium Safety

196608

0x00030000

Low Safety

For descriptions for each of the URL policy settings, see “URL Action Flags” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=32777.

Default settings for each urlAction in zones and templates

Each urlAction has a default that is set in each zone and set when a specified template is applied. The default settings for each zone are described in the following table:

urlAction Numeric Name

High Security Template Restricted Zone

Medium Security Template Internet Zone

Medium-Low Security Template Intranet Zone

Low Security Template Trusted Zone

Local Machine Zone (LMZ)

The Locked-down local machine zone (LMZ) is a more secure iteration of the security settings for Local Machine Zone (LMZ).This column identifies the settings that differ from the LMZ settings. Locked-down LMZ

1001

3

1

1

0

0

 

1004

3

3

3

1

1

3

1200

3

0

0

0

0

3

1201

3

3

3

1

1

3

1400

3

0

0

0

0

3

1402

3

0

0

0

0

 

1405

3

0

0

0

0

 

1406

3

3

1

0

0

 

1407

3

0

0

0

0

 

1601

1

1

0

0

0

 

1604

1

0

0

0

0

 

1606

3

0

0

0

0

 

1607

3

0

0

0

0

 

1608

3

0

0

0

0

 

1609

1

1

1

1

1

 

1800

3

1

1

0

0

 

1802

1

0

0

0

0

 

1803

3

0

0

0

0

 

1804

3

1

1

0

0

 

1809

0

0

3

3

3

 

1A00

65536

131072

131072

0

0

 

1A04

3

3

0

0

0

3

1C00

0

65536

131072

196608

196608

0

1E05

65536

131072

131072

196608

196608

 

2000

3

0

0

0

0

65536

2001

3

0

0

0

3

3

2004

3

0

0

0

3

3

2100

3

0

0

0

0

3

2101

0

0

0

1

3

3

2102

3

3

0

0

0

3

2200

3

3

0

0

0

3

2201

3

3

0

0

0

3

2300

3

1

1

1

1

N/A

In all security templates (Low, Medium Low, Medium and High), LMZL has the exact same settings for that template as LMZ except as identified in the previous table

Group Policy Settings Paths

  • Group Policy Management Console:

    • HKEY_LOCAL_MACHINE policies by security zone for urlActions:

      \Computer Configuration\Administrative Templates\Windows Components
      \Internet Explorer\Internet Control Panel\Security Page

    • HKEY_CURRENT_USER policies by security zone for urlActions:

      \User Configuration\Administrative Templates\Windows Components
      \Internet Explorer\Internet Control Panel\Security Page

  • Registry (in either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER):

    • Location of Local Machine Zone policy values

      Software\Policies\Microsoft\Windows
      \CurrentVersion\Internet Settings\Zones\0

    • Location of Local Machine Zone Lockdown policy values:

      Software\Policies\Microsoft\Windows
      \CurrentVersion\Internet Settings\Lockdown-Zones\0

    • Location of Intranet Zone policy values:

      Software\Policies\Microsoft\Windows
      \CurrentVersion\Internet Settings\Zones\1

    • Location of Trusted Sites policy:

      Software\Policies\Microsoft\Windows
      \CurrentVersion\Internet Settings\Zones\2

    • Location of Internet Zone policy values:

      Software\Policies\Microsoft\Windows
      \CurrentVersion\Internet Settings\Zones\3

    • Location of Restricted Sites policy values:

      Software\Policies\Microsoft\Windows
      \CurrentVersion\Internet Settings\Zones\4

Configuring Policies and Preferences

Group Policy is the recommended tool for managing Internet Explorer for client computers on a corporate network. Internet Explorer supports Group Policy management for all new Internet Explorer Feature Controls in Windows XP Service Pack 2, and for Security page settings or urlActions. Administrators of Group Policy can manage these new policy settings in the Administrative Templates extension of the Group Policy Management Console.  

When implementing policy settings, it is recommended that you configure template policy settings in one Group Policy object (GPO) and configure any related individual policy settings in a separate GPO. You can then use Group Policy management features (for example, precedence, inheritance, or enforce) to apply individual settings to specific client computers.

Policies can be read by users but can only be changed by via Group Policy management or by an admin. Preference settings can be changed programmatically, by editing the registry, or in the case of urlActions, by using Internet Explorer. Settings specified by Group Policy take precedence over settings specified using preferences.

IEAK/IEM

For operating systems prior to Windows XP SP2 and previous Internet Explorer versions, Internet Explorer Administration Kit (IEAK) 6 Service Pack 1 remains the recommended tool for solution providers and application developers to customize Internet Explorer for their end users IEAK support and the IEAK/IEM process does not change for Internet Explorer versions prior to Windows XP Service Pack 2. The process also has not changed for using IEAK/IEM to set user setting preferences in Internet Explorer versions prior to and including Windows XP Service Pack 2. This includes the new IE6 in XPSP2 preference settings. However, the true policy settings introduced by this feature can only be managed within Group Policy. For information, see “Microsoft Internet Explorer 6 Administration Kit Service Pack 1” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=26002.

Windows XP SP 2 will mark the start of two key changes for IEM/IEAK:

  • Upgrades to IE will only be available via Windows Service Packs and major Windows releases.

  • Starting with Windows XP SP 2, customers will no longer be able to redistribute IE binaries with their IEAK packages. Custom packages that are generated from IEAK 6 SP1 will transparently apply settings to Internet Explorer running on Windows XP SP2, but will not install any binaries.

In summary, the IEAK can still be used as before for all Internet Explorer versions prior to Windows XP Service Pack 2, and is still the tool to use for branding in Windows XP Service Pack 2. IEM/IEAK can be still be used to set user preference settings in Windows XP Service Pack 2, and now true policies can be set using the GPMC.

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

By adding the new Internet Explorer urlAction security setting policies to Group Policy, administrators can manage these true policies to establish standard security settings for all the computers that they configure. The administrator can control these settings in such a way that they cannot be changed except through Group Policy or by a user with administrator privileges thus ensuring that urlAction settings are not set by end-users that override a feature control policy or preference setting.

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

Windows XP Service Pack 2 adds new policies to Group Policy but does not change how policies are managed. Developers need to be aware of how each Feature Control and urlAction setting or setting combination affects security-related behavior for their applications in each security zone.

For greater security, the administrator should enable policies for all zones, so that there is a known configuration set by policy rather than an unknown setting read from HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER preference settings not set by policy. If the administrator sets policies for all zones, we recommend that the policy to disable the Security page be enabled, which will make the user interface in Internet Explorer unavailable.

Feature Control Policies

The administrator should also understand the Feature Control policy settings. Some of the urlAction settings will not be valid unless the corresponding Feature Control policy is enabled. Internet Explorer checks to see if the feature is enabled, and if it is, then looks for the setting for the action based on the security zone of the URL.

Zone Map Policies

The current method for adding Zone Mapkeys to policy is as follows:

  • Add the trusted sites and restricted sites to the registry using the Internet Explorer user interface.

  • Export the hive HKEY_CURRENT_USER\Software\Microsoft
    \Windows\
    CurrentVersion\Internet Settings\ZoneMap into a .reg file

  • Edit that file, and insert the word Policies into the pathname

  • Read the .reg file in, using Administrator permissions

For example, when the export file is created, the path name is:

HKEY_Local_Machine\Software\Microsoft
\Windows\
CurrentVersion\Internet Settings\ZoneMap

To read the .reg keys into the policies hive, the paths should include the addition of policies as shown below, and then be read into the registry by an administrator:

HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap

Following is an example of an exported .reg file, structured to be loaded into the policies hive:

Windows Registry Editor Version 5.00 
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap] 
@="" 
"ProxyByPass"=dword:00000001 
"IntranetName"=dword:00000001 
"UNCAsIntranet"=dword:00000001 
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains] 
@="" 
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoft.com] 
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoft.com\msdn] 
"http"=dword:00000002 
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults] 
@="" 
"http"=dword:00000003 
"https"=dword:00000003 
"ftp"=dword:00000003 
"file"=dword:00000003 
"@ivt"=dword:00000001 
 
[HKEY_CURRENT_USER\Software\Policies\Microsoft
\Windows\CurrentVersion\Internet Settings\ZoneMap\Ranges] 
@=""

Notes   For more information on using Group Policy, see "Implementing Registry-based Group Policy" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=28188.

For more information on using Internet Explorer security zone and privacy settings, see "Description of Internet Explorer Security Zones Registry Entries" on the Microsoft Knowledge Base Web site at http://go.microsoft.com/fwlink/?LinkId=28195.

Internet Explorer Local Machine Zone Lockdown

What Does Local Machine Zone Lockdown do?

When Internet Explorer opens a Web page, it places restrictions on what the page can do, based on the page’s Internet Explorer security zone. There are several possible security zones, each with different sets of restrictions. The security zone for a page is determined by its location. For example, pages that are located on the Internet will normally be in the more restrictive Internet security zone. They might not be allowed to perform some operations, such as accessing the local hard drive. Pages that are located on your corporate network would normally be in the Intranet security zone, and have fewer restrictions. The precise restrictions that are associated with most of these zones can be configured by the user through Internet Options on the Tools menu.

Prior to Windows XP Service Pack 2, the content on the local file system, aside from that cached by Internet Explorer, was considered to be secure and was assigned to the Local Machine security zone. This security zone normally allows content to run in Internet Explorer with relatively few restrictions. However, attackers often try to take advantage of the Local Machine zone to elevate privilege and compromise a computer.

Many of the exploits that involve the Local Machine zone will be mitigated by other changes to Internet Explorer in Windows XP SP2. However, attackers may still be able to figure out ways to exploit the Local Machine zone. Windows XP SP2 further protects the user by locking down the Local Machine zone in Internet Explorer by default. Local HTML hosted in other applications will run under the less restrictive, previous default settings of the Local Machine zone unless that application makes use of Local Machine Zone Lockdown.

Administrators will be able to use Group Policy to manage Local Machine Zone Lockdown and more easily apply it to groups of computers.

Who does this feature apply to?

All application developers should review this feature. Applications that host local HTML files in Internet Explorer are likely to be impacted. Developers of stand-alone applications that host Internet Explorer will want to modify their applications to make use of Local Machine Zone Lockdown.

By default, Local Machine Zone Lockdown is only enabled for Internet Explorer. Developers will need to register their applications to take advantage of the changes. Applications that do not use this mitigation should independently review their applications for Local Machine zone attack vectors.

Software developers with applications that host Internet Explorer should use this feature by adding their process name to the registry as described later in this document. In the future, Microsoft might implement this feature using an “opt-out” policy rather than an “opt-in” policy. Applications that host Internet Explorer should be tested to ensure that they function properly with Local Machine Zone Lockdown enabled for their process.

Network Administrators might have local scripts that will be affected by these restrictions. Administrators should review the available solutions to enable their local scripts without compromising the security of their user's client computers.

Developers of Web sites that are hosted on the Internet or Local Intranet zones should not be affected by changes to the Local Machine zone.

Users could be impacted by applications that are not compatible with these more stringent restrictions.

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

Changes to Local Machine Zone Security Settings

Detailed description

With Windows XP Service Pack 2, Local Machine Zone Lockdown will be even more restrictive than the Internet zone. Any time that content attempts one of these actions, the Information Bar will appear in Internet Explorer with the following text:

To help protect your security, Internet Explorer has restricted this file from showing active content that could access your computer. Click here for options...

The user can click the Information Bar to remove the lockdown from the restricted content.

The security settings that control the privileges that are granted to content running in the Local Machine zone are known as URL actions. When Local Machine Zone Lockdown is applied to a given process, it changes the behavior of URL actions from the previous Local Machine zone setting of Allow to Disallow. As a result, scripts and Active X controls will not run. The default URL actions changed are:

  • URLACTION_RUN_SCRIPT

  • URLACTION_DOWNLOAD_UNSIGNED_ACTIVEX

  • URLACTION_ACTIVEX_RUN

  • URLACTION_ACTIVEX_OVERRIDE_OBJECT_SAFETY

  • URLACTION_CLIENT_CERT_PROMPT

  • URLACTION_BEHAVIOR_RUN

  • URLACTION_JAVA_PERMISSIONS

For Local Machine Zone Lockdown, these settings are stored under a separate registry key:

HKEY_CURRENT_USER\Software\Microsoft
\Windows\CurrentVersion\Internet Settings\Lockdown_Zones\0

The default Local Machine zone URL action settings are found under:

HKEY_CURRENT_USER\Software\Microsoft
\Windows\CurrentVersion\Internet Settings\Zones\0

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

This change helps prevent content on a user’s computer from elevating privilege. Code with such elevated privilege can then run any code through an ActiveX control or read information with a script.

What works differently? Are there any dependencies?

If a Web page uses any of the restricted types content that were previously listed, Internet Explorer displays the Information Bar, as previously described.

HTML files that are hosted on the res: protocol on the local computer will automatically run under the security settings for the Internet zone. For more information about what these templates allow, see “Introduction to URL Security Zones” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=26003.

How do I resolve these issues?

You can allow Active X and scripts to always run in Web pages that are launched from a CD by clicking “Yes” when presented with the following message:

Active content can harm your computer or disclose personal information. Are you sure that you want to allow CDs to run active content on your computer?

If your Web page needs to run ActiveX or scripting, you can add a Mark of the Web comment in the HTML code. This Internet Explorer feature allows the HTML files to be forced into a zone other than the Local Machine zone so that they can then run the script or ActiveX code based on the security template that would be applied to the URL identified in the comment. For example if the URL specified was www.contoso.com and that URL was present in your trusted sites list, the page would use the security template for the trusted sites zone. This setting works in Internet Explorer 4 and later. To insert a Mark of the Web comment into your HTML file, add one of the following comments:

<!-- saved from url=(0022)http://www. yoururl .com -->

Use this comment when you are inserting a Mark of the Web into a page whose domain is identified, replacing http://www.yoururl.com with the URL of the Internet or intranet domain that the page is hosted by. Include the length of the URL in parenthesis used for the Mark of the Web before the URL, for example (0022).

If you want your Web page to always be treated as though it were part of the Internet zone, you can use the following Mark of the Web:

<!-- saved from url=(0013)about:internet -->

Use this comment when you need to generically insert a Mark of the Web. The about:internet portion will place the page in the Internet zone.

As part of the changes to Internet Explorer in Windows XP SP2, this HTML comment can also be used with .mht files, known as multipart HTML or .xml files. Mark of the Web will not be respected for .mht or .xml files in earlier versions of Internet Explorer.

As another option, you can create a separate application that hosts the HTML content in the Internet Explorer Web Object Control (WebOC). The HTML is then no longer bound by the same rules that apply to content run in Internet Explorer. When the HTML content runs in the other process, it can have full rights as defined by the developer or the zone policy for that process.

An easy way to do this is to save your content as an .hta (HTML application) file and try to run the file again in the Local Machine zone. An .hta file is hosted in a different process and therefore is not impacted by the mitigation. However, .hta files run with full privileges, so you should not allow code that is not trusted to run in this manner.

Do I Need to Change My Code to Work With Windows XP Service Pack 2?

Developers should test their applications and enable the lockdown in order to offer enhanced levels of security. Developers of stand-alone applications should plan to adopt these changes in their applications that host Internet Explorer.

Developers of ActiveX controls that previously allowed elevated privileges in the Local Machine zone should not change their controls to allow elevated privileges in another zone. Instead, these controls should be converted to run only from an HTML application (.hta file) or a stand-alone application that runs outside of Local Machine Zone Lockdown.

By default, Local Machine Zone Lockdown is not enabled for non-Internet Explorer processes. Developers must explicitly register their applications to take advantage of the changes. Application developers that do not use this mitigation should independently review their applications for Local Machine zone attack vectors. To enable Local Machine Zone Lockdown for your application, go to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Internet Explorer\Main\FeatureControl
\FEATURE_LocalMachine_Lockdown

Add a REG_DWORD value to this key named for your application (for example, MyApplication.exe) and set it to 1. Any other setting for this value will disable Local Machine Zone Lockdown for the application.

Internet Explorer MIME Handling Enforcement

What does MIME Handling Enforcement do?

Internet Explorer uses Multipurpose Internet Mail Extensions (MIME) type information to decide how to handle files that have been sent by a Web server. For example, when there is a Hypertext Transfer Protocol (HTTP) request for .jpg files, when they are received, they will generally be displayed to the user in an Internet Explorer window. If Internet Explorer receives an executable file, Internet Explorer generally prompts the user for a decision on how to handle the file.

In Windows XP Service Pack 2, Internet Explorer will follow stricter rules that are designed to protect users from accidentally downloading or executing a dangerous file due to misleading MIME or file name extension information.

Who does this feature apply to?

Web developers need to be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.

Application developers should review this feature to plan to adopt changes in their applications. The feature is not enabled for non-Internet Explorer processes by default and developers will need to register their applications to take advantage of the changes.

End users will be impacted by sites or applications that are not compatible with these stricter rules.

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

MIME-handling file type agreement enforcement

Detailed description

When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file:

  • File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension.

  • Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type.

  • Content-Disposition from the HTTP header.

  • Results of the MIME sniff.

In Windows XP Service Pack 2, Internet Explorer is more restrictive about executing a downloaded file that could be dangerous.

Internet Explorer will enforce consistency between how a file is handled in the browser and how it is handled in the Windows Shell. As the file is downloaded into the cache, Internet Explorer will compare the MIME-type of the cache file to the extension of the cache file. If there is a mismatch between the MIME-type and the file name extension, Internet Explorer will attempt to reconcile that mismatch by renaming the file in the cache.

Before a file is loaded in its MIME handler or executed by its extension handler, Internet Explorer will compare the CLSIDs of the MIME handler and the extension handler. If there is a still a mismatch between the two handlers, Internet Explorer will impose a mandatory prompt for the use to confirm that they want to load the file in the MIME handler. If the MIME handler rejects the mismatched file, Internet Explorer will show a download error dialog and not automatically execute the file in the Windows shell extension handler.

There is a related but separate change to prevent execution of potentially corrupt files in their shell extension handlers. Internet Explorer will show the download error dialog for any file that is rejected by its MIME handler with the error code E_Cannot_Load_Data and will not execute that file in its shell extension handler regardless of MIME-type or file name extension.

These changes do not affect cases where a “content-disposition=attachment” HTTP header is used for the file. In those cases, the file name or extension suggested by the server is considered final and the file can be executed regardless of MIME/extension mismatch if the user chooses to accept the file download prompt.

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

If file type information is misreported by the server and that information is saved to the computer, a dangerous file could be incorrectly executed later. For example, Internet Explorer might download a file that appears to be a text file. If the file can’t be loaded by its MIME handler and has a .doc file name extension, the .doc file might run in an application such as Microsoft Word without prompting the user. In Microsoft Word, the file may be able to use active content, such as a macro, to run a program (such as a virus) on the user’s machine.

What works differently? Are there any dependencies?

Internet Explorer will now attempt to rename downloaded files in the Internet Explorer cache to have matching content types and extensions to protect against files that mislead the user about their type.

Internet Explorer will prompt the user to download the file and will no longer execute MIME and extension mismatched files that are rejected by the registered MIME handler.

Internet Explorer will also not execute a file in its shell handler if the E_Cannot_Load_Data error code was reported by its MIME handler.

Web developers can isolate non-working applications due to this behavior by switching off the functionality, as covered in the Settings section later in this document.

How do I resolve these issues?

Web developers must change their Web servers to host files, using consistent content-type headers and file name extensions. If this is not possible, Web developers can use the “Content-disposition=attachment: HTTP header to directly send the file to its extension handler rather than to the MIME handler. Note that file downloads with the “Content-disposition=attachment” header will prompt the user to open or save the file.

If you have developed a MIME handler and intentionally rely on Internet Explorer to execute files that your MIME handler rejects, you will need to make changes in your MIME handler to accommodate this change. The most secure change would be to natively handle the file directly in the MIME handler rather than rejecting the file.

For some scenarios, it may not be possible to change the behavior of the MIME handler to natively handle downloaded files. In those scenarios, there are a few options:

  • You may choose to develop a MIME handler and file name extension handler that are both part of the same CLSID, Internet Explorer will accept the CLSID match and therefore not prompt the user to download the file or block the file from execution in the extension handler.

  • If the MIME handler does not need to be loaded and will cause errors due to MIME and extension mismatch, the developer can mark the MIME handler to be ignored by Internet Explorer in the case of a MIME and extension mismatch. For example, if the MIME handler for a certain media MIME type has a mismatched extension and needs to be executed directly to be played properly, the developer can mark the ProgID of their MIME handler to be ignored on the mismatch when the media file name extension belongs to a different ProgID. To do this, the developer sets the following value in the registry with the MIME handler to ignore:

    HKEY_CLASSES_ROOT\PROG_ID_OF_MIMEHANDLER_TO_IGNORE\

    ”PreferExecuteOnMismatch”=DWORD:00000001

    If neither of these solutions are viable, the developer should notify their users of the incompatibility and explain to the user how to save the mismatched file to the file system and then launch it manually.

    If your scenario is impacted by unwanted file-download prompts because of an irreconcilable MIME/extension mismatch, you can register you MIME handler ProgID to bypass all download prompts including the new prompt on mismatch.

    Before doing this, you should confirm that your MIME handler can securely deal with any file that is delegated to it. For example, you should confirm that your handler would never allow an attacker to gain more privilege than allowed by the zone of the originating file. This should be done through threat modeling, code review for secure failure modes, and buffer overruns. If you determine that your MIME handler is capable of safely handling any file that might be delegated to it, you can register your handler to circumvent download prompts by adding a new key to one of the following registry settings:

    HKEY_LOCAL_MACHINE\Software\Microsoft
    \Windows\
    CurrentVersion\InternetSettings\Secure_Mime_Handlers

    HKEY_CURRENT_USER\Software\Microsoft
    \Windows\
    CurrentVersion\InternetSettings\Secure_Mime_Handlers

    The key should be named with the ProgID of your MIME handler and have a DWORD=00000001.

MIME sniffing file type elevation

Detailed description

One of the backup criteria for determining a file type is the result of the MIME sniff. By examining (or sniffing) a file, Internet Explorer can recognize the bit signatures of certain types of files. In Windows XP Service Pack 2, Internet Explorer MIME sniffing will not promote files of type text\plain to more dangerous file types in the restricted sites zone. For example, files that are received as plain text but that include HTML code will not be promoted to the HTML type, which could contain active content.

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

This change provides users additional defense in depth against malicious content posted on a friendly Web server where the server serves files with content-type=text\plain for a file but an attacker has managed to load HTML with active content into the file.

What works differently? Are there any dependencies?

Web servers that do not include the correct Content-Type header with their files and that use non-standard file name extensions for HTML pages now may have their pages rendered as plain text rather than HTML.

How do I resolve these issues?

You should configure Web servers to use the correct Content-Type headers or you can name the files with the appropriate file name extension for the application that should handle the file.

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

Setting name

Location

Previous default value (if applicable)

Default value

Possible values

IExplore.exe

Explorer.exe

HKEY_LOCAL_MACHINE(or Current User)
\Software \Microsoft \Internet Explorer
\Main\FeatureControl
\FEATURE_
MIME_HANDLING\

None

1

0 - Off

1 - On

IExplore.exe

Explorer.exe

HKEY_LOCAL_MACHINE(or Current User)
\Software \Microsoft \Internet Explorer
\Main\FeatureControl
\FEATURE_
MIME_SNIFFING\

None

1

0 - Off

1 - On

MIME Sniffing behavior per-zone

The new MIME sniffing restriction is controlled by the Open files based on content, not file extension security setting which can be enabled or disabled for individual security zones. The following table provides a reference of the default settings per security zone:

Security Zone

“Open files based on content, not file extension” Security Setting

Restricted Sites Zone

Disable

Internet Zone

Enable

Intranet Zone

Enable

Trusted Sites Zone

Enable

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

You should configure Web servers to use the correct Content-Type headers. You can also name the files with the appropriate file name extension for the application that should handle the file.

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 cached objects (except for ActiveX controls) are 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?

Setting name

Location

Previous default value (if applicable)

Default value

Possible values

IExplore.exe

Explorer.exe

HKEY_LOCAL_MACHINE (or Current User)
\Software \Microsoft \Internet Explorer
\Main\FeatureControl
\FEATURE_
OBJECT_CACHING

None

1

0 - Off

1 - On

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();

Internet Explorer Pop-up Blocker

What does Pop-up Blocker do?

Pop-up Blocker blocks most unwanted pop-up windows from appearing. Pop-up windows that are opened when the end user clicks a link will not be blocked.

End users and IT administrators can let specific domains open programmatic pop-up windows. Developers will be able to use or extend the pop-up functionality in Internet Explorer for applications hosting Internet Explorer.

Who does this feature apply to?

For most end users, browsing the Web will be less annoying, because unwanted pop-up windows will not automatically appear.

For Web developers, Pop-up Blocker affects the behavior of windows opened by Web sites, for example, by using the window.open() and showHelp() methods

For application developers, there is a new user interface called INewWindowManager.

Applications that use the rendering engine in Internet Explorer to display HTML can choose to use or extend the Pop-up Blocker functionality.

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

The Pop-up Blocker is a new feature for Internet Explorer which can be broken down into three sections:

  • User experience changes, defaults, and advanced options.

  • Changes in behavior of current application programming interfaces (APIs), such as window.open and showHelp.

  • The new INewWindowManager interface which allows applications to use the pop-up technology in Internet Explorer.

Pop-up Blocker features

Detailed description

Defaults

Pop-up Blocker is turned on by default. There are restrictions on the size and position of pop-up windows, regardless of the Pop-up Blocker setting. Pop-up windows cannot be opened larger than or outside the viewable desktop area. For more information, see “Windows Restrictions” in this document.

When this functionality is enabled, automatic and background pop-up windows are blocked, but windows that are opened by a user click will still open in the usual manner. Note that sites in the Trusted Sites and Local Intranet zones never have their pop-up windows blocked, as they are considered safe. This can be configured in the Security tab in Internet Options.

Enabling Pop-up Blocker

Pop-up Blocker is enabled by default. You can change this in the Tools menu, with the Pop-up Blocker item, or in the Information Bar when a pop-up is blocked.

When a pop-up window is blocked

If a site opens a pop-up window that is blocked by Internet Explorer, a notification appears in the Information Bar and status bar and a sound is played. If you click the notification in the Information Bar or status bar, you see a menu with the following options:

  • Temporarily Allow Pop-ups. Reloads the page, allowing pop-up windows.

  • Always Allow Pop-ups from This Site. Adds the current site to the Allow list.

  • Settings. Shows more Pop-up Blocker settings menu items and gives access to the Pop-up Blocker Settings window.

Advanced options

Internet Explorer provides advanced configuration of Pop-up Blocker settings.

  • Web site Allow List

    You can add sites to the Allow list. Any site on the Allow list can open pop-up windows.

  • Block All Pop-up Windows

    Pop-up Blocker allows sites to open a pop-up window when the user clicks a link. This setting changes that behavior by blocking windows that are opened from a link. If this setting is enabled, you can allow pop-up windows to open by pressing the CTRL key at the same time that you launch the pop-up.

  • Override Key

    You can allow pop-up windows to open by pressing CTRL while the pop-up is opening.

  • Configure Sound

    You can toggle whether or not Pop-up Blocker plays a sound when a pop-up is blocked through the Advanced settings in Internet Options. You can also change the sound that plays. To do this, click Start, click Control Panel, and then double-click the Sounds and Audio Devices icon, and then specify the Blocked Pop-up Window system sound.

  • Zones

    Customers can expand the scope of Pop-up Blocker to include the Local Intranet or Trusted Sites zones in the Security tab of Internet Options.

When will end users see pop-up windows while Pop-up Blocker is enabled?

Customers will still see pop-ups windows opened in the following cases:

  • The pop-up is opened by a link which the user clicked.

  • The pop-up is opened by software that is running on the computer.

  • The pop-up is opened by ActiveX controls that are instantiated from a Web site.

  • The pop-up is opened from the Trusted Sites or Local Intranet zones.

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

Pop-ups have been misused in many ways. By blocking pop-ups, the customer has more control over their browsing experience.

INewWindowManager

Detailed description

By default, the Pop-up Blocker functionality does not apply to applications that host the WebBrowser control or MSHTML. These applications have the ability to use or extend Pop-up Blocker, use their own Pop-up Blocker, or disable pop-up management for their application through the INewWindowManager interface.

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

Methods: window.open(), window.external.navigateAndFind(), showHelp()

Detailed description

In the Internet zone, the Pop-up Blocker blocks windows that are automatically opened by these methods without the user clicking a link. Windows that are opened by these methods by clicking a link might also be blocked if the customer has enabled the more restrictive blocking setting.

If a function normally returns a window object, then the function will return null when a window is blocked. Web developers can check for null to determine whether the window they attempted to open was blocked.

Windows that are outside the viewable screen when they are opened are positioned onto the viewable area.

Windows that are larger than the viewable screen when they are opened are resized to the viewable area.

For more information, see “Internet Explorer Window Restrictions” in this document.

How do I resolve these issues?

Ensure that all windows that are opened with window.open() are opened through user interaction and not automatically through your code.

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

Setting name

Location

Previous default value (if applicable)

Default value

Possible values

URLname

HKEY_CURRENT_USER
\Software\Microsoft
\Internet Explorer
\New Windows\Allow

None

Empty

URL names of trusted sites

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

Web page authors should check for a NULL return value for any windows that you open. This will indicate whether the pop-up window opened successfully and allow you to handle either case.

If your software opens windows automatically, they will be blocked. Look for alternative ways of doing the same thing as described earlier in this document. The best way to open a window is to have the customer click a link or graphical element.

Internet Explorer Untrusted Publishers Mitigations

What does Untrusted Publishers Mitigations do?

This feature allows the user to block all signed content from a given publisher without showing the Authenticode dialog box to the user while doing so. This stops code from the blocked publisher to be installed. This feature also blocks installation of code with invalid signatures.

Who does this feature apply to?

This feature applies to all users, since it deals with installation and running of applications that are signed.

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

Blocked Publisher

Detailed description

Through Authenticode, the user can block content for a given publisher from installing or running. To do this, the user selects the Never trust content from PublisherName check box in the Authenticode dialog box. If selected, the user is never prompted when code that is identified with the publisher’s digital signature is trying to install itself on their system. It will be automatically blocked without showing the Authenticode dialog box.

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

This feature was designed to help users block ActiveX controls and other signed file formats from repeatedly prompting them on the Web. Users had no way of saying, “I don’t want content from this publisher. Do not ask me again.” Because they didn’t have this feature, many users installed applications or content just to keep from encountering repeated prompts.

What works differently?

Previously, the Authenticode dialog box only supported selecting the Always trust content from Publisher check box, which allowed the automatic install of code from a specified publisher without prompting the user. Now the user can perform the opposite action and designate a publisher as untrusted. No application compatibility issues should be encountered for trusted code.

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

Blocking Invalid Signatures

Detailed description

By default, Windows blocks the installation of signed code if it has an invalid digital signature.

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

If code has an invalid signature, it usually means that the code has been changed since it was signed. When this happens, Internet Explorer considers the code to be unsigned, since someone might have tampered with it. By default, Internet Explorer blocks ActiveX applications that are unsigned that come from the Internet zone. This extends that functionality so that it applies to all code with invalid signatures.

What works differently?

By default, code with invalid signatures cannot be installed.

How do I resolve these issues?

To revert to previous functionality and allow unsigned code to run, see the RunInvalidSignatures setting in the “What settings are added or changed in Windows XP Service Pack 2?” section below.

One prompt per control per page

Detailed description

Internet Explorer only prompts once per ActiveX control per page.

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

This change helps defend against the social engineering trick of prompting the user a number of times for the same control. Even though users repeatedly refuse, they cannot get out of the loop, and they might eventually accept the installation out of frustration.

What works differently?

The user only sees one prompt per page per control.

Ellipsis placed on text for application description and publisher name

Detailed description

When the text that is given for the application description, file name, or publisher name is wider than the dialog box in width, Internet Explorer places an ellipsis on the text. This helps indicate to the user that there is more text that they are not seeing.

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

This reduces the ability of control authors from placing marketing text and EULAs in the dialog box or using other social engineering tricks to overwhelm the users and get them to install the control.

What works differently?

Application description, file names, and publisher names will contain an ellipsis if the text is longer than the width of the dialog box. No applications or Web pages should need to be modified.

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

Setting name

Location

Previous default value (if applicable)

Default value

Possible values

RunInvalid
Signatures

HKEY_CURRENT_USER
\Software \Microsoft
\Internet Explorer \Download

HKEY_LOCAL_MACHINE
\Software \Microsoft
\Internet Explorer \Download

None

0

1

Internet Explorer Window Restrictions

What does Window Restrictions do?

Internet Explorer provides the capability for scripts to programmatically open additional windows of various types, and to resize and reposition existing windows. The Window Restrictions security feature, formerly called UI Spoofing Mitigation, restricts two types of script-initiated windows that have been used by malicious persons to deceive users: popup windows (which do not have components such as the address bar, title bar, status bar, and toolbars) and windows that include the title bar and status bar.

Who does this feature apply to?

Web developers should be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.

Application developers should review this feature to plan to adopt changes in their applications. This feature is only enabled by default for Internet Explorer processes. Developers must register non-Internet Explorer applications to take advantage of the changes

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

Script repositioning of Internet Explorer windows

Detailed description

Script-initiated windows with the title bar and status bar are constrained in scripted movement to ensure that these important and informative bars remain visible after the operation completes.

  • Scripts cannot position windows so that the title bar or address bar are above the visible top of the display.

  • Scripts cannot position windows such that the status bar is below the visible bottom of the display.

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

Without this change, windows that are created by the window.open() method can be called by scripts and used to spoof a user interface or desktop or to hide malicious information or activity by one of the three following methods:

  • Positioning the window such that the title bar, status bar, or address bar are off-screen.

  • Positioning the window to hide important elements of the user interface from the user.

  • Positioning the window so that it is entirely off-screen.

The visible security features of Internet Explorer windows provide information to the user to help them ascertain the source of the Web page and the security of the communication that uses that page. When these elements are hidden from view, the user might think they are on a more trusted page or interacting with a system process when they are actually interfacing with a malicious host. Malicious use of window relocation can present false information to the user, obscure important information, or otherwise “spoof” important elements of the user interface in an attempt to motivate the user to take unsafe actions or to divulge sensitive information.

What works differently? Are there any dependencies?

This change places constraints on positioning of script-initiated windows with a title bar and status bar, to ensure that the title bar and status bar in these windows are always visible to the user. Scripts cannot move a window off-screen, although the user can still move a window off-screen. If you maintain a script that creates off-screen windows in Internet Explorer, you need to change your code.

How do I resolve these issues?

If your script creates or moves a window off-screen, you should examine this requirement and alternate ways to accomplish your goal.

Script sizing of Internet Explorer windows

Detailed description

Script-initiated windows that include a title bar and status bar are constrained in scripted sizing to ensure that the title bar and status bar remain visible after the operation completes.

  • Scripts cannot resize windows such that the title bar, address bar, or status bar cannot be seen.

  • When creating a window, the definition of the fullscreen=yes specification is changed to mean “show the window as maximized,” which will keep the title bar, address bar, and status bar visible.

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

Without this change, windows that are created using the window.open() method can be called by scripts and used to spoof a user interface or desktop or to hide malicious information or activity by sizing the window so that the status bar is not visible.

Internet Explorer windows provide visible security information to the user to help them ascertain the source of the Web page and the security of the communication with that page. When these elements are not in view, the user might think they are on a more trusted page or interacting with a system process when they are actually interacting with a malicious host. Malicious uses of window sizing can obscure important security-related information, and otherwise spoof important elements of the user interface in an attempt to motivate the user to take unsafe actions or to divulge sensitive information

What works differently? Are there any dependencies?

With this change, there are constraints on sizing of script-initiated windows to ensure that the title bar and status bar of these windows is always visible to the user. The result is that a script cannot open a window in kiosk mode, a mode that does not display the title bar, address bar, and status bar, which present important security information to the user.

The user can choose to display a window in kiosk mode. This election is still persistent.

How do I resolve these issues?

Script-initiated windows will be displayed fully, with the Internet Explorer title bar and status bar. The user or the site administrator can manually change this state.

Script management of Internet Explorer status bar

Detailed description

Internet Explorer has been modified to not turn off the status bar for any windows. The status bar is always visible for all Internet Explorer windows.

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

Without this change, windows that are created using the window.open() method can be called by scripts and spoof a user interface or desktop or hide malicious information or activity by hiding important elements of the user interface from the user.

The status bar is a security feature of Internet Explorer windows that provides Internet Explorer security zone information to the user. This zone cannot be spoofed, and lets the user know exactly what security zone the displayed content is in. When the status bar is hidden from view, the user might think they are on a more trusted page when they are actually interacting with a malicious host.

What works differently? Are there any dependencies?

For a script-initiated window, by default, the status bar is always on so that the security zone is visible to the user. There should be no change to applications.

Internet Explorer pop-up window placement

Detailed description

Script-initiated popup windows are now constrained so that they:

  • Do not extend above the top or below the bottom of the parent Internet Explorer Web Object Control (WebOC) window.

  • Are smaller in height than the parent WebOC window.

  • Overlap the parent window horizontally.

  • Stay with the parent window if the parent window moves.

  • Appear above its parent so other windows (such as a dialog box) cannot be hidden.

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

Popup windows are created by the window.createPopup() method and are also called chromeless windows because they do not have the border “chrome” components, such as the address bar, title bar, status bar, and toolbars. These windows:

  • Can be opened on top of a dialog box and obscure or replace important elements.

  • Can be used to overlay the address bar with a different address.

  • Can simulate a full-screen Windows desktop with a password dialog box.

Unrestricted chromeless windows can deceive the user in several ways:

  • A chromeless popup window that is opened on top of a dialog box can obscure or replace important elements of the dialog box, such as warning text and selection or action controls. (These include check boxes, option buttons, and so on.) This might lead the user to a response that might be inappropriate or harmful.

  • A chromeless popup window can overlay the address bar with an address that is different from the actual address of the page, which gives the user a false sense of security. In the same way, it can overlay the status notification area, so it might indicate that Internet Explorer is displaying a secure Web page (which displays a URL beginning with https://) Because of this, the user might think that security is in effect for the page when no such security exists.

  • A chromeless popup can use the entire display. With this method, a malicious user can simulate a full-screen Windows desktop with a password dialog box, with a malicious script that captures the user’s private authentication information.

What works differently? Are there any dependencies?

Popup windows are constrained horizontally, vertically, and in order of placement on top of other windows.

  • A popup window must appear between the top and bottom of its parent window’s chrome, so it does not overlap the Internet Explorer address bar, title bar, status bar, or toolbars.

  • Horizontally, a popup window must always overlap some area of its parent window.

  • A popup window must stay immediately on top of its parent, so it cannot be placed over other windows.

These constraints might affect the appearance of a popup window if it has been designed to display in an area that is larger or separate from its parent window. The pop-up windows will be truncated, which might obscure some of the information displayed on that window.

How do I resolve these issues?

Redesign the popup window to fit into the constraints of this mitigation.

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

There is only one setting for this feature. This setting enables the Windows Restrictions (1) or does not enable them (0). For application compatibility, this feature is not enabled by default for non-Internet Explorer processes.

Setting name

Location

Previous default value

Default value

Possible values

IExplore.exe

HKEY_LOCAL_MACHINE
(or Current User)\Software
\Microsoft \Internet Explorer
\Main \FeatureControl
\FEATURE_WINDOWS_
RESTRICTIONS\

Not applicable.

1

0 (off)

1(on)

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

The script will call the same methods for the creation of an Internet Explorer window with chrome (using the window.open() method) or an Internet Explorer chromeless popup window (using the window.createPopup() method). However, the design might need to be reviewed to ensure that popup windows are appropriately visible to the user and that the status bar contains accurate information.

Internet Explorer Zone Elevation Blocks

What does Zone Elevation Blocks do?

When a Web page is opened in Internet Explorer, Internet Explorer puts restrictions on what the page can do, based on where that Web page came from: the Internet, a local intranet server, a trusted site, and so on. For example, pages on the Internet have stricter security restrictions than pages on a user’s local intranet. Web pages on a user’s computer are in the Local Machine security zone, where they have the fewest security restrictions. This makes the Local Machine security zone a prime target for malicious users. Zone Elevation Blocks makes it harder to get code to run in this zone. In addition, Local Machine Zone Lockdown makes the zone less vulnerable to malicious users by changing its security settings.

Who does this feature apply to?

Web developers must plan changes or workarounds for any possible impact to their Web site.

Application developers should review this feature to plan to adopt changes in their applications that run in the Local Machine security zone. Since the feature is not enabled for processes other than Internet Explorer by default, developers must register their applications to take advantage of the changes.

End users might be impacted by sites that are not compatible with these stricter rules and settings.

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

Zone Elevation Blocks

Detailed description

Internet Explorer prevents the overall security context for any link on a page from being higher than the security context of the root URL. This means, for example, that a page in the Internet zone cannot navigate to a page in the Local Intranet zone. A script, for example, could not cause this navigation. For the purpose of this mitigation, the security context ranking of the zones, from highest security context to lowest, is: Restricted Sites zone, Internet zone, Local Intranet zone, Trusted Sites zone, and Local Machine zone.

Zone Elevation Blocks also disables JavaScript navigation if there is no security context.

If a user clicks a link which causes the Web site to attempt to navigate to a higher zone, navigation is blocked for navigation to the Local Machine, or a dialog will appear in Internet Explorer with one of two messages. The italicized portions change, according to the situation.

  • The current Internet site is trying to open a file that is on your Trusted sites list.

    If you trust this Internet site, proceed by clicking OK.    

  • The current site is in your Restricted sites list and is trying to open a file that is on the Intranet. We recommend that you do not allow this.

In both cases, the default action does not allow the zone elevation. The user must explicitly allow the requested zone elevation.

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

Elevation of privilege is one of the most exploited vulnerabilities in Internet Explorer, with the ultimate goal of running malicious code in the Local Machine zone. Zone Elevation Blocks helps mitigate many privilege escalation attacks.

What works differently?

Navigation from one zone to a “higher” zone is blocked. This means that Web pages that automatically call more privileged Web pages fail.

How do I resolve these issues?

If a trusted Web application cannot be used, you can modify the Internet Explorer security zone settings to allow the application to continue working. You can change the zone elevation setting under for each security zone by setting the registry key 2101 from Disabled to Prompt or Allow. For example, to change the Local Machine Zone Lockdown setting, you would change the key as follows:

HKEY_CURRENT_USER\Software\Microsoft
\Windows\CurrentVersion\Internet Settings\Lockdown_Zones\0

"2101"=dword:00000001 to Prompt

"2101"=dword:00000000 to Allow

Internet Explorer Network Protocol Lockdown

What Does Network Protocol Lockdown Do?

In the RTM release of XP SP2, Internet Explorer can be configured to lockdown HTML content from particular network protocols in additional zones besides the local machine zone. This feature allows an administrator to extend the same restrictions of the Local Machine Zone Lockdown (which is described previously in this document) to be applied to any content on any arbitrary protocol in any security zone. For example, an administrator can configure Internet Explorer to lock down HTML content hosted on the Shell: protocol if it is in the Internet zone. Since the Shell: protocol’s most common use is for local content and not Internet content, this mitigation can reduce the attack surface of the browser against possible vulnerabilities in protocols less commonly used than HTTP.

Who does this feature apply to?

By default, Network Protocol Lockdown is not enabled for any application.

All application developers should review this feature. Applications that host HTML files over non-HTTP protocols in Internet Explorer may be impacted in organizations where administrators elect to apply additional restrictions. Developers of stand-alone applications that host Internet Explorer might want to modify their applications to make use of Network Protocol Lockdown.

Developers who chose to opt-in should to register their applications to take advantage of the changes. Applications that do not use this mitigation should independently review their applications for support for arbitrary protocols.

Software developers with applications that host Internet Explorer can use this feature by adding their process name to the registry as described later in this document. In the future, Microsoft might implement this feature with certain uncommonly used protocols restricted by default and with an “opt-out” policy for applications rather than the current “opt-in” policy for applications. Applications that host Internet Explorer should be tested to ensure that they function properly with Network Protocol Lockdown enabled for their process.

Network Administrators should consider adding un-used protocols to the restricted protocol list on managed desktop machines. If the network admin enables this restriction, they may have HTML files that will be affected.

Developers of Web sites that are hosted on the HTTP protocol should not be affected by restrictions to other protocols.

Users are most likely to be impacted by these more stringent restrictions if their Network Administrator chose to restrict certain protocols for their desktop.

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

Changes to Security Settings for Restricted Protocols
Detailed description

With Windows XP Service Pack 2, HTML content in an opt-ed in application that is served on one of the restricted protocols will be restricted to run at a higher security level. Any time the restricted protocol content attempts to use a restricted feature, such as ActiveX controls for example, the Information Bar will appear in Internet Explorer with the following text:

The webpage is trying to communicate in a way that may be unsafe. Click here for more options.

The user can click the Information Bar to remove the lockdown from the restricted content.

The security settings that are locked down for the content on the restricted protocols are the same as the settings enforced for the Local Machine Zone lockdown which is described earlier in this document. Please consult that section to review exactly which security settings are enforced for the content on the restricted protocols.

Restricted Protocols Feature is OFF by default for Internet Explorer and all Applications
Detailed description

The behavior of the Network Protocol Lockdown is controlled per-process by a new Internet Explorer Feature Control setting. Since this feature is designed to provide an additional layer of defense-in-depth for Network Administrators, the default Internet Explorer processes, IExplore.exe and Explorer.exe are not opted in by default. To opt-in to the Network Protocol Lockdown, Network Administrators or Developers should add a DWORD at either of the following locations where the name is their process name and the value is set to 1 to have the mitigation apply to them, To forcibly opt-out, set the value to 0.

HKEY_LOCAL_MACHINE\Software
\(Policies)\Microsoft
\Internet Explorer\Main\FeatureControl
\FEATURE_PROTOCOL_LOCKDOWN

HKEY_CURRENT_USER\Software
\(Policies)\Microsoft
\Internet Explorer\Main\FeatureControl
\FEATURE_PROTOCOL_LOCKDOWN

Applications may want to proactively opt-out to prevent the mitigation from being applied to them when a wildcard is used to force the mitigation into Opt-out mode.

Behavior per-zone when an application has “opt-ed in”

For an opt-ed in process, the behavior of the Network Protocol Lockdown is also controlled per-zone by a new Internet Explorer security setting or URLAction. This URLAction will be set to the following values:

Security Zone

Default behavior for Restricted Protocols

Example of what the user might see

Restricted Sites Zone

Prompt

Since ActiveX is never allowed in the Restricted Sites zone by default, no Information Bar is shown.

Internet Zone

Prompt

If the administrator blocklists the file:// protocol, HTML that uses script over the file:// protocol is restricted, but users can click the Information Bar to allow it.

Intranet Zone

Prompt

If the administrator blocklists the local:// protocol, HTML that uses Java over the local:// protocol is restricted, but users could click the Information Bar to allow it.

Trusted Sites Zone

Prompt

If the administrator blocklists the Shell:// protocol, HTML that uses Binary Behaviors over the Shell:// protocol is restricted, but users can click the Information Bar to allow it.

Local Machine Zone

Not applicable – By default, the Local Machine Zone Lockdown feature already restricts all HTML, independent of protocol.

Not applicable – By default, the Local Machine Zone Lockdown feature already restricts all HTML, independent of protocol

Per-Zone Protocol Blocklists

The list of protocols that are restricted is defined separately for each zone to allow some protocols to be locked down in some zones but run without restrictions in other zones. Protocols can be restricted for a given zone by writing the protocol name to the restricted list for a particular security zone

Security Zone

Registry location of the list of restricted protocols for each zone

Security settings applied to restricted protocol content

Restricted Sites Zone

HKEY_LOCAL_MACHINE

-or-

HKEY_CURRENT_USER

\Software\(Policies) \Microsoft\Windows
\CurrentVersion\Internet Settings
\RestrictedProtocols\4

HKEY_CURRENT_USER
\Software\Microsoft\

Windows\CurrentVersion
\Internet Settings
\Lockdown_Zones\4

Internet Zone

HKEY_LOCAL_MACHINE

-or-

HKEY_CURRENT_USER

\Software\(Policies) \Microsoft
\Windows \CurrentVersion
\Internet Settings \RestrictedProtocols\3

HKEY_CURRENT_USER
\Software\Microsoft\

Windows\CurrentVersion
\Internet Settings\Lockdown_Zones\3

Intranet Zone

HKEY_LOCAL_MACHINE

-or-

HKEY_CURRENT_USER

\Software\(Policies) \Microsoft
\Windows \CurrentVersion
\Internet Settings \RestrictedProtocols\2

HKEY_CURRENT_USER
\Software\Microsoft\

Windows\CurrentVersion
\Internet Settings\Lockdown_Zones\2

Trusted Sites Zone

HKEY_LOCAL_MACHINE

-or -

HKEY_CURRENT_USER

\Software\(Policies)

\Microsoft\Windows
\CurrentVersion\Internet Settings

\RestrictedProtocols\1

HKEY_CURRENT_USER
\Software\Microsoft\Windows
\CurrentVersion\Internet Settings
\Lockdown_Zones\1

Local Machine Zone

Not applicable. By default, the Local Machine Zone Lockdown feature already restricts all HTML, independent of protocol.

Not applicable. By default, the Local Machine Zone Lockdown feature already restricts all HTML, independent of protocol.

Protocols to consider for blocklisting

The default list of restricted protocols is blank. Network administrators should add additional protocols to the lockdown that they know are not needed in their organization for a particular zone. Network Administrators should consider restricting some of the following default windows protocols on managed desktop machines and other protocols that are not needed for rendering HTML with active content in the organization.

  • local://

  • file://

  • shell://

  • hcp://

  • ftp:// 

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

This change provides general defense in depth against vulnerabilities in less-frequently-used protocols. For example, an ActiveX control running under the Local:// protocol might assume that it is loaded in the Local Machine Zone and it may grant elevated privilege to the hosting page.

What works differently? Are there any dependencies?

If a Web page served on a protocol that is restricted for a given zone uses any restricted content, such as ActiveX, Internet Explorer will display the Information Bar, as previously described.

How do I fix these issues?

If your Web page needs to run ActiveX or scripting on a protocol that should be restricted for your intranet, you might allow the HTML to render correctly by moving the domain for that HTML to the trusted sites zone on the managed desktop machines. As a long term solution, you can look for ways to move the content off of the restricted protocol or if that’s not possible, you might remove the active content from the restricted protocol pages entirely by performing needed computations on the server using a server-side script such as an Active Server Page.

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

Since this feature is off by default, you will probably not need to change your HTML content unless it runs over a protocol that is restricted by a Network Administrator for your organization.

Related Links
Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft