Internet Explorer’s zone model[234] is a proprietary attempt to reconcile the different security requirements that users (or system administrators) may have for different types of web applications, for example, a banking page and an online game. Microsoft’s approach is to establish several predefined classes of websites—known as zones—each with its own set of configurable security permissions. The five supported zones are these:
My computer (aka local machine) This hidden zone is used for all local file: resources (with one exception—more about it soon). The user cannot add or remove any elements from this set and cannot change its security settings through the normal user interface. Administrators and developers can modify the registry or use urlmon.dll hooks to override settings, however.
Local intranet This zone is meant to include trusted applications on a user’s local network. By default, local intranet enjoys many problematic privileges, such as unrestricted access to the system clipboard, the ability to open windows without an address bar, or the ability to bypass the usual frame navigation security checks (the descendant policy, outlined in Chapter 11). Members of this set are detected automatically using several configurable heuristics, and they may include destinations with non-fully qualified hostnames, addresses on the HTTP proxy exemption list,[76] or remote file: URLs accessed over SMB. Manual inclusion of sites in this zone is also possible (in addition to or instead of the built-in heuristics).
The local intranet zone makes an implicit connection between a local network and a trusted environment. This connection is often dubious in the modern-day environment, especially given the prevalence of public Internet access over unencrypted Wi-Fi: Other uses of the network are not any more trustworthy than a random website hosted across the globe.
Trusted sites These are nominally empty zones roughly equivalent to local intranet in terms of their security settings but managed solely by the user. Autodetection heuristics are unavailable, and all entries have to be created by hand.
Restricted sites In these nominally empty zones, the user may add “untrusted” destinations. The default settings for these zones remove many rudimentary and generally harmless capabilities from the loaded content (for example, Refresh headers will not work) while offering limited security benefits.
The practicality of this zone seems unclear. Because of the need to whitelist every untrusted site, the zone obviously can’t be relied upon as an alternative to browsing the Internet with sensible default settings for previously unseen destinations.
Internet This is a default zone for sites not included in any of the remaining categories. Its default settings match the general browser security model baseline discussed previously in this book.
The concept of zones, coupled with some of their security controls, seems to be a step in the right direction. For example, it allows system administrators to fine-tune the permissions for file: documents without affecting the security or convenience of normal browsing—or to prohibit Internet sites from navigating to local, corporate systems (using the setting named “Websites in less privileged web content zone can navigate into this zone”). Unfortunately, the actual implementation of the zone model is muddied by a lack of focus, and in practice, it is misused more often than it is genuinely benefited from.
The first problem evident to anyone trying to master the zone mechanism is its obtuse terminology and the almost-comical complexity of many of the settings. Every zone comes with over 100 checkboxes; some of these will alter the browser security model profoundly, while others have no security consequences whatsoever. (The aforementioned Refresh setting is one example of a security no-op; the ability to disable form submission is another.) These two classes of settings are not distinguished in any clear way, and many are nearly impossible to comprehend at a glance. For example, the option “Binary and script behaviors” can be set to “enable” or “disable,” but the help subsystem offers no information about what either setting will actually do. The only explanation is provided in the official developer documentation posted on Microsoft’s site—but even this document can confuse.[235] See for yourself:
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, allowing them to work on Web pages in the Restricted Sites zone. In Windows Server 2003 Service Pack 1, there is a new Internet Explorer security setting for binary behaviors. This new setting disables binary behaviors in the Restricted Sites zone by default. In combination with the Local Machine Lockdown security feature, it also requires administrative approval for binary behaviors to run in the Local Machine zone by default. This new binary behaviors security setting provides a general mitigation to vulnerabilities in Internet Explorer binary behaviors.
There are many similar cases of settings that require a substantial effort to understand. For example, it is unlikely that even the most seasoned administrators will understand the implications of tweaking settings named “Access data sources across domains” or “Navigate windows and frames across different domains”. All this confusion has an interesting consequence: Trusted parties unintentionally dispense dubious advice. For example, Charles Schwab, a prominent investment bank, tells customers to disable the frame navigation descendant model,[236] essentially making HTML frames unsafe to use not only for Charles Schwab but also for any other website. One of the sites maintained by the Internal Revenue Service provides the same, extremely inconsiderate tip.[237]
The complexity and poor documentation of Internet Explorer’s zone settings aside, the other problem with the zone model is the clustering of unrelated permissions. The settings for local intranet and trusted sites containers enable a random collection of features that may be required by some trusted sites—but none of the trusted sites could possibly require all of the permissions the zone entails. Because of this design, adding sites to privileged zones can once more have unexpectedly far-ranging consequences in the case of, say, a trivial XSS flaw.
To maintain the integrity of the zone model on downloaded files, Internet Explorer further utilizes two overlapping mechanisms to track the original zone information for any externally retrieved document:
Mark of the Web (MotW) This simple pseudo-HTML tag is inserted at the beginning of HTML documents downloaded via Internet Explorer to indicate their initial source.[238] One example of a MotW tag may be <!-- saved from url=(0024)http://fuzzybunnies.com/ -->. The URL recorded in this tag is mapped to an appropriate zone; the document is then opened in a unique origin in that zone. The most important consesequence is that the downloaded content is isolated from other file: URLs.
The inline nature of MotW is one of its flaws. Faux tags can be pre-inserted by rogue parties into HTML documents downloaded through non-Internet Explorer browsers, saved from email clients, or downloaded by Internet Explorer with a non-HTML extension (and then subjected to content sniffing). Though, to be fair, the privileges of file: documents saved without any MotW tags are significant enough to keep attackers relatively uninterested in hopping from the My Computer zone to, say, Local Intranet.
Alternate Data Stream (ADS) Zone Identifier This is a piece of NTFS metadata attached by Internet Explorer (and Chrome) to every downloaded file, indicating the numerical code of the zone the file was retrieved from.[239] The Zone.Identifier mechanism is less portable than MotW, and the information is lost when files are saved to non-NTFS filesystems. However, it is also more versatile, as it can be applied to non-HTML documents.
Zone.Identifier metadata is recognized by Internet Explorer itself, by the Windows GUI shell, and by some other Microsoft products, but third-party software almost universally ignores it. Where it is supported, it may result in a more restrictive security policy being applied to the document; more commonly, it just pops up a security warning about the unspecified risks of opening Internet-originating data.
[76] In configurations where a proxy is required to access protected internal systems but not required to access the Internet, these may have the unintended and scary effect of classifying the entire Web as a local network.