W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [CSP] How to interpret 'self' in a sandboxed iframe

From: Mike West <mkwst@google.com>
Date: Thu, 8 Jan 2015 11:42:30 +0100
Message-ID: <CAKXHy=cPLsBrni__FShC4NqknQztiqFq3Ds3DLTj3Fr1sYzbVA@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>, Dan Veditz <dveditz@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
I think we should be using origins for security checks; the origin of a
location is an odd thing to rely upon. This means that sandboxed documents
would have to spell out the origins from which they would allow resources,
but I think that's a reasonable requirement.

WDYT, Dan?

-mike

--
Mike West <mkwst@google.com>, @mikewest

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.)

On Tue, Dec 30, 2014 at 2:23 AM, Joel Weinberger <jww@chromium.org> wrote:

> In Chrome, https://crbug.com/443444 was recently filed and points out
> that Chrome acts inconsistently with IE and Firefox when it comes to 'self'
> and resources in a sandbox. From the bug report:
>
> "The web page in the attached attached archive attempts to frame HTML
> documents that load external stylesheets.  There are four cases: the
> stylesheet comes from the same or different source, and the iframe is
> sandboxed or not.  All of the framed documents (and their stylesheets) are
> served with CSPs that allow stylesheets from 'self' and the named different
> source.  Since both stylesheet sources are permitted by the CSP, the
> stylesheet is expected to load in all cases.
>
> However, in the same-source, sandboxed case, Chrome refuses to load the
> stylesheet, citing a CSP violation.  Firefox and the most recent Internet
> Explorer builds do load the stylesheet in all cases."
>
>
> We've gotten to the root of what Chrome's doing and, as the reporter (and
> Brad Hill) suggests, Chrome is checking the the *unique origin* of the
> sandbox against 'self', rather than checking if it's the same, "scheme,
> host, and port as the protected resource’s URL" (
> https://w3c.github.io/webappsec/specs/content-security-policy/#match-source-expression).
> So this is definitely the difference in what Chrome's doing, and I even
> uploaded a CL that potentially addresses at least part of the problem (
> https://codereview.chromium.org/822483002/).
>
> However, I'm not convinced that this is actually the right answer, and at
> the very least, I want to make sure we consciously decide what user agents
> should do in this case. I see two issues here:
>
>    - It seems odd to me that 'self' is not checked against the origin, be
>    against a URL. For most security decisions, shouldn't we be using origin,
>    so that we're consistent in cases like this?
>    - As abarth@chromium.org points out in a previous CL (
>    https://codereview.chromium.org/150893004/), this non-origin
>    definition presents problems for about:blank and srcdoc resources. It
>    doesn't seem unreasonable to me to require that resources that are
>    sandboxed explicitly whitelist the resources they want to access, rather
>    than relying 'self'.
>
> What are thoughts out there in CSP land?
> --Joel
>
Received on Thursday, 8 January 2015 10:43:19 UTC

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