Trying to end mixed scripting vulnerabilities

Thursday, June 16, 2011 11:37 AM



A “mixed scripting” vulnerability is caused when a page served over HTTPS loads a script, CSS, or plug-in resource over HTTP. A man-in-the-middle attacker (such as someone on the same wireless network) can typically intercept the HTTP resource load and gain full access to the website loading the resource. It’s often as bad as if the web page hadn’t used HTTPS at all.

A less severe but similar problem -- let’s call it a “mixed display” vulnerability -- is caused when a page served over HTTPS loads an image, iFrame, or font over HTTP. A man-in-the-middle attacker can again intercept the HTTP resource load but normally can only affect the appearance of the page.

Browsers have long used different indicators, modal dialogs, block options or even click-throughs to indicate these conditions to users. If a page on your website has a mixed scripting issue, Chromium will currently indicate it like this in the URL bar:



And for a mixed display issue:



If any of the HTTPS pages on your website show the cross-out red https, there are good reasons to investigate promptly:
  • Your website won’t work as well in other modern browsers (such as IE9 or FF4) due to click-throughs and ugly modal dialogs.
  • You may have a security vulnerability that could compromise the entire HTTPS connection.
As of the first Chromium 14 canary release (14.0.785.0), we are trialing blocking mixed scripting conditions by default. We’ll be carefully listening to feedback; please leave it on this Chromium bug.

We also added an infobar that shows when a script is being blocked:


As a user, you can choose to reload the website without the block applied. Ideally, in the longer term, the infobar will not have the option for the user to bypass it. Our experience shows that some subset of users will attempt to “click through” even the scariest of warnings -- despite the hazards that can follow.

Tools that can help website owners
If Chromium’s UI shows any mixed content issues on your site, you can try to use a couple of our developer tools to locate the problem. A useful message is typically logged to the JavaScript console (Menu -> Tools -> JavaScript Console):


You can also reload the page with the “Network” tab active and look for requests that were issued over the http:// protocol. It’s worth noting that the entire origin is poisoned when mixed scripting occurs in it, so you’ll want to look at the console for all tabs that reference the indicated origin. To clear the error, all tabs that reference the poisoned origin need to be closed. For particularly tough cases where it’s not clear how the origin became poisoned, you can also enable debugging to the command-line console to see the relevant warning message.

The latest Chromium 13 dev channel build (13.0.782.10) has a command line flag: --no-running-insecure-content. We recommend that website owners and advanced users run with this flag, so we can all help mop up errant sites. (We also have the flag --no-displaying-insecure-content for the less serious class of mixed content issues; there are no plans to block this by default in Chromium 14).

The Chromium 14 release will come with an inverse flag: --allow-running-insecure-content, as a convenience for users and admins who have internal applications without immediate fixes for these errors.

Thanks for helping us push website security forward as a community. Until this class of bug is stamped out, Chromium has your back.
The comments you read here belong only to the person who posted them. We do, however, reserve the right to remove off-topic comments.

13 comments:

BananaSlug said...

I get the mixed display issue in Gmail all the time...
Does this mean the entire HTTPS session is shot?

Motoma said...

Hey that's great; now if only AdSense would start serving over HTTPS.

Erik said...

This happens a lot in Google Reader, too. Particularly when a feed embeds to a Youtube video.

Chris said...

@BananaSlug: (nice nick ;-) mixed display isn't too bad; the HTTPS session isn't automatically shot. Probably, an HTML e-mail had an img tag to some HTTP resource? Longer term, perhaps they can be proxied.

@Motoma: interesting, do you have a sample URL that only works over HTTP?

fugufish said...

question regarding cross-browser origin errors:

will this affect iframed web apps that load the files from another website?

eg:

a facebook canvas game takes it's files from a server and displays it to the user.

normally, in the debug console this would occur (but it will still pass normally:

Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/app_name/ from frame with URL http://anothersite.com. Domains, protocols and ports must match.

Melvin Ram said...

YouTube videos are a common culprit. Please add HTTPS support to YouTube before releasing this feature.

Adam Barth said...

@MevlinRam: Very true! I believe YouTube does now support HTTPS embedding.

Larry Seltzer said...

Isn't the answer to this, from the attacker's standpoint, to serve malicious scripts and other content from HTTPS sites? You can get CA-issued certs for free these days.

Larry Seltzer said...

And about the default-block of mixed scripting in Chrome 14, I frequently get mixed scripting errors in Reader and maybe even in GMail. What happens in those cases? Maybe they should be blocked. I wish it would be possible just to strip the scripts.

Chris said...

@Larry: There are some bug fixes underway in Reader. If you get the infobar in Gmail, put a comment here on how to reproduce it and it'll get fixed.

Regarding the attacker's standpoint, the attacker doesn't have any control over where the scripts are loaded from. So getting https://www.evilscripts.com/ won't help the attacker defeat mixed scripting blocks.

Ericlaw said...

Is the reason that Chrome will continue to allow insecure subframes because AdSense does not support HTTPS and blocking insecure subframes would break Google's revenue stream?

Yuhong Bao said...

EricLaw: It seems that AdSense is based on a script loaded from Google which do not support HTTPS:
https://www.google.com/adsense/support/bin/answer.py?answer=10528
Linking to this script using HTTP on a HTTPS site would be a mixed scripting attacks that would be blocked.
You can see this for example if you visit LKML.

Yuhong Bao said...

Actually, the AdSense script URL seems to work via HTTPS now. But I can't really see any danger if there is no script inside the IFRAME.