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

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
>