Internet Explorer 9 Security Part 4: Protecting Consumers from Malicious Mixed Content
Mixed content on a Web page puts consumers at risk of man-in-the-middle attacks, especially as consumers spend more time browsing from untrusted public networks (like free WiFi in coffee shops and airports). An attacker can view page content that a consumer expected to be delivered securely, and even modify the contents of the page without the consumer knowing it. This happens when Web sites void the security promise of HTTPS by including content delivered by HTTP into their otherwise secure HTTPS pages. IE9 helps you stay secure. When a HTTPS site includes unsecure HTTP content, Internet Explorer 9 blocks the unsecure content to help keep your information safe.
One of my first posts on the IEBlog detailed two critical mistakes common on Web sites with HTTPS. While a lot has changed on the Web in the six years since that post was written, unfortunately it’s still common to see these problems.
Understanding the Risk of Mixed Content
An attacker can replace any unprotected, unsecure HTTP content on an otherwise secure, HTTPS page with a “poisoned” version. For example, when you visit https://www.youtube.com with different browsers and a man-in-the-middle attacker present, you’ll see different results. Most other browsers just show the unprotected content automatically, allowing a spoofing or information disclosure attack, as seen here in Chrome 13:
Internet Explorer 9 blocks the content from the unsecure frame at the top of the page because its presence compromises the security of the page:
How the Attack Works
Web pages delivered over HTTP are much like “postcards” – anyone along the delivery path can see what they contain, and can even deface or change the content of the message. Web pages delivered over HTTPS are more like “sealed envelopes” that protect the content inside from modification or disclosure. Going along with this simile, when a page mixes both HTTPS and HTTP, it’s as if the envelope has been unsealed, eliminating the benefit of using HTTPS to begin with.
This happens when any part of the page uses HTTP rather than HTTPS to refer to content… a script, stylesheet, object, or frame. Malicious content can rewrite the page, steal its content, or entice the user to perform some unsafe action (e.g. “download a required plugin” which is really malware).
You can further explore this type of attack using the IE Test Drive Mixed Content Demo page:
Unsecure Images
While Internet Explorer has helped protect users from Mixed Content vulnerabilities for over a decade, IE9 includes additional smarts to distinguish between what types of unsecure references exist in the page. If a HTTPS page contains unsecure images, the images are permitted by default. We did this to provide a friendlier user-experience given how frequently Web sites make this mistake with images.
When we looked at the prevalence of unsecure content on popular real-world Web sites, we found that in many cases, the unsecure content was simply one or more small images. Unsecure images are the least risky type of mixed content because an attacker can only modify the content of the image itself, and cannot use that image to run script that attacks the rest of the page. In some cases, these images were just tracking beacons (which can be silently blocked by IE9’s Tracking Protection feature, avoiding the mixed-content warning entirely). However, in many cases, these images were product logos, bullet icons, and the like.
When an HTTPS contains unsecure images, the lock icon is removed from the address bar to indicate to the user that not all content was delivered securely. For example, the page on the left below (link) is delivered over https and includes an image also delivered over HTTPS; the one on the right (link) contains an unsecure image. The image is shown, but the lock icon is removed from the address bar:
Users can change this behavior, and have Internet Explorer block display of unsecure images on secure pages. Inside Tools > Internet Options > Advanced, check the Block unsecured images with other mixed contentbox in the Security section.
Better Protection with the Descendants rule
Internet Explorer 9 includes stronger protection against Mixed Content vulnerabilities by blocking unsecure content in HTTPS-delivered frames, even when the top-level page itself is unsecure.
This protection is necessary because unsecure content running in a HTTPS subframe is still dangerous—it can steal or pollute the HTTPS-delivered frame’s cookies and HTML Storage, perform cross-site request forgery attacks, or perform other mischief. Web Developers are sometimes surprised when they encounter an “Only secure content is displayed” warning on a HTTP page, particularly in cases where the HTTPS frame isn’t as visible as it is in this test page:
The best way to think about this is what I call the Mixed Content Descendants Rule: All descendant resources inside a HTTPS-delivered frame must also be delivered via HTTPS, or they will trigger the browser’s Mixed Content protection.
Unfortunately, this protection caused some temporary hiccups for many sites that are using a widget from a popular social network. That widget used a HTTPS subframe which itself contained a HTTP subframe-- it used this architecture as a part of a rudimentary cross-domain communication mechanism. The widget is being updated to remove the unsecure subframe and it will instead use the HTML5 postMessage API for communication between the widget’s frame and the parent page.
Troubleshooting Mixed Content with the F12 Developer Console
Internet Explorer 9 helps Web developers discover the source of Mixed Content warnings with the F12 Developer Tools’ Console. When the browser encounters an unsecure resource within a secure page, a warning message is shown in the Console. The message includes shows the URL of the problematic unsecure resource:
This feature dramatically simplifies the process of discovering what content on a page is insecure, resolving a top-pain point for Web developers using IE8. Developers can then fix their content to remove the insecure reference, unblocking the page and ensuring that the lock is shown.
Tip: Some pages are accessible over both HTTP and HTTPS, and Web developers may not want to use HTTPS except when the user visits the page over HTTPS. A useful trick is to specify the source of the page’s resources using 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.
For more information about IE9’s security protections, you can read the previous posts in this series (Part 1, Part 2, Part 3). Thanks for your help in securing the Web!
Eric Lawrence
Program Manager
Comments
Anonymous
June 23, 2011
I ran the test in Chrome and while it's true, it's also true that the https:// in the location bar turned red and was strikeout, and a sign of warning something has gone wrong (not sure why this didn't work for you, but at least there appears to be a warning sign). In Firefox you can also see the bar doesn't turn green. That's probably the best you can do: either the user pays attention or it's useless.Anonymous
June 23, 2011
This is fixed in Chrome 14.Anonymous
June 23, 2011
The comment has been removedAnonymous
June 23, 2011
Chrome will block sites with mixed scripting, but not mixed display content, in Chrome 14 - googleonlinesecurity.blogspot.com/.../trying-to-end-mixed-scripting.htmlAnonymous
June 23, 2011
@Larry: Thanks for the link. It's unfortunate that chrome will not be blocking insecure frames, as (by default) these frames, if poisoned, can display misleading webforms, run script, navigate the user to a malicious top-level page, etc.Anonymous
June 23, 2011
@EricLaw: Hi Eric, I have a question. Ever since Facebook switched to HTTPS by default, a lot of pages (pretty much every page with a Facebook like button on it) gives this warning. Is there anything I can do to prevent that warning? As a random example, I see this warning on http://www.thebookofbiff.com.Anonymous
June 23, 2011
I don't want to see testdrive/Dev builds of IE. I wish it was beta and then a month or 3 later call it a full new version. Look at mozilla they will be at version 8 by the end of 2011. come on Microsoft step your game up. Make IE14 be out by the end of the year. Also give IE a better speed boost.Anonymous
June 23, 2011
"Unsecure images are the least risky type of mixed content because an attacker can only modify the content of the image itself, and cannot use that image to run script that attacks the rest of the page." : maybe now there are protections built in the browser, but some years ago, scripts could be embeded in images and cause some damages... :-/ @Mike: the way Chrome and Firefox are versioned is stupid. Why do you want others people to follow that ?Anonymous
June 23, 2011
The comment has been removedAnonymous
June 23, 2011
Guys Plzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz Have Mercy on developers. PLEASE STOP DEVELOPING INTERNET EXPLORERAnonymous
June 23, 2011
@Aethec: While it's true that Mozilla ignored corporate users in their rapid release cycle, there are currently no plans for Firefox 8. Tha last planned Version is 7, after that it will be re-evaluated if the rapid release cycle was successful or not. Also, contrary to Mozilla, Microsoft implements compatibility modes which allow corporate users to install IE.next and have their tools use IE 5 or 7 etc. Aside from that, I'd prefer if IE was released once a year. This allows a good chunk of progress while not holding back the web for ages.Anonymous
June 23, 2011
@Sven: If you hit F12 on the page in question, you'll see a very long list of URLs where the page is using HTTP resources inside a HTTPS frame. @Olivier: The issue you mention about "script hidden in images" were fixed years ago, and they weren't exploitable in this scenario anyway.Anonymous
June 24, 2011
@Daniel.S: I think we can already say "no". Just look at the wonderful FF roadmap for version 6 and 7:TBD
TBD
TBD
...anything that improves responsiveness and is ready
...anything that improves stability and is ready
...anything that polishes the user interface and is ready
...anything else serving product priorities and is ready (source: wiki.mozilla.org/.../Roadmap ) Having entreprises use Firefox would be a big boost for them because people would realise there are other web browsers and maybe want to switch. (of course, this kind of thing doesn't happen in a day, and since Mozilla wants everything to happen instantly...)
Anonymous
June 24, 2011
Hmm, where's my message? Oh well... @Aethec: I don't see your point here. Also note that there is a difference between corporate usage and corporate installations. If a company builds its internal applications or intranet websites with Gecko in mind, that will eventually fail (it already did a few times in the past). However, if companies install Firefox for daily use of the internet, there will be no real problems. In fact, my own company uses IE for intranet and Firefox for internet. New releases are quickly distributed as well. Requiring Gecko for internal usage is a bad idea for many reasons. Mozilla can't nor would they wan't to support one of their products as long as Microsoft does. Please realize that IE9 will be supported until 2020. That's almost as long as we have to deal with IE6. That's surely not good for the web and I think people don't realize this when they blame Mozilla for not taking their Mission seriously. The good thing is, however, that upgrading IE is a lot easier now than it was years ago when IE7 was released. So we can expect faster adoption rates with new IE versions.Anonymous
June 24, 2011
Sorry, but "unsecure" is not actually a word.Anonymous
June 25, 2011
The main issue with HTTPS is that it costs extra to get the required unique IP for an SSL certificate.Anonymous
June 26, 2011
Alexey: Sorry, but "unsecure" really is a word... dictionary.reference.com/.../unsecuredAnonymous
June 27, 2011
The comment has been removedAnonymous
June 28, 2011
f.aa - your link does not further your case. Dictionary.com is one of the loosest references you can find, and even it has no matches for "unsecure".