W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: "Mixed Content" draft up for review.

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 2 Jun 2014 14:55:01 +0200
Message-ID: <CADnb78irDvcY6u5wuAGMXBbvE2o-y0Af=xiy756_SyU6TTTeuA@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <bhill@paypal.com>, Dan Veditz <dveditz@mozilla.com>, Ryan Sleevi <rsleevi@chromium.org>, palmer@chromium.org
On Mon, Jun 2, 2014 at 2:35 PM, Mike West <mkwst@google.com> wrote:
> On Mon, Jun 2, 2014 at 12:32 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> You want to talk about something broader than document in the
>> introduction and maybe elsewhere. In particular service workers can
>> run without an associated document. If a service workers runs over TLS
>> (and there might be no alternative) it should not be able to get to
>> non-TLS resources.
>
> That makes sense. Does "execution context" capture "Document or Global
> Scope"? Or is there some term that's more applicable?

HTML uses "JavaScript global environment" and then has "document
environment", "dedicated worker environment", "shared worker
environment", and "worker environment" (former two combined) as
classifications.


>> Under "assumed secure origin" you should probably remove blob URLs.
>> They will get an origin and it will be the origin of the method that
>> created them. So they are not always secure, as they could be created
>> by an origin' whose scheme is http.
>
> Hrm. A blob constructed from an HTTP resource wouldn't touch the network
> when loading; it would be just as secure as the rest of the page. As long as
> restrictions are in place that lock blobs to their own origins, they can be
> safely considered just as secure as 'data:', etc.

Right, so if the environment is non-TLS, the blob is not secure.


>> Also, Chrome does not seem to
>> consider origins that are a globally unique identifier secure per
>>
>> https://sites.google.com/a/chromium.org/dev/Home/chromium-security/security-faq
>> so maybe that should be removed entirely?
>
> Chrome certain allows HTTPS pages to load 'data:' URLs at the moment. I
> think there's been some discussion around whether or not we need to do some
> sort of taint checking before doing so (similar to Canvas). I'm hoping to
> avoid that entirely by simply blocking the mechanisms currently available
> for grabbing insecure data (XHR, EventSource, WebSockets, etc).

I see what you mean. But that means blob/data inherit the security.
They are not secure by themselves. E.g. if I navigate to a data URL,
that does not mean the environment it creates is secure.


>> ISSUE 2: It seems like only <form method=POST> to an insecure origin
>> is actively harmful. GET would be the same as following a link.
>
> I disagree. Links don't have a mechanism for soliciting information from the
> user that the page doesn't already know, nor do they generally (assuming
> sanity...) contain capability-bearing nonces.

http://www.w3.org/TR/capability-urls/ (very bad without TLS though)


> Those are the problem, not the
> method used to transmit the data. If it's compatible with the web at large
> to treat HTTP-targeting forms as mixed content, we should do it for all form
> submissions, regardless of action.

Fair enough I guess.


>> "Is document a secure browsing context?" This algorithm does not seem
>> to work how you want it to work. It seems first you want to get the
>> list of inclusive ancestors of a given document's associated browsing
>> context and then verify that for all of them the associated document
>> is TLS-protected. And only at that point do you want to return true.
>
> Checking the top-level resource is currently all that Chrome does. Hopefully
> Tanvi can weigh in on Mozilla's implementation.
>
> That said, I don't think we need to traverse the entire chain if each
> resource load checks its parent. The child frames should then be
> transitively secure.

True, and the same goes for only checking top. However, the current
algorithm does not do that. It returns as soon it verifies the current
document.


>> ISSUE 5: We should coordinate with implementers whether this Fetch
>> hook should happen before HSTS or after HSTS. It seems there was some
>> misalignment around that. Also, it seems that if service workers are
>> TLS-only, the second note in this section only partially applies.
>
> I believe that both Chrome and Firefox currently implement the opposite of
> what's specced here (e.g. mixed content happens, then HSTS happens). I think
> that the relevant folks consider that a bug, but I'd invite Ryan and Chris
> to weigh in (Hi Ryan and Chris, who I just added to CC!). If I've
> misinterpreted things, I'm happy to change that piece.

Okay, in http://fetch.spec.whatwg.org/#concept-fetch the placeholder
hook is after HSTS.


>> Also, for Fetch integration I would prefer if your hooks simply took a
>> request and a response (if necessary and available).
>
> Yup, that makes a lot of sense.
> https://github.com/w3c/webappsec/commit/21ecb452df370ed37ad1de8d8ed69c499b8ae525
>
> WDYT?

Looks good.


-- 
http://annevankesteren.nl/
Received on Monday, 2 June 2014 12:55:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC