Compatibility in Internet Explorer 6 for Windows XP Service Pack 2

  • Article

Microsoft Internet Explorer 6 for Microsoft Windows XP Service Pack 2 (SP2) introduces significant additions and changes to security features. Developers should review this document against their code because applications developed for earlier versions might break. A applications compatibility tool is available that you can run against your applications to help you find out if they will break. For more information, see Windows Client Application Compatibility.

This document assumes that you are familiar with Dynamic HTML (DHTML).

The following topics are discussed in this document.

  • Local Machine Zone Lockdown
  • Object Caching
  • MIME Handling
  • MIME Sniffing
  • Network Protocol Lockdown
  • Window Restrictions
  • File Download Restrictions
  • ActiveX Restrictions
  • Pop-up Blocker
  • Zone Elevation Blocks
  • Binary Behaviors
  • view-source Protocol
  • Related Topics

Local Machine Zone Lockdown

Before Windows XP SP2, the content on the local file system, aside from that cached by Windows Internet Explorer, was considered to be secure and was assigned to the Local Machine security zone. (For more information about security zones, see About URL Security Zones.) This security zone usually 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 privileges and compromise a computer.

Windows XP SP2 secures the Local Machine zone by tightening restrictions on several URL actions. In effect, Windows XP SP2 creates a new, locked-down Local Machine zone. This change does not affect the other security zones (Internet, Restricted sites, Local intranet, and Trusted sites zones). Any time that content attempts one of these actions, a new security user interface (UI) element called the Information Bar displays. The user can click the Information Bar to remove the lockdown from the restricted content. Thee following eleven URL actions are more restrictive in the Lockdown zone than in the usual Local Machine zone.

URL action URL policy
URLACTION_ACTIVEX_OVERRIDE_OBJECT_SAFETY URLPOLICY_DISALLOW
URLACTION_ACTIVEX_RUN URLPOLICY_DISALLOW
URLACTION_AUTOMATIC_ACTIVEX_UI URLPOLICY_DISALLOW
URLACTION_AUTOMATIC_DOWNLOAD_UI URLPOLICY_DISALLOW
URLACTION_BEHAVIOR_RUN URLPOLICY_DISALLOW
URLACTION_CLIENT_CERT_PROMPT URLPOLICY_DISALLOW
URLACTION_DOWNLOAD_UNSIGNED_ACTIVEX URLPOLICY_DISALLOW
URLACTION_FEATURE_MIME_SNIFFING URLPOLICY_DISALLOW
URLACTION_FEATURE_WINDOW_RESTRICTIONS URLPOLICY_DISALLOW
URLACTION_JAVA_PERMISSIONS URLPOLICY_JAVA_PROHIBIT
URLACTION_SCRIPT_RUN URLPOLICY_DISALLOW

If your Web page runs a Microsoft ActiveX control or script, you can add a Mark of the Web (MOTW) comment to the HTML of the page. This Internet Explorer feature forces the HTML file into the security zone of the specified URL so that it can run the script or ActiveX code in a less restrictive zone. MOTW works in Internet Explorer 4.0 and later.

Use the following comment to insert an MOTW comment into a page whose domain is identified, replacing https://www.example.com with the URL of the Internet domain or intranet domain where the page is hosted.

<!-- saved from url=https://www.example.com -->

Use the following comment when you want to generically insert an MOTW.

<!-- saved from url=about:internet -->

With Internet Explorer 6 for Windows XP SP2 and later, the MOTW comment can be used with multipart HTML (.mht) files.

For more information on MOTW, see Mark of the Web.

HTML application (.hta) files are hosted in a different process and are not impacted by the Local Machine zone lockdown.

The Local Machine zone lockdown is managed through a feature control registry key (FEATURE_LOCALMACHINE_LOCKDOWN). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_LOCALMACHINE_LOCKDOWN
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable the Local Machine zone lockdown feature by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

Object Caching

In previous versions of Windows, some Web pages could access objects cached from another Web site. In Internet Explorer 6 for Windows XP SP2, a reference to an object is no longer accessible when the user browses to a new domain.

For Windows XP SP2, there is a new security context on all scriptable objects so that access to all cached objects is blocked. In addition to blocking access when browsing across domains, access is also blocked when browsing within the same domain (fully qualified domain name). A reference to an object is no longer accessible after the context has changed due to navigation.

