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

On 12/29/14 5:23 PM, Joel Weinberger wrote:
>   * 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 <mailto: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'.

So much of me wants the consistency of using origin everywhere, but it's
getting us the wrong result in the sandbox case. I think that's because
the sandboxed content had a perfectly good origin to start with and then
an external party went and forced it to have a different (unique) origin
altogether. That unique origin may be good for the containing site's
security but not necessarily the security of the (possibly 3rd party)
sandboxed content if doing so breaks its CSP.

For sandboxed frames we need self to be something like the "fallback
Base URL"
http://www.w3.org/TR/html5/infrastructure.html#fallback-base-url

We have a similar confusion with frame-ancestors and sandboxed frames.
If your content is put into a sandbox with a unique origin does that
mean that all sub-documents that use a CSP with frame-ancestors will be
blocked because no one can match a unique origin? From one very narrow
view you could say that the parent content was sandboxed because it
wasn't fully trusted and therefore if frame-ancestors is a list of
trusted framers then blocking is the right result. But mostly we'll get
very sad broken pages and ultimately less use of frame-ancestors and/or
sandboxed frames. Keep in mind that content can be sandboxed against its
will if that helps an attacker.

-Dan Veditz

Received on Monday, 12 January 2015 07:51:05 UTC