June 16, 2011

Trying to end mixed scripting vulnerabilities



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.

15 comments:

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

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

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

    ReplyDelete
  4. @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?

    ReplyDelete
  5. 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.

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

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

    ReplyDelete
  8. 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.

    ReplyDelete
  9. 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.

    ReplyDelete
  10. @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.

    ReplyDelete
  11. 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?

    ReplyDelete
  12. 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.

    ReplyDelete
  13. 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.

    ReplyDelete
  14. 為何婚后男人更“萎”了?
    性功能障礙所致這是發生陽萎原因主要之一,約占陽萎總數威而鋼 犀利士哪裡買 壯陽藥品 壯陽藥 威而鋼哪裡買 犀利士專賣 威而鋼 威而鋼哪裡買 威而鋼專賣店 威而鋼藥局 情色貼圖的百分之九十左右,由性功能障礙引起的陽萎主要表現在:  1.精神因素所致。男子在情緒不佳,如悲痛、憂愁、恐懼、焦慮、抑郁或過度緊張時,大腦皮層的功能失調,造成性功能失調,引起陽萎。另外,缺乏性知識,對性生活缺乏正確認識,或受某種刺激,都會影響性功能,犀利士 犀利士 犀利士 犀利士 犀利士 威而鋼 威而鋼 威而鋼 威而鋼 威而鋼 威而鋼 威而鋼 威而鋼 犀利士 壯陽藥品去哪買 犀利士 犀利士 犀利士 犀利士 犀利士 威而鋼 犀利士以致引起陽萎。
      2.男子過度勞累或身體衰弱,就會引起大腦皮層活動障礙,從而影響性功能,出現陽萎。
      3、婚后房事過額,或婚前長期手淫,侵大腦皮層性中樞經常處于興奮狀態,從而引起性中樞疲勞而轉入抑制狀態,出現陽萎。
      4.長期酗酒、吸煙或經常服用鎮靜藥,使大腦皮壯陽藥 威而鋼 壯陽藥 犀利士 犀利士 犀利士專賣 犀利士哪裡買 犀利士5mg價格 壯陽藥品 犀利士專賣 威而鋼 壯陽藥 威而鋼專賣店 犀利士哪裡買層處于抑制狀態,導致性功能減弱,從而出現陽萎。
      吃壯陽菜應審“時”度“勢”:所謂度勢,即必須根據自身具體情況而定。個人由于年齡、體質等方面的差異,在食療進補時也會出現不同。壯陽藥 壯陽藥品 犀利士 威而鋼 威而鋼哪裡買 犀利士 犀利士 壯陽藥品 壯陽藥比如,年紀大的人不宜過補,燥熱體質的人不宜在夏季食用過多食補物品。如果是對某些食物有過敏性反應的就更應該注意了。

    ReplyDelete
  15. What if the google.com(https://www.google.com.ph/?gfe_rd=cr&ei=ZCGIU8jhFeOJ8Qenk4Fg)
    is also crossed-out in red?

    How is it? Thanks :)

    ReplyDelete

You are welcome to contribute comments, but they should be relevant to the conversation. We reserve the right to remove off-topic remarks in the interest of keeping the conversation focused and engaging. Shameless self-promotion is well, shameless, and will get canned.

Note: Only a member of this blog may post a comment.