[MIX] HTTPS -> non-HTTPS redirects

Hi,

In another thread [1], I suggested that all mixed content in iframes
should be blocked by default, and after receiving some encouragement,
I offered to propose some text for that. As a refresher, the goal is
to give some assurance to a page that, even when it frames third-party
content, there's no way that framed third-party content can cause the
mixed content indicator for the framing page to "go bad."

This got me thinking about other ways that a page that tries to do the
right thing could get burned in a similar manner. In particular,
consider redirects:

     <img src='https://ads.example.com/CREAM.jpg'>

Looks good, right? But, what if https://ads.example.com/CREAM.jpg
redirects to http://ads.example.com/CREAM.jpg? Then the browser's
mixed content indicator will go bad, just like the iframe case, even
though the page is trying to do the right thing. That's not good. This
makes me think that HTTPS -> non-HTTPS redirects for
otherwise-optionally-blockable fetches should be blocked.

In particular, the change would be to add the equivalent of a fourth
sub-step to step 7 of [2] along the lines of 'If the redirect count is
not zero and the previous request URL had an origin of "https", return
blocked.'

In particular, the following kinds of redirects for
optionally-blockable requests would be blocked:

HTTPS -> HTTP
HTTP -> HTTPS -> HTTP

If people object to blocking the second kind of redirect, then the
restriction could be modified in a simple way, e.g. "If the redirect
count is 1..."

I anticipate that people would want to completely rewrite my proposed
text to fit better with how fetch is specified. I encourage people to
do so.

To emphasize, my suggestion here only applies to the things classified
as optionally-blockable: <img> (without crossorigin), <video>,
<audio>, and prefetch content.

WDYT?

Cheers,
Brian

[1] http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0202.html
[2] https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch

Received on Tuesday, 25 November 2014 01:29:06 UTC