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 content box 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