Prior to Internet Explorer 5.5, navigations across HTML pages (or across 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 remains 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 security hole.

If your application receives 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;  // reestablishes pointer to document object
   d.open();

Object caching is managed through a feature control registry key (FEATURE_OBJECT_CACHING). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_OBJECT_CACHING
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable the object caching feature by adding their processes to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

MIME Handling

Internet Explorer uses MIME type information to decide how to handle files that have been sent by a Web server. For example, when Internet Explorer receives a .jpg file, the file is generally displayed to the user in an Internet Explorer window. If Internet Explorer receives an executable file, it generally prompts the user for a decision on how to handle the file. In Windows XP SP2, Internet Explorer follows stricter rules that are designed to protect users from accidentally downloading or executing a dangerous file because of misleading MIME or file extension information.

Internet Explorer uses the following pieces of information to decide how to handle a file:

  • File extension, the corresponding ProgID, and the class identifier (CLSID) for the registered handler of that file extension.
  • Content-Type from the HTTP header (MIME type), the corresponding ProgID, and the CLSID for the registered handler of that content or MIME type.
  • Content-Disposition from the HTTP header.
  • Results of the MIME sniff. (See MIME Sniffing.)

Internet Explorer enforces 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 compares the MIME type of the cache file to the extension of the cache file. If there is a mismatch between them, Internet Explorer reconciles the 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 compares the CLSID of the MIME handler to the CLSID of the extension handler. If there is still a mismatch between the two handlers, Internet Explorer displays a prompt that forces the user to confirm whether to load the file in the MIME handler. If the MIME handler rejects the mismatched file, Internet Explorer displays a download error dialog box and does not automatically execute the file in its extension handler.

A related change prevents the execution of a potentially corrupt file in its extension handler. Internet Explorer displays the download error dialog box for any file that is rejected by its MIME handler with the error code INET_E_CANNOT_LOAD_DATA and does not execute the file in its extension handler regardless of MIME type or extension.

These changes do not affect cases where a Content-Disposition: attachment�HTTP header is used for the file. For these files, the file name or extension suggested by the server is considered final, and the file can be executed, regardless of any MIME/extension mismatch if the user chooses to accept the file download prompt.

Custom MIME handlers that intentionally rely on Internet Explorer to execute files that the custom MIME handler rejects should be updated to accommodate the changes for Windows XP SP2. The most secure scenario would be to handle files natively in the MIME handler instead of rejecting them. If the MIME handler cannot be changed, there are a few options.

  • Develop a MIME handler and an extension handler that are both part of the same CLSID. Internet Explorer can accept the CLSID match and not prompt to download the file or block the file from execution in the extension handler.
  • Mark the MIME handler to be ignored by Internet Explorer when there is a MIME/extension mismatch. For example, if the MIME handler for a certain media MIME type has a mismatched extension and must be executed directly to play properly, you can mark the ProgID of the MIME handler to be ignored on the mismatch when the media file extension belongs to a different ProgID. To do this, you set the following value in the registry with the MIME handler to ignore.

    • HKEY_CLASSES_ROOT

      • PROG_ID_OF_MIMEHANLDER_TO_IGNORE
      • PreferExecuteOnMismatch = 0x00000001

If neither option is viable, the developer should notify users of the incompatibility, and explain how to save the mismatched file to the file system and how to launch it manually.

If your scenario is impacted by unwanted file download prompts because of an irreconcilable MIME mismatch, you can register the MIME handler's ProgID to bypass all download prompts, including the new prompt on mismatch. Before doing this, you should confirm that the MIME handler can securely manage any file that is delegated to it. For example, you should confirm that the handler will never allow an attacker to gain more privilege than allowed by the zone of the originating file. This can be done through threat modeling, a code review for secure failure modes, and checks for buffer overruns. If you determine that the MIME handler is capable of safely handling files, you can register it to circumvent download prompts by adding a new value, as follows:

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Windows

          • CurrentVersion

            • Internet Settings

              • Secure Mime Handlers
              • MIME Handler PROGID = 0x00000001

MIME handling is managed through a feature control registry key (FEATURE_MIME_HANDLING). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_MIME_HANDLING
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable MIME handling by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

MIME Sniffing

Internet Explorer can determine the file type for certain files by examining (or sniffing) the file's bit signature. In Internet Explorer 6 for Windows XP SP2, MIME sniffing does not promote a file whose type is text/plain to a more dangerous file type. For example, a file received as plain text that included HTML code would not be promoted to the HTML type.

MIME sniffing is managed through a feature control registry key (FEATURE_MIME_SNIFFING). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_MIME_SNIFFING
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable MIME sniffing by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

After the feature control is enabled for a process, the value of the URL action flag�URLACTION_FEATURE_MIME_SNIFFING determines whether MIME sniffing is allowed to run. This flag can be set differently for each security zone. The default value for this flag is URLPOLICY_ALLOW for all zones except the Restricted sites zone. In the Restricted sites zone, the default value is URLPOLICY_DISALLOW.

Network Protocol Lockdown

Windows XP SP2 provides further restrictions for the various security zones by network protocol. Selected protocols are restricted from performing various URL actions. A different set of protocols is restricted for each security zone. The following are the default protocols by zone:

  • Local intranet zone: file, shell, and local
  • Trusted sites zone: No restricted protocols
  • Internet zone: file, shell, and local
  • Restricted sites zone: file, shell, local, hcp, and ftp

When a network protocol is restricted, URL actions in the locked-down security zone have the same values as the corresponding URL actions in the Local Machine Lockdown zone. See Local Machine Zone Lockdown for more information.

The URL action flag URLACTION_ALLOW_RESTRICTEDPROTOCOLS determines whether the user is prompted to choose to trust the page and allow the restricted protocol access to the local computer.

The network protocol lockdown is managed through a feature control registry key (FEATURE_PROTOCOL_LOCKDOWN). It is disabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and disabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_PROTOCOL_LOCKDOWN
              • iexplore.exe = 0x00000000
                explorer.exe = 0x00000001
                process name.exe = 0x00000000

Applications that host the WebBrowser Control can enable the network protocol lockdown by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

Window Restrictions

Internet Explorer 6 for Windows XP SP2 places some restrictions on windows to prevent hidden information and the spoofing of UI. The visible security features of Internet Explorer windows, such as the status bar, provide information to users to help them find out the source of a Web page and the security of the page. When these elements are hidden from view, users might think that they are on a more trusted page or are 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 UI in an attempt to motivate the user to take unsafe actions or to divulge sensitive information.

Internet Explorer requires that the title bar, address bar, and status bar of windows are in the visible area of the display. Other changes affect windows opened by the window.open (with chrome) and window.createPopup (chromeless) methods.

The following are guidelines for working with script-initiated window calls in a process running the Window Restrictions feature control.

For windows opened using window.open:

  • Expect the status bar to be present, and code for it. The status bar is on by default and is 20-25 pixels in height.
  • Adjust your window's size and content so that it fits well visually with the window's overall size. The window does not cover the taskbar, so it might lose 40 pixels if the status bar is on, and you do not account for the taskbar. Vertically size the window no more than 30 pixels outside the taskbar.
  • Do not open windows offscreen. Internet Explorer will move them by the smallest offset of x-coordinates and y-coordinates that enables the window to fully display onscreen.
  • As before, the display of the window is affected by the display theme, font size, and resolution, so you might have to account for these UI influences when you are designing your windows.

Note  Using the window.open method with fullscreen=yes results in a maximized window, not a kiosk mode window.

See Pop-up Blocker for some other possible restrictions.

For windows opened using window.createPopup:

  • Adjust the window's size and content so it fits well visually within the window's overall size. With this new feature, the window does not cover its parent window's title bar or status bar, so it might lose 40 pixels, if you do not account for the title and status bars. Vertically size the window no larger than the currently visible area of the page.
  • Do not open chromeless windows outside the HTML rendering surface of Internet Explorer. They will be moved by the smallest offset of x-coordinates and y-coordinates that enables the window to be fully displayed inside the client area. There is one exception: as much as one-half of the window can exist outside the left edge or right edge of the Internet Explorer client area.
  • As before, the display of the window is affected by the display theme, font size, and resolution, so you might have to account for these UI influences when you are designing your windows.

Applications hosting the WebBrowser Control can take advantage of window restrictions. The restrictions are managed through a feature control registry key (FEATURE_WINDOW_RESTRICTIONS). Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe) run under this feature control by default. The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_WINDOW_RESTRICTIONS
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications hosting the WebBrowser Control can take advantage of this feature control by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

