*** 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):
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.
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:
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.
The registry key
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
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.