Share via

Beware Cookie Sharing in Cross-Zone Scenarios

Note: I mentioned this problem before ( Troubleshooting Login Cookies #3 ) but it was buried in a long post and this is an issue that lots of folks inside Microsoft hit, so I’m pulling it out into its own post.

The Problem

From time to time, various users have complained to the IE team that they’re unable to log into assorted websites and services that they care about: Hotmail and GMail are two common examples. They report that after entering their credentials into the login page, the page seems to get caught in some sort of redirect loop, redirecting from the login page to the site back to the login page. This pattern either continues endlessly or until an error message is displayed.

What these scenarios have in common is that the login page and the web application are on servers with different hostnames, for instance and, or across multiple protocols (e.g. httpS:// and When we investigate these issues, we invariably find that the user’s browser is configured with one site in one zone (e.g. is in the Trusted Sites zone, or only the HTTPS version of is in the Trusted Zone) and the other site is in a different zone (e.g. and are in the Internet zone).

Determining the Zone

Oftentimes, the user is unaware of this distinction, either because they moved one site into the Trusted Sites zone a long time ago, or their IT Department used Group Policy’s Site-to-Zone Assignment feature to move a site into the Trusted Sites zone without the user even knowing that this happened. In some cases, users hit this problem because their company Intranet is fragmented across multiple zones due to an incorrect proxy configuration.

Tip: In IE8 and below, the current page’s Zone is listed in the browser status bar at the bottom of the screen. In IE9, the Zone information was moved to the Properties dialog, available on the context menu for the page. Alternatively, users may view all of their Zone assignments by clicking Tools > Internet Options > Security > Trusted > Sites….

Why is having related sites in different Zones a problem?

The problem is that sites in the Internet and Restricted Sites zones run in Protected Mode (Low Integrity), and sites in the Local Intranet, Trusted Sites, and Local Machine zones (Medium Integrity) run outside of Protected Mode. For security reasons, each Integrity level maintains its own isolated cookie store. This is problematic when two servers expect to share cookies but cannot because they are running at different Integrity levels.

For instance, consider the Windows Live Hotmail case, where the user has moved the server to the Trusted Zone.

  1. The user types into their browser address bar.
  2. The server observes that the user is not logged in and redirects to
  3. allows the user to enter their credentials, validates them, and returns a login cookie.
  4. This login cookie is stored for * in the Medium Integrity Cookie store.
  5. then redirects the user back to
  6. examines the (Low Integrity) cookie store for a login cookie.
  7. Not finding the login cookie, redirects to
  8. examines the (Medium Integrity) cookie store, and finds that the user’s login cookie is still valid.
  9. Since the user’s login cookie is still valid, redirects the user back to
  10. Steps 6-9 repeat a number of times until the service detects a loop and shows an error page.

The fix is pretty simple: just remove the site from the Trusted Zone. After you do this, step #4 stores the login cookie in the Low Integrity store, and the mail site is able to retrieve it. Generally speaking, there are very few reasons that you should ever need to put a site in the Trusted Sites Zone (I blogged about one reason a while ago).

Other than Cookies, are there other problems?

We most often see this problem with cookies, but technically, this could happen in any case where storage is partitioned by zone. For instance, the web browser cache is partitioned by Zone, as are the HTML5 sessionStorage and localStorage areas. Unless an ActiveX control or browser plugin uses a broker or was carefully written to write to shared space, its settings will likely be isolated by Integrity level. For instance, the Mouse Gestures Add-on requires you to configure gestures once for Internet/Restricted sites and again for Intranet/Trusted sites, because the gesture configuration settings are stored in registry keys that are virtualized when running in Protected Mode.

I'm a Web Developer: is there anything I should do?

Web pages cannot directly detect what Zone they are running in. However, they can send querystring parameters when redirecting between cooperating sites. If the querystring parameter indicates that the user just came from a site that set a cookie, but that cookie isn't present on the request, the user either has cookies disabled or restricted, or the two cooperating sites are in different zones. An error page should be displayed to help the user adjust their configuration.

In some cases, the problem can be avoided by clever use of frames. Internet Explorer uses the top-level page to determine the integrity level of all frames in the page. So, if had placed within a subframe, rather than performing a top-level navigation to that page, the cookies from the subframe are guaranteed to be in the store of the same Integrity level as the top-level page. Note: If you do rely on setting cookies from subframes, be (especially) sure to follow best practices and ensure that the cookie-setting page in the subframe declares a proper compact P3P policy using the P3P header. If you don't set proper P3P headers on a cookie from a cross-domain frame, IE will generally drop the cookie for privacy reasons.

Can Browser add-ons or other applications running at Medium Integrity read/write Low Integrity stores?

In the case of cookies, there are APIs that permit your code to read/write cookies in the Protected Mode storage area. However, APIs are generally not available (or supported) for reading or writing to other partitioned storage areas.

Thanks for reading!

-Eric Lawrence