Applications can also use the CoInternetIsFeatureEnabledForUrl function to determine whether window restrictions apply to the security zone of a URL. The function returns an HRESULT based on value of the URL policy for the URL action flag�URLACTION_FEATURE_WINDOW_RESTRICTIONS in the zone of the specified URL.

File Download Restrictions

In Internet Explorer 6 for Windows XP SP2, file download dialog boxes that are not the result of a user action, such as a mouse click or keystroke, are suppressed. Users can allow downloads through a security UI element called the Information Bar.

To ensure that downloads on your Web site are not suppressed, do not launch a file download automatically, for example, when a user browses to your site. Launch file downloads on your Web pages through hyperlinks or buttons�anything that requires direct user action.

Some Web sites contain images of the download dialog box to instruct users on where to click to accept the control. The file download dialog boxes have changed in Windows XP SP2. If your Web site has images of the dialog box, consider updating them to reflect the new download dialog boxes for users of Windows XP SP2. Use the userAgent string to determine the correct version of the browser.

Windows XP SP2 checks for a digital signature on files that can be digitally signed. Publishers should sign files with Microsoft Authenticode technology. Common examples of files that can be signed include files with the following extensions.

  • .exe
  • .dll
  • .cab
  • .ocx
  • .msi

Applications hosting the WebBrowser Control can take advantage of the tighter restrictions on file downloads. The restrictions are managed through a feature control registry key (FEATURE_RESTRICT_FILEDOWNLOAD). Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe) run under this feature control by default. The following shows where to add the registry key and your process.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_RESTRICT_FILEDOWNLOAD
              • process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable this feature control by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

