W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: CSP: Embedded Enforcement

From: Mike West <mkwst@google.com>
Date: Mon, 12 Sep 2016 08:25:27 +0200
Message-ID: <CAKXHy=fV_uGATiEhUDa9U4=NKn_sqrC2YzZ=r=Bkga_e+-bpag@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Fri, Sep 9, 2016 at 11:39 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> If I'm reading the spec correctly (ยง3.3) this does not recurse into nested
> iframes.


> I haven't been able to decide whether recursing leads to terrible things
> or if it's necessary to preserve protection, especially in the same-origin
> case.

For same-origin, I think it would probably be safe to simply cascade CSP
without any warning; since the top-level can already reach into the child,
no harm done. That's what the current document is doing (in step 3 of

For cross-origin, it might be necessary to recurse enforcement. I'm hoping
to get some experience with the version in the spec to see how big a deal
it actually is for folks who are interested in deploying the feature. That
is, if folks are generally going to use `child-src 'none'`, then recursion
isn't terribly interesting.

I think recursing is arguably OK because middle frames could have applied
> the same restrictions on their own and in theory know this will be applied
> because of the Embedding-CSP header they got (and agreed to by reflecting).

I don't think recursion is dangerous, since it's still opt-in on the part
of the nested-nestee. It complicates the model a bit, but not significantly.

That does complicate the requirement that there be only one Embedding-CSP
> policy, because a middle frame could apply their own csp attribute to an
> embedded iframe. If both aren't passed along then we can run into potential
> attacks depending on which one gets suppressed.

Yeah. If we want this kind of recursion then we need to a) track a set of
required CSPs for each frame (Chrome's OOPIF folks will love me), and b)
send a comma-separated list in the request header.

I'd kinda like to avoid the complexity if we don't need it, but I agree
that if we want the required policy to have teeth, then we need to either
recurse the requirement, or block nesting.

Received on Monday, 12 September 2016 06:27:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC