PSA: Tightening Blink's mixed content behavior.

[Mike West]

+security-dev, BCCing blink-dev, FYI.

A few CLs have landed in the recent past that are meant to tighten up Blink's mixed content handling. These behavioral changes will be noticeable to developers, so a here's a quick overview of what's changed so far:

1. XMLHttpRequest, WebSockets, and EventSource are now blocked by default in a mixed context, just like scripts. WebSocket's behavior changed in time for Chrome 37, XMLHttpRequest and EventSource are currently targeting Chrome 38.
   
   Each of these APIs exposes users to the risk that data could be intercepted and modified in transit, and this change brings Blink's behavior into line with Firefox and Internet Explorer, which were already protecting users from these threats.
   
   
2. TextTrack, Web Fonts, Beacon, CSP violation reports, and <a ping> requests are now also blocked by default in a mixed context. These are all passive content, but their usage is such that blocking mixed requests is low risk.
   
   
3. In an ideal world, we wouldn't allow any mixed content: to that end, I've added UseCounters to the remaining types of passive content (images, audio, video, PPAPI requests); if we're successful in driving down usage of those types of mixed content as well, we'll change their default behavior as well.
   
   
4. Forms with mixed action attributes are now treated as passive mixed content, and break the SSL indicator in the omnibox. Ideally, we'd never submit forms to insecure origins, but that's not a change we can make without actually breaking today's web.
   
   
5. We now consistently check both the current context and the top-level context when determine whether we need to worry about mixed content. It was possible to bypass mixed content checking in a few edge cases; now it shouldn't be.

I also intend to clean up the console messages that the mixed content checker to improve clarity, but that's going to take a bit of refactoring work in order to teach the checker what it's looking at.

http://crbug.com/388650 is the bug to follow to keep up with these changes, and you're also cordially invited to participate in the dicsussion around a proposed mixed content spec[1] on the WebAppSec WG's mailing list[2].

[1]: https://w3c.github.io/webappsec/specs/mixedcontent/

[2]: http://lists.w3.org/Archives/Public/public-webappsec/

Thanks!

-mike

[Chris Palmer]

Thanks Mike!

Bit of a tangent: Are Web Fonts truly passive content? Some font
formats, at least, are Turing-complete programming languages, and some
of them can have side-effects on the system. Or so I have heard. But I
know nothing of Web Fonts in particular.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.

[Mike West]

1. I'd like to de-emphasize the focus on active vs passive content. We
should block mixed content when we can, period.

2. I don't think webfonts have any particularly active characteristics
that have side effects on anything other than rendering. Fonts can
certainly be used for all sorts of crazy attacks, but always paired
with script or style, not on their own (that I know of).

-mike
--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Tarquin Wilton-Jones]

> 1. I'd like to de-emphasize the focus on active vs passive content. We
> should block mixed content when we can, period.

This is certainly my opinion as well. At the very least, insecure
content means insecure cookies. At the worst, "passive" content can be
more effective than phishing because it appears to come from a trusted
source.

> 2. I don't think webfonts have any particularly active characteristics
> that have side effects on anything other than rendering. Fonts can
> certainly be used for all sorts of crazy attacks, but always paired
> with script or style, not on their own (that I know of).

Web fonts and images both lend themselves to a similar attack; that
misleading text can be placed on any page where they are used. It would
take some work with a web font, but it's easiest if it's used in a
heading, for example. If you allow me to control what gets written onto
a page, I can write anything, causing the user to think that another
site can be trusted.

Imagine that your secure page has an insecure image on it. I can change
that image to be an image of the following text:
"If you want to log in faster, head over to our partner site evil.com
and log in with your realsite.com password."
I can do the same with a webfont. If a secure page uses it to write
"RealSite" in a heading, I can replace each of those characters with a
rendering of my attack text, so the rendering looks like the complete
attack sentence.

(There are also less severe textual attacks aimed at destroying a
company's reputation, like "We would like to announce that this company
is declaring bankruptcy".)

I have never been comfortable with treating these as not-so-serious.

/Tarquin

--
Tarquin Wilton-Jones
Security Group
Opera Software ASA

[Michal Zalewski]

> > 2. I don't think webfonts have any particularly active characteristics
> > that have side effects on anything other than rendering. Fonts can
> > certainly be used for all sorts of crazy attacks, but always paired
> > with script or style, not on their own (that I know of).
>
> Web fonts and images both lend themselves to a similar attack; that
> misleading text can be placed on any page where they are used.

Personally, I think that fonts are considerably worse than images.
Most images are constrained to specific drawing areas and are not used
to implement security-critical bits of application UIs (although, of
course, there are exceptions to this).

A mixed content font, on the other hand, could be likely used to
essentially rewrite the entire content of the page to give it a
malicious meaning that is opposite or tangential to what the author
intended; it feels closer to the dangers of mixed-content CSS than to
the risks of mixed content JPEGs.

Now, in the long haul, differentiating between various types of mixed
content probably isn't desirable, but in the short haul, an
impact-based approach seems like a good option.

/mz

[Mike West]

I think we're violently agreeing. Mixed fonts are bad, and they're
being blocked in ToT (as noted in #2 of the original email). :)

-mike

--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)