Re: [MIX] Require HTTPS scripts to be able to anything HTTP scripts can do.

On 01/05/2015 07:39 AM, Boris Zbarsky wrote:

> Resolving this problem is a must if we want to consider allowing XHR to
> http:// URLs from https:// contexts.  It may be viable to have a way to
> opt in to such XHRs explicitly on a per-load basis, with it being
> somehow clear that the page is expected to not trigger any script
> execution based on the returned data...

this sounds buggy and prone to breakage.  Saying "this data is tainted
and should never affect scripts" seems unclear: what if a script has a
branching condition for data display which is always "true" with normal
data, but malicious data could change to "false" -- does this count as
"triggering script execution"?

And even if there were a way to prevent script execution, it still
wouldn't prevent the network attacker from making the application lie to
the user.  You're using the wifi from a cafe to look for nearby
drugstores with a mapping webapp secured by https.  Should the cafe
operator be able to filter the responses so that their business
partner's drugstore is the only one that shows up for you, even though
others might be preferable in some way?

Also, this proposal doesn't protect the confidentiality of what data is
being fetched from anyone sniffing the network.

Say i'm visiting the secure mapping site to look up data about where the
nearest abortion clinic is?  or gun store?  or mosque?  Should the
response data leak to anyone observing the network even though my
browser indicates to me that the site is secured?  I don't think so.

The larger concern here is that the current arrangement provides
pressure on the apps to move from https to http, to be able to access a
wider range of data sources.

But the current arrangement also puts pressure on the data stores to
enable https access for confidentiality and integrity.  This is important.

The proposal of allowing access to http data from https sites would
relieve pressure on the data stores to provide https access.  We
shouldn't do that.

I admit, it's a tricky spot: an https-secured webapp does actually have
fewer sources of data that it can fetch than an insecure webapp.  But
the tradeoff is that the user of the https webapp actually knows that
they're getting the data they're intended to get, and that no one other
than the server operators can easily know what they've asked for.

If we allow access to http data from https web applications, there will
be no way to make these guarantees to the user, which would make the web
much weaker as a whole.

 --dkg