Please read my blog's comment policy here.
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.
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 http://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.
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!
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
@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
Re this statement: "users may view all of their Zone assignments by clicking Tools > Internet Options > Security > Trusted > Sites…." It becomes more complicated if there are group policies dictating that only machine settings are used, and/or group policy dictates one or more site-to-zone-assignment lists. See
Will wininet use the cookie in the request when i have a Referrer set in a different domain that is loading in Internet zone?
- Http: Request, GET http://intranetsite
+ URI: http://intranetsite
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
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.