*** Under construction ***

This article is added in the NDL to help the developers understand the impact of the Microsoft Internet Explorer security features and settings over the applications and development environments that use its rendering engine. The article is especially targeted to the Active Local Pages and IE ScriptBar developers, but it is useful for any application that uses the IE's rendering engine and not only. Perhaps this article is a bit long, but you can skip some of the first sections if you are already familiar with the matter they explain. The main idea of the article is to present the WEB security problems from the prospective of a programmer that builds an entire system. This approach may need a bit more talking but on the other hand it helps the reader (and the writer as well) see the picture as whole and find out his/her place in it. The decision to write such an article has been inspired by the fact that in many cases the problems that occur in the application development are in fact caused by attempts to look at the security from an wrong angle. The problems are often caused by the temptation to implement a feature in a way that is somehow incompatible with the security concepts in operation. Thus the time spent to reconsider the security from its foundations helps one see the needs behind the technologies. Thus the article is not too technical, but it targets the technical aspects no less.   

A few words about the IE security in general.

Even before Windows XP SP2 the security manager used by Microsoft Internet Explorer (IE) has been able to cause troubles to those who want to use the IE as user interface engine for their applications. Perhaps you have witnessed that even some of the OS supplied Microsoft applications experience problems when the security is too high. For example the Add/Remove programs applet, Window registration utility and many others. This is so because IE is extremely advanced and flexible foundation for user interface construction. In quite many cases it is impractical to create generic Windows applications or even use a RAD tool if you can use IE instead. The obvious benefit is that IE is already installed on the system and the developer needs minimal efforts to implement user interface using DHTML. Compared to the efforts needed otherwise the IE usage is effective and less dependent on additional components. So, even Microsoft based many of their system support applets on it, no need to mention the IE integration in the bigger products and the thousands of 3-d party products that depend on it.

The issue with IE is its complexity. The few holes in it and mostly the problems in the additions published by Microsoft and other vendors made it notorious for its vulnerability. The fact is that any complex application that allows so many extension plug-ins would have the same fate. Microsoft solved many of the problems in the Windows XP SP2 and the service packs for other Windows versions that carry the same features (such as SP1 for Windows 2003, but we will talk about XP SP2 for brevity - just consider that the same applies to any Windows OS that implements the features introduced in it). 

It is important to understand that the XP SP2 effect over IE is not deep. In fact the actual SP2 additions are outside IE and the changes in IE are only cosmetic, yet they are very important and one can say - "just in time". In fact the role of the XP SP2 introduced features is to move  the weight - from the open environment to secure environment. In other words the main idea is to change the default behavior and require the users to pay more attention to the features they use. So, while before XP SP2 IE was by default opened for any extension, now it poses much higher limitations in its default configuration. Many features available before would need user attention now. Therefore we will discuss later not only how to override certain limitations, but also the policies we must comply in order to keep the user environment secure. The today's security risks require the developers to avoid some of the yesterday's practices, sometimes this may even mean that certain application should be installed in non-functional or semi-functional state until the user allows it to operate at its full capacity! It is possible to overcome any limitation, but the developer must stand the temptation to do this if there is any chance that this may lead an inexperienced user to a mistake that will render his/her system vulnerable. This must be done even if that would mean that some users may be unable to find out how to use the application. Why? Because otherwise you can lose more by losing the user's trust.

The security zones.

IE security is based on the so called "security zones". There are 5 of them - each identified by an ID:

0 - the local machine
1 - the local area network or intranet
2 - The trusted sites
3 - the Internet
4 - The restricted sites.

The IE security manager determines to which zone the resource belongs in different manner for each zone: The "local machine", "local area network" and the "Internet" are determined automatically from the resource location. The "trusted sites" and the "restricted sites" on the other hand are determined over a list maintained in the system registry. Adding registry entries that put certain resource location in the zone 0,1 or 3 would not work because this will disrupt the very foundation of the IE security, however there are some entries that can be changed (see below):

Protocol defaults

IE uses the so called protocols to fetch the resources it needs to show. These are Asynchronous Pluggable Protocol modules registered with the system or with the process. Their role is to implement an abstract workframe for the underlying protocol which will make it transparent for the IE and the other applications that may want to use them. Thus the browser doesn't know anything in-depth about the http, https, ftp, file or any other protocol you may use in an URL. The protocol name just tells the IE which module to invoke. The actual work is done by the protocol module and the IE just consumes the results.

For each protocol there is a place in the registry where the default security zone for it can be specified. This way the browser knows the nature of the protocol. For example the http protocol belongs to the Internet zone (3) by default, while the file protocol belongs to the "local machine" zone by default. Still, you may see that changing the settings would not always have any effect - especially for the popular protocols. This is a result of two things - first there is a fail safe hard coded in the IE security manager and second the security manager implements much more than just reading of a few registry entries. The protocols are required to report the security portion of the URL of any resource they serve. This is used by the security manager to perform more complicated checks and determine if the URL is a local path or a DNS name plus path for example. This is out of the topic of this article, but you must at least know about it in order to avoid confusion.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults

is the registry key in which the protocol defaults are listed as DWORD values. The name of the value must be the same as the protocol name and the value specifies the zone ID.

For example to make the ALP protocol belonging to the "trusted sites" zone you need to add a value:

name: "alp"
value: 0x00000002

in the above key. The effect will be that any ALP served content with Security URL set to "alp://" will be treated as trusted content. Note that if the above setting is left empty (default) ALP will declare the content as belonging to the "local machine" zone which is obviously the truth. Furthermore ALP is interesting example for on of the the comments above. When the Security URL is left empty ALP reports to the security manager URL like this one: "alp://C:/somepath/somefile.asp" for example. This contains a local path and is assigned to the local machine zone. If the Security URL is set to "alp://" ALP will report the protocol only without any path included and if the protocol is registered as trusted (see above) the content will be trusted indeed.

Domains

The registry key

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains

is used to hold a list of domains/partial URL and assign specific zones to them. This is mainly used for the trusted and the restricted sites.

////////////// To be continued //////////////

What is the impact of the security zones?

We explained some of the methods used to put certain resource in a particular security zone. As you can see the zone selected for the resource depends mostly on the URL and on the protocol over which it is fetched. Once obtained the resource is "used". In most cases when we consider resource usage we mean displaying the resource in Internet Explorer. This means for example a DHTML page resource must be shown and the objects and scripts in it activated. The dangers in this case are well-known for everyone already, but we should not restrict our view to the browser only. The downloaded resource may be something else - an MS Word document, a spreadsheet, database etc. Many of these resources would have active content - a content that includes scripts, other code, ActiveX, applets. With respect to the specifics we can still say that any such a resource is a kind of application - a program that we must run on the local machine. Indeed a DHTML page is a program - may be a little limited in features, not fully connected to the local machine features, but still a DHTML page can do many things through embedded controls. The same is true for an MS Access database or a MS Word document for instance which may contain VBA modules.

Thus the problem is not limited to the Internet Explorer only. In fact we are dealing with a general problem for which the IE integration with the OS seems to be a good thing (Yet we must not forget that part of the problems are also born because of the integration).

What we had before XP SP2? The user has been (is) able to enable/disable certain features in IE for the all zones except the Local machine zone. Still all the settings concerned only the IE DHTML features.