When a process is running the feature control for file download restrictions, the URL action flag URLACTION_AUTOMATIC_DOWNLOAD_UI determines whether the Information Bar is used for file downloads.

ActiveX Restrictions

In Internet Explorer 6 for Windows XP SP2, the modal installation prompt for ActiveX controls is initially suppressed. Users can allow installation through a security UI element called the Information Bar. An exception is made for upgrades to controls that have already been installed on the computer that meet the following criteria:

  • The file registered as the ActiveX control must be signed with Authenticode technology. (The 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 cabinet (.cab) file, the .cab file must be signed. The DLL or OCX to be installed should also be signed so that subsequent upgrades do not require user intervention.

Internet Explorer also blocks controls that are unsigned, invalid, or explicitly distrusted by the user.

Note  If an ActiveX control that is suppressed takes up space on the rendered Web page, Internet Explorer shows an inline icon and text in place of the control to indicate that the ActiveX control must be installed. Users can click on this area or on the Information Bar to install the control.

Some Web pages automatically redirect users to another page or behave differently after a refresh when an ActiveX control is not installed. In some cases, building your site this way can prevent the user from installing the control, which might result in an disagreeable user experience. Because a Web page cannot distinguish between a user declining the installation of an ActiveX control and the control being suppressed by the tighter security in Windows XP SP2, the recommended practice for installing an ActiveX control is to create an instance of the control on a stand-alone Web page that explains the purpose of the control. Also, use a SPAN section within the OBJECT tag to dynamically show explanatory text to the user for installation failures.

The Authenticode dialog box has changed in Windows XP SP2. If your Web site has images of the dialog box, you can update them to reflect the new Authenticode�UI. Use the userAgent string to determine the correct version of the browser.

Here are some best practices around ActiveX controls:

  • Do not install ActiveX controls using a pop-up window or an HTML dialog box.
  • Do not suggest to users that they should lower their security settings to install an ActiveX control.
  • Document the purpose of the ActiveX control and its impact on users by creating an instance of the control on a stand-alone page.

Applications that host the WebBrowser Control can enable tighter restrictions on ActiveX controls. The restrictions are managed through a feature control registry key (FEATURE_RESTRICT_ACTIVEXINSTALL). Both Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe) run under this feature control by default. The following shows where to add the registry key and your process.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_RESTRICT_ACTIVEXINSTALL
              • process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable this feature control by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

When a process is running the feature control for ActiveX restrictions, the URL action flag URLACTION_AUTOMATIC_ACTIVEX_UI determines whether the Information Bar is used for ActiveX control installations.

Windows XP SP2 provides more information during the binding process. After an ActiveX control has been downloaded and its signature has been analyzed, urlmon calls IBindStatusCallback::OnProgress on the process and sends the following two pieces of information to the application indicated by these BINDSTATUS members:

Pop-up Blocker

The Pop-up Blocker feature blocks pop-up (and pop-under) windows that are initiated automatically from a Web site. Windows in the Internet and Restricted sites zones are blocked by default. However, the Pop-up Blocker allows windows that are initiated by a user action. Users can configure Internet Explorer 6 for Windows XP SP2 to be more or less restrictive. Users can also turn off the Pop-up Blocker altogether.

For Internet Explorer 7, see URLACTION_FEATURE_BLOCK_INPUT_PROMPTS for additional restrictive capabilities.

Generally, the Pop-up Blocker lets a window open under the following circumstances:

  • When initiated by user action, such as a mouse click on a button or hyperlink.
  • When opened in the Trusted sites and Local intranet zones (considered safe).
  • When opened by other applications running on the local machine.

The affected script methods are:

Note  Pop-ups created with window.createPopup are unaffected by the Pop-up Blocker.

Most methods that open a new window return a window object. When the Pop-up Blocker blocks a window, the method that attempted to open it returns null instead. Before using the object, script should test for and handle a null return value when opening a window. See Window Restrictions for more changes to window objects in Internet Explorer 6 for Windows XP SP2.

