Please read my blog's comment policy here.
Update: IE9 includes improved handling of Mixed Content. Click to learn more...
As we developed Internet Explorer 8, we spent quite a bit of time pondering what to do about IE7’s infamous “Mixed Content” warning prompt:
As I noted on the IEBlog four years ago, the mixed content warning occurs when a web developer references an insecure (http) resource within a secure (https) page. Such references create vulnerabilities that put the privacy and integrity of an otherwise-secure page at risk, because the insecure content could be modified in transit. If added to the DOM, insecurely-delivered content can read or alter the rest of the page even if the bulk of the page was delivered over a secure connection. These types of vulnerabilities are becoming increasingly dangerous as more users browse using untrusted networks (e.g. at coffee shops), and as attackers improve upon DNS-poisoning techniques and weaponize exploits against unsecure traffic.
From a security standpoint, our best option would be to suppress the prompt altogether and simply make the secure choice on the user’s behalf, blocking all insecure content in secure pages. Unfortunately, as I mentioned in my MiX 2009 Security session, security is usually easy, but tradeoffs are often hard. If we were to simply automatically block the insecure content, we risk confusing the user; pages which rely on insecure images, stylesheets, or scripts could appear broken. In the worst case, the user might think the broken pages indicate a bug in IE8 and subsequently revert to an older version of the browser to get the prompt and unbroken pages.
In an attempt to resolve the compatibility / security tradeoff, we experimented with a number of concepts. For instance, we tried blocking insecure content in secure pages by default, with an information bar that allowed refresh of the page with mixed content permitted.
In our testing, we discovered a number of important scenarios where this approach introduced a much more severe problem-- data loss. For instance, when the user is composing a blog post or email message on a secure site, they might type or copy/paste a reference to an insecure resource within that message. When the information bar is subsequently used to unblock the mixed content, the blog post or email message would be lost because the web application was refreshed. If we didn’t refresh the page after permitting the mixed content, the page could break anyway, because the insecure resource would be run out of its normal order.
Ultimately, we concluded that removing the prompt wasn’t feasible. In IE8, we continue to rely on web developers to fix their pages to remove insecure content vulnerabilities; pages without such vulnerabilities won’t trigger the prompt.
Though we couldn’t get rid of it entirely, we did make some improvements to the prompt to correct several violations of our secure design principles. We identified three major problems with the older version:
1> The secure choice is not the default option.
2> The prompt does not clearly identify that the user is being asked to make a security decision.
3> The prompt does not offer the user enough information to make a safe choice. Specifically, it doesn’t indicate what the consequences of their choice might be.
To address these issues, we changed the default behavior of this prompt such that the secure option is the default; if the user simply clicks through, the page remains secure. We also updated the title, question, and explanatory information to help users understand the implications of the security decision they are being asked to make. The new prompt appears as follows:
If the user chooses “No,” then the insecure resources are displayed in the page and the lock icon is removed from the browser address bar.
If you encounter a mixed content warning, feel free to point the website administrator to the following section of this blog post to help them fix the bug in their site.
Users may choose to suppress mixed content warnings by adjusting browser security settings. Inside the Tools / Internet Options / Security / Internet Zone / Custom… dialog, the “Display mixed content” option can be set to “Disable.” This option will automatically block insecure content in secure pages without the annoyance of the prompt. In many cases the web page will not be seriously broken; in some cases, no user-visible change will occur, for instance, if the insecure content was a tracking pixel or metrics-tracking script.
Similar configurations can be made to the Intranet Zone and Trusted Zone settings. Within some organizations, it may be appropriate to set the Intranet zone option to “Enable,” because it is less likely that an attacker outside the organization could exploit Intranet sites containing mixed content. In contrast, while it might be tempting to set the “Trusted” zone setting to “Enable,” it’s important to remember that in the face of a DNS-poisoning or man-in-the-middle attack, even “trusted” HTTP traffic could be intercepted.
Note: There's one other important factor to keep in mind-- IE checks the Security Settings for the Zone of the insecure content, not the Security Settings of the Zone of the page. Intuitively, that's seems quite backwards, doesn't it? It certainly seemed surprising and wrong to me when I first learned about it.
However, if you think harder about it, it turns out that it makes perfect sense: you (the user) may know that you have a "safe" connection to a particular zone (say, the Intranet) and hence any content that is coming from that Zone can be transfered without HTTPS but remain secure (say, because your organization's firewall prevents tampering by external attackers). In contrast, if you were visiting a HTTPS page on your Intranet, and it tried to pull in insecure content from the Internet, it would be incorrect for the browser to say "Well, the outer page is trusted, so we'll let unprotected content from another source be mixed in."
For security and user-experience reasons, mixed content vulnerabilities should be fixed by the web developer. In principle, this is very simple: within a HTTPS page, never include a link to a HTTP-delivered resource.
One trick which might be useful is to use protocol-relative hyperlinks, of the form “//example.com/image.gif”. When the user visits a secure page containing such a reference (e.g. https://example.com/page.htm) the resulting URI will be evaluated as https://example.com/image.gif. On the other hand, if the user visits the same page using HTTP, the resulting URI will be evaluated as http://example.com/image.gif. In this way, site developers can easily build pages that work for either HTTP or HTTPS without introducing a mixed content vulnerability.
If you simply remove the SRC attribute from this tag (since it's not performing a download), you will find the problem goes away.
If you encounter a mixed content warning while working with your site, you may be able to use IE’s built-in developer tools to search for the insecure reference. However, it’s also possible that a HTTPS URL returned a redirect to an insecure resource, which could be difficult to determine by examining the DOM alone. The Fiddler web debugger can help troubleshoot the problem; simply follow these steps:
1> Start Fiddler
2> Clear the browser cache
3> Hit CTRL+F5 to reload the page
4> In Fiddler, click the Protocol column to sort by requests by protocol
6> Eliminate the use of those HTTP URLs or update any secure redirectors pointing to HTTP resources
By removing mixed content vulnerabilities, you can protect the integrity and privacy of the content on your secure pages, and avoid annoying your visitors with this security prompt.
Thanks for your help in securing the web!
@Kyle: Unfortunately, no such option exists (although I did propose it). One thing you might try is to intercept the paste, parse the content, and if there are any links, replace the URLs with a "temporary" secure URL (or just remove them temporarily). Then, when the user actually performs the post, you could "fixup" your blocked URLs.
I believe this is how Outlook Web Access handles this scenario, although I haven't tried it in a while.
Hi Eric, thanks for the post and of course thanks for fiddler! May I suggest that the MoreInfo button on the dialog would be alot more helpful if it actually listed the path of the resources that were insecure (then it could have the help-file button on that dialog). This information is not only incredibly useful to developers trying to secure their sites (witness the posts here!) but it is also pertinent to *any* user who encounters this message and allows them to take a slightly more informed choice of the risks. Besides each file listed there could even be specific security info for the file-type (e.g. low-risk images, high-risk forms etc). For developers, it's great that tools like Fiddler & the EnhanceIE script exist, but the answers should simply be revealed in IE; at the moment it feels like IE knows the answer but purposefully withholds it so that developers have to embark on a sort of insecure-resource-treasure hunt (that isn't actually that much fun)! Thanks again for fiddler, can't say it often enough!
@tabba: :-) Have you looked at the console tab in the IE9 Platform Preview Build #3? Expect a blog post on this topic on the IEBlog in the IE9 Beta timeframe.
Heh heh - Hey Eric, no that's your job! We're far too busy securing content on our websites ;o) Sounds like something good to look forward to though, will await blog-post happy knowing you've got it all under control! Your script is a real-lifesaver btw, so thanks for that too, popped up an offending item we had 5 secs after installing - would advise anyone with probs to go straight for the script; we had some absolute refs to images in a bit of css nested in a jquery call so it had been proving a bit of a headscratcher reviewing code manually... thanks again
I have tried the option that is mentioned above. But even after allowing the Mixed content, I'm still getting the prompt. Any ideas?
You likely set the option for the incorrect zone. Do you have a repro URL?
Eric, I've got a web app that should run over HTTPS. However, we as many other have, are running into the mixed content issue. The application in question is Activ-x-based and uses java scripting. Via Fiddler I can see no calls to any other web site other than the proper URL. However, our developers seem to think that the issue is casued by the Active-x component accessing files that are stored on the local PC's file system, outside of the Browser's cache. The app allows users to select a batch of documents that has been scanned and stored on the server for review. The client downloads a set of thumbnail representations of the full sized images and stpres them in a set of applciation-specific folders. We believe that IE is viewing the locahost's file system as a zone separate from Internet, Intranet or Trusted. Any thoughts?
@Misery: Generally speaking, no, IE's not that smart-- it doesn't know what your control is doing with the filesystem.
Did you try running your repro using my "Script Free" plugin referenced above to find the URLs that are causing the Mixed Content warning?
@Eric: yes, I did try "Script Free" and it defiantely confirmed the suspicion that the mixed content was caused by the Active-x control accessing files in the local file system. However, it is only the thumbnail versions of the scanned document that seem to be unsecured, the full size image files are not causing a mixed content problem, though they are stored in the same directory structure. Are there different methods of accessing the files system where some are considered secure and others not?
@Mixed: Please elaborate-- what are the URLs specifically? IE doesn't care what files the ActiveX control loads. If, however, the ActiveX control directs IE itself to render insecure content (e.g. creates an IMAGE element in the containing document and directs that IMAGE element to load, say, file:///Something.jpg") then that will cause a Mixed Content prompt.
I think what you just described above is what is happening. The URLs that are causing the problem look like this: file:///C:/Documents%20and%20Settings/userID/Application%20Data/Capture/Batch/thumb.1.gif.
Thanks very much for your help. I guess they will just need to change the app to call the thumbnails to load in the same way that the full size image is loaded. That is why I'm confused, the full sized images are in the same directory structure and they get loaded with no issues. That is why I asked if there were different ways of dealing with local files.
What are they doing to load the full-size images? My guess (based on the information provided thus far) is that they're using the ActiveX control itself to display those; since IE has no real idea what's going on in the control, there's no prompt for those images.
I wish I knew what they are doing. I'm just the services guy who is trying to prevent a huge customer sat issue. However, the client is segmented into components (from a UI point of view) and I could easily see the Active-x controls working in some sections and not in others. While I can't fix it, you've given me invalueable information that really pin-points the issue and removes any argument that IE is not working as it should. Thanks again.
We can't seem to get the Protocol Relative URLs to work. This was/is the perfect solution to our problem, as we do not want to deal with changing a user's browser settings for a number of reasons.
When we use the Protocol Relative URLs, the images and style sheet located on the non-secure server are not loaded. Any ideas?
@Suzanne: Please provide a repro page. Thanks.