IE Security Zones

IE Security Zones
IE Security Zones
Greetings. My name is Mike Friedman. I’m on the Internet Explorer Security Test Team. In IE, the different areas of the Web are partitioned into a set of security zones. The topic I would like to talk about is programmatically adding sites to those zones. Zones were introduced in IE4 as a way to give users and admins more control, to strike a balance between user experience and gradations of risk. If you have a high degree of trust in a site, placing it in a lower-security zone can reduce the number of warnings and prompts the user will encounter. Conversely, placing a site you are concerned about into a higher-security zone can provide additional protection. For security management or as part of a product installation, it’s sometimes useful to be able to add some sites to a security zone programmatically. Of course a website can't manipulate which sites are in which security zones; it can only be done by code running on the user's machine. I am going to show you how to write a C# application to place sites into security zones.

First, some background: IE, WebBrowser applications, and other participating applications use the Internet Security Manager to determine what zone an URL is in and what actions can be performed in that zone. The security zones are:

*

Local Intranet Zone—content located on an organization's intranet. Because the servers and information is within an organization's firewall, a user or organization can assign a higher trust level to the content on the intranet.

*

Trusted Sites Zone—content located on Web sites that are considered more reputable or trustworthy than other sites on the Internet. Users can use this zone to assign a higher trust level to these sites to minimize the number of authentication requests.

*

Internet Zone—Web sites on the Internet that do not belong to another zone. This default setting causes IE to prompt the user whenever potentially unsafe content is ready to download. Web sites that are not mapped into other zones automatically fall into this zone.

*

Restricted Sites Zone—Web sites that contain content that can cause, or may have previously caused, problems when downloaded. Users can use this zone to cause Internet Explorer to alert them whenever potentially unsafe content is about to download, or to prevent that content from downloading

*

Local Machine Zone—The Local Machine zone is an implicit zone for content that exists on the local computer. The content found on the user's computer, except for content that IE caches on the local system, is treated with a high level of trust. However, in XPSP2 the Local Machine Zone Lockdown feature causes IE to apply additional security that is even more restrictive than the default Internet Zone settings.

Each zone is assigned an equal level of permissions and starts out with a default security level (template) of High, Medium, Medium-High, or Low. The user can change the security level of each zone through the Security tab of the Internet Options UI, available in Internet Explorer by selecting Tools | Internet Options and accessible from the Control Panel as well. Starting with IE5, a Medium-Low template is available as well. The user can also use the UI to customize zone security settings except for the Local Machine Zone. A user can assign Web sites to some of the security zones. Besides the Internet Options UI, sites can be added to zones using the Internet Explorer Administration Kit (IEAK).

When adding sites to a zone, the user specifies an URL pattern. An URL pattern can be a fully specified site URL like http://www.microsoft.com, or it can contain asterisks as wildcards, for example http://*.msn.com . While browsing, users can tell what security zone a site is in by looking at the bottom right-hand corner of the IE window.

Each zone has an associated set of URL action policies. An example of an URL action is "Access data sources across domains." The possible policies for this URL action are "Disable," "Enable," and "Prompt." Ultimately, each zone's URL patterns and URL action policies reside in the registry. Theoretically, an application can use the registry to query or manipulate the URL-to-zone mappings or the per-zone URL action policies. However, this is not a good idea, as the location and format of this information can change. The proper way to work with this information is through interfaces that the Internet Security Manager exposes. If you write your own control or web application, you'll want to make use of the Internet Security Manager to conform your software's security policies with IE's.

The IInternetSecurityManager interface enables client applications to modify the security settings. This interface is part of the URL Security Zones API, which allows developers to manage URL security zones and create custom URL security zone managers. If an application wants to place a pattern into a specified security zone, it would use the method IInternetSecurityManager::SetZoneMapping(). The syntax for the method looks like this:

HRESULT SetZoneMapping(DWORD dwZone, LPCWSTR lpszPattern, DWORD dwFlags)

