Re: CSP: Embedded Enforcement

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

Correct.


> 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
https://www.w3.org/TR/csp-embedded-enforcement/#process-response).

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.

-mike