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

Also, as Dev points out in the bug, for the iframe sandbox case, sites
don't know that they're going to be sandboxed, so they won't prepare for
that contingency. Put differently, if we get to a world where every site
has a nice CSP, they might all reasonably use 'self', and that will make
iframe sandbox unusable, which would make me sad.
--Joel

On Thu Jan 08 2015 at 9:19:05 AM Brad Hill <hillbrad@gmail.com> wrote:

> I don't think it's an unreasonable requirement, but I do think it may be
> an adoption barrier.  I think we'd like to encourage the use of sandboxing
> by keeping as much as we can the situation that dropping origin privileges
> is easy to do without breaking unexpected things.  If you have to rework
> all of your other CSP policies, that is unfortunate for both sandboxing and
> CSP.
> On Thu Jan 08 2015 at 2:44:43 AM Mike West <mkwst@google.com> wrote:
>
>> 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/
>>>    <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
>>>
>>
>>