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 login.live.com and mail.live.com, or across multiple protocols (e.g. httpS://example.com and https://example.com). When we investigate these issues, we invariably find that the user’s browser is configured with one site in one zone (e.g. https://login.live.com is in the Trusted Sites zone, or only the HTTPS version of example.com is in the Trusted Zone) and the other site is in a different zone (e.g. mail.live.com and example.com 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 Login.live.com server to the Trusted Zone.

  1. The user types mail.live.com into their browser address bar.
  2. The mail.live.com server observes that the user is not logged in and redirects to Login.live.com
  3. Login.live.com allows the user to enter their credentials, validates them, and returns a login cookie.
  4. This login cookie is stored for *.live.com in the Medium Integrity Cookie store.
  5. Login.live.com then redirects the user back to mail.live.com.
  6. mail.live.com examines the (Low Integrity) cookie store for a login cookie.
  7. Not finding the login cookie, mail.live.com redirects to Login.live.com
  8. Login.live.com 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, login.live.com redirects the user back to mail.live.com
  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 mail.live.com had placed login.live.com 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

Comments

  • Anonymous
    July 21, 2011
    I want to know if we redirect from HTTP to HTTPS, should IE send the session cookie with HTTPS request? Host: mpcb.mu (for HTTP)
    Host: secured.mpcb.mu (for HTTPS) Here are the cookie attributes set from the server: Set-cookie: JSESSIONID=4E8CEB2926EFD; Path=/ ; HttpOnly

  • Anonymous
    July 21, 2011
    @Anshu: If the pages are in the same zone (as described in this article), then yes, the insecure cookie will be sent to the secure subdomain by IE only. See Q3 at blogs.msdn.com/.../wininet-ie-cookie-internals-faq.aspx

  • Anonymous
    September 25, 2011
    The comment has been removed

  • Anonymous
    March 05, 2012
    Will wininet use the cookie in the request when i have a Referrer set in a different domain that is loading in Internet zone? Sample request:

  • Http: Request, GET http://intranetsite    Command: GET  + URI: http://intranetsite    Accept:  /    Referer:  http://internet.site.com    Cookie:  cookieset Does Referrer really matter to set a cookie? From my analysis, i see the cookie is used when either protected mode is turned on/off in both the zones. Thanks in advance

  • Anonymous
    May 09, 2012
    I think I encountered an even stranger case of this.  I have a Silverlight application that runs in the browser.  The HTML page hosting the <object/> tag, and the XAP file it points to, is all delivered via http://launch.mydomain.com.  Once launched, the Silverlight application uses WCF to httpS://service.mydomain.com except for displaying PDF documents which is does by popping a window open to httpS://service.mydomain.com with a GET request.  Now the cookie in question is delivered in the HTTP response header to one of the WCF calls to httpS://service.mydomain.com.  Depending on whether the page that delivered hosted the <object/> tag in the first place is in the same security zone affects the delivery of the cookie.  On the one hand, I get it.  But on the other hand, the cookie was both delivered and attempting to be re-sent to one zone -- the zone of httpS://service.mydomain.com.  But, in IE9 at least, the zone of the page hosting the Silverlight control still impacted the function.

  • Anonymous
    February 17, 2014
    Hi, Browser cookies vanish in IE8 when opening a new window to a different sub-domain. we fixed it by setting the second domain as trusted site. But, How do we handle this programatically when we are using cookies? [EricLaw] It's not entirely clear what you're asking. As explained by this post, if you have scenarios that cross between security zones (e.g. Trusted to Internet or vice-versa) then cookies are not shared between the pages in those zones. The only workarounds are to 1> not use cookies, or 2> Ensure that all pages in the scenario are mapped into the same zone in the client's browser settings.

  • Anonymous
    February 22, 2014
    We have two sites (site1 and site2)  hosted with different domains. SSO and everything working fine on IE8 except one scenario. Issue is: Having problem with a new window (popup) in IE8, it is being redirected to login page when popup opensup. its working fine on our machines but not on client machine. Could you please advice what could be the cases causing this to redirecting to login page? [EricLaw] Do you have a Fiddler capture or similar that would allow us to track what cookies are being received and sent?