The dwZone parameter specifies the security zone; lpszPattern specifies the pattern, and dwFlags indicates whether to create or delete the mapping.

For further information, see the MSDN reference for this method. (Note that in Windows Server 2003 and higher there is a regular and Enhanced Security Configuration version of each zone and you need to set a flag if you're addressing the Enhanced Security Configuration version.)

I have written a simple C# application that illustrates the use of SetZoneMapping(). Here is a screen shot of the application:



In the “Site Pattern” field you enter an URL containing possible wildcards. You choose one of the radio buttons to designate the zone you want to place the pattern into. Then you push the “Add” button. A message box will come up saying whether the pattern was successfully added to the zone or not. You can repeat this however many times you wish. Push the Close button to end the application.

The complete Visual C# project is available to download here: SetZoneMappingDemo.zip.

To see how the app works, let’s zero in on two code snippets that contain the meat of the program:

The constructor for the form creates the Internet Security Manager COM object and obtains a reference to the IInternetSecurityManager interface:

Type t = Type.GetTypeFromCLSID(CLSID_InternetSecurityManager);
_securityManager = Activator.CreateInstance(t);
_ism = (IInternetSecurityManager) _securityManager;

The handler for the Add button calls SetZoneMapping() and pronounces the result:

int result = _ism.SetZoneMapping((UInt32)_ctrl.Tag, txtPattern.Text, SZM_CREATE);
if (S_OK==result)
{
MessageBox.Show("Pattern \""+txtPattern.Text+"\" successfully added to " + _ctrl.Text + " zone.");
}
else
{
MessageBox.Show("Could not add pattern \""+txtPattern.Text+"\" to " + _ctrl.Text + " zone.");
}

An obvious extension to this application would be a Delete button. The handler for that button would look very similar, except you’d pass SZM_DELETE to SetZoneMapping() instead of SZM_CREATE.

Adding an URL pattern to a security zone is only effective for the particular user that runs the application. You can learn more about security zones and how to work with them programmatically in the MSDN topic URL Security Zones .
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included code samples is subject to the terms specified at http://www.microsoft.com/info/cpyright.htm .

Table Rendering

Table Rendering
Table Rendering

A comment from Dave P on this blog touched on the interesting aspect of table rendering.

Dave said “IE renders pages differently from, say firefox. One of the noticeable differences is that IE waits for the entire page before displaying it.“ Actually this is not true and you can se from going to many pages that Internet Explorer does support progressive rendering of content as it arrives. This is true however for table rendering. When Internet Explorer encounters a table it measures all the content of the table before rendering so that it knows what the widths of the columns are to render the content correctly. On the other hand Firefox uses a different algorithm in that it renders the table contents progressively before it has all been passed. There are pros and cons to both approaches. In the case of progressive rendering a table it can result in an experience where content is initially displayed and then moved as the browser progresses creating a clunky and poor quality feel. On the other hand if we parse the entire table content first then it can take some time to display in the case of heavily nested tables. I’ve heard user feedback supporting both arguments and more than a few people have mentioned that they find Firefox’s rendering a little off putting in this regard.

There is actually a solution that should improve the performance of browsers whichever table parsing algorithm they use and that is for web developers to make use of the table-layout attribute in CSS. This was first introduced with Internet Explorer 5 and is now part of CSS2 and CSS2.1. This attribute will force the table to honor the declared widths of columns rather than size to fit. I’m assuming that Firefox does support this attribute but there is a lack of documentation on exactly what is supported in that particular browser.

Now you may be asking why tables didn’t just honor the specified widths to start with and the answer is our old friend compatibility. When developing Internet Explorer 4 there was another browser called Netscape Navigator 3 that was the most used browser in the world. We knew then that if people were to adopt a different browser then we had to render content exactly as they were used to. So we spent a great deal of time in IE4 emulating the parsing and rendering of tables that Netscape had implemented. That was some time ago but we continue to be able to render pages that make use of this rendering functionality. In recent years many people have moved to using CSS for layout in preference to tables and there are certainly advantages to that although there has also been some interesting debate about the benefits of a purely CSS based approach.

Tables have been used to position content on a page for many years but the truth is that they were never originally intended for that purpose. The wonderful thing about the web is that people will make use of functionality in new and interesting ways, they become reliant on bugs and strange behavior. As a result it becomes difficult to change without breaking existing content. The consideration of compatibility goes back to almost any platform, for example there was a great deal of work undertaken in Windows 95 before its launch to ensure that programs written for Windows 3.1 continued to work. As we move forward we need to be careful to ensure that existing web content continues to function. That doesn’t mean we cannot move forward though. In Internet Explorer 6 we introduced support for the strict doctype to allow us to improve our CSS support without breaking existing content. We expect to use this same technique in the future to allow us to make further improvements.

Thanks

IE content-type logic

IE content-type logic

IE content-type logic

This being my first post on the IE blog, I should introduce myself quickly. My name is Vishu Gupta; I am a developer on the IE team.

There have been several posts in the recent past asking for more information on how does Internet Explorer sniff the content-type of a downloaded file. The whole thing looks totally inconsistent or should I say...non-compliant! Before reaching any conclusions here, let’s dig just a little bit deeper.

During XPSP2, we gave a real hard look at the IE's content-type handling code path and how to make it more secure and reasonable. The whole idea of the mime-sniffing logic was to make it easier for an average Joe to put up a personal website without worrying about mimetype details even when web servers and ISPs have random default configurations. IE does mime-sniffing only if either the server doesn't specify a content-type or if the server claims that the file is something that IE knows about. For example, if there is a new mimetype abc/xyz and the server reports that to IE, IE will consider the mimetype of the file to be abc/xyz only. In addition to the content-type sniffing, IE also does clsid sniffing, which actually decides which component handles the file within IE. The clsid can be either sniffed from the document itself or it can be obtained from the mimetype (decided previously with or without sniffing) or can be obtained from the extension. For example, if the mimetype abc/xyz doesn't have a clsid corresponding to itself in the registry, IE will try to obtain the clsid from the extension or from the document itself, and use that to host the file. If it cannot find the clsid, the file will be Shell Executed and shell will use the extension to determine the application to handle the file.

Now comes:
The question: "Do we really need to sniff a file if the server says it is text/plain?"
Short answer: No.
Long answer: Probably, we do.

During XPSP2 betas, we had the mimesniffing mitigation enabled in all zones by default. We tested the waters with applying the "server knows best, so treat the server-suggested mimetype as authoritative" concept for text/plain mimetype. This led to an outcry on the newsgroups about different file types being rendered as text on XPSP2, and we had to disable the mitigation in the internet zone. One can only imagine the app-compat backlash if we stopped sniffing for all reported mimetypes. Yes, instead of handling that by sniffing in the browser, we could go about asking everybody to fix their servers but not everyone can do that easily. In addition to this, several apps depend on IE to launch them after sniffing the correct clsid from their compound file (OLE structured storage). Its one thing to ask new apps to do the right thing, but a whole different ball-game if you want to switch the entire installed base.

Mimesniffing doesn't mean that there is no way for a server to control how a file is handled. header enables a server to do precisely that. With this however, IE makes sure that the user gets prompted with the file type information (based on the extension specified by the server here) before the file is opened/saved.

-Vishu

posted on Tuesday, February 01, 2005 7:22 AM

BetaNews | MS: No Updates for Virtualized Windows

BetaNews | MS: No Updates for Virtualized Windows: "Microsoft's Windows Genuine Advantage (WGA) validation initiative has set off a firestorm of protest throughout the open source community after programmers uncovered a special function in the software dedicated to detecting Wine, a compatibility layer for running Windows programs in non-Windows environments.

WGA authentication is set to become mandatory for all non-critical Windows updates starting in the second half of 2005. Customers must run a program that verifies their Windows license, or they will not have access to Windows Update or the Microsoft Download Center."