Internet Explorer no longer launches a new window when window.open is called on an onunload event. Some Web sites used this method to try to get users to stay on the site longer or to serve users one more advertisement.

Another common practice is to open a new window outside of the visible desktop area. Internet Explorer no longer allows this practice. Also, a window that is larger than the screen cannot be opened. See Window Restrictions for more information.

The Pop-up Blocker is managed through a feature control registry key (FEATURE_WEBOC_POPUPMANAGEMENT). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_WEBOC_POPUPMANAGEMENT
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable the Pop-up Blocker by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

An application that hosts the WebBrowser Control can also implement the INewWindowManager interface to use or to extend the Pop-up Blocker.

To receive context information about current Pop-up Blocker settings from within a MIME handler, implement IMonikerProp on the handler and use the information passed through IMonikerProp::PutProperty, specifically the POPUPLEVELPROP property. This information is sent just before the object is activated.

Zone Elevation Blocks

When a Web page is opened, Internet Explorer 6 for Windows XP SP2 puts restrictions on what the page can do based on the zone that the page is running in. 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 run in the Local Machine zone, which has the fewest security restrictions. This makes the Local Machine zone a prime target for malicious users. Zone Elevation Blocks make 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. See Local Machine Zone Lockdown for more information about the Local Machine Lockdown.

Internet Explorer prevents automatic navigation from a page in one security context to another page in a lower security context. For example, this means that a page in the Internet zone cannot navigate to a page in the Local intranet zone, except as the result of a user-initiated action. A script cannot automatically make this sort of navigation without user interaction, such as a mouse click or a keystroke. For the purpose of this limitation, 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 disable script navigation if there is no security context.

The Zone Elevation Blocks are managed through a feature control registry key (FEATURE_ZONE_ELEVATION). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_ZONE_ELEVATION
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable Zone Elevation Blocks by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

Applications can also use the CoInternetIsFeatureZoneElevationEnabled function to determine before navigation whether the navigation from one URL to another is allowed. The function returns an HRESULT based on value of the URL policy for the URL action flag�URLACTION_FEATURE_ZONE_ELEVATION in the zone of the specified URL.

Binary Behaviors

Internet Explorer 6 for Windows XP SP2 mitigates attacks that use binary behaviors maliciously. It provides a general mitigation for binary behaviors by not allowing them to run. The mitigation can further be established differently for each security zone. For example, Internet Explorer does not allow binary behaviors to run in the Restricted sites zone by default, but allows them to run in the other security zones.

Note  Binary behaviors are Component Object Model (COM) objects, usually written in C++, and are compiled. For more information on binary behaviors, see Binary Behaviors. They differ from attached behaviors and element behaviors, which are written in script. See Introduction to DHTML Behaviors and About Element Behaviors for more information.

Applications that host the WebBrowser Control and that use Internet Explorer functionality in the Restricted sites zone may be affected by the new feature control for binary behaviors. For example, e-mail applications that use a binary behavior to render HTML e-mail in the Restricted sites zone might have to be modified. To use binary behaviors from the Restricted sites zone, an application can implement a custom security manager. See Creating a Customized URL Security Manager for more information.

The mitigation of binary behaviors is managed through a feature control registry key (FEATURE_BEHAVIORS). It is enabled by default for Internet Explorer (iexplore.exe) and Windows Explorer (explorer.exe). The following shows the registry key and enabled processes.

  • HKEY_LOCAL_MACHINE (or HKEY_CURRENT_USER)

    • SOFTWARE

      • Microsoft

        • Internet Explorer

          • Main

            • FeatureControl

              • FEATURE_BEHAVIORS
              • iexplore.exe = 0x00000001
                explorer.exe = 0x00000001
                process name.exe = 0x00000001

Applications that host the WebBrowser Control can enable this feature control by adding their process to the registry. This can be done programmatically by using the CoInternetSetFeatureEnabled function. If an application does not run under this feature control, the WebBrowser Control behaves the same as in Internet Explorer 6 SP1b.

After the feature control is enabled for a process, the value of the URL action flag�URLACTION_BEHAVIOR_RUN determines whether binary behaviors are allowed to run. This flag can be set differently for each security zone. The default value for this flag is URLPOLICY_ALLOW for all zones except the Restricted sites zone. In the Restricted sites zone, the default value is URLPOLICY_DISALLOW.

view-source Protocol

For security reasons, the view-source protocol is no longer supported. To view the source code for a URL on a Windows XP SP2-based computer, choose the Source command on the View menu.