Intent to Ship: Content Security Policy: Embedded Enforcement

[Andy Paicu]

Contact emails
andy...@chromium.org, mk...@chromium.org

Spec
https://w3c.github.io/webappsec-csp/embedded/

Summary
CSP's Embedded enforcement  defines a mechanism by which a web page can embed a nested browsing context if and only if it agrees to enforce a particular set of restrictions upon itself. In other words, an embedder can pull in a third-party widget via code like the following, to ensure that it doesn't load plugin content, or resources from unapproved origins:

   <iframe src="https://cool-widget.example.com/"

                  csp="default-src approved.cdn.com; object-src 'none'">

   </iframe>

The embedee is informed about the embedder's requirements via a new HTTP request header, and can opt-in by reflecting in the `Content-Security-Policy` header a policy that is at least as strong as the one specified or by returning an appropriate `Allow-CSP-From` header.

If neither is done, the response is blocked.

Motivation
Content Security Policy defines ways for developers to restrict their web pages to trusted content. However, there isn’t any enforcement done on embeddee’s such as third-party advertisements and widgets to abide by embedder’s policies.

Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Tentative interest

We've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables.

There has been tentative interest expressed by developers around this feature.

Compatibility risk
Low. Existing content that doesn't use the `csp` attribute won't be affected at all.

Ongoing technical constraints
None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug
https://crbug.com/647588


Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5750241810710528

Requesting approval to ship?
Yes.

[Mike West]

+Malika, who did basically all the actual work to make this happen. Hi, Malika!

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bck8mCc-HOQ was the intent to implement.

On Tue, May 23, 2017 at 2:10 PM, 'Andy Paicu' via blink-dev <blin...@chromium.org> wrote:

Contact emails
andy...@chromium.org, mk...@chromium.org

Spec
https://w3c.github.io/webappsec-csp/embedded/

Summary
CSP's Embedded enforcement  defines a mechanism by which a web page can embed a nested browsing context if and only if it agrees to enforce a particular set of restrictions upon itself. In other words, an embedder can pull in a third-party widget via code like the following, to ensure that it doesn't load plugin content, or resources from unapproved origins:

   <iframe src="https://cool-widget.example.com/"

                  csp="default-src approved.cdn.com; object-src 'none'">

   </iframe>

The embedee is informed about the embedder's requirements via a new HTTP request header, and can opt-in by reflecting in the `Content-Security-Policy` header a policy that is at least as strong as the one specified or by returning an appropriate `Allow-CSP-From` header.

If neither is done, the response is blocked.

Motivation
Content Security Policy defines ways for developers to restrict their web pages to trusted content. However, there isn’t any enforcement done on embeddee’s such as third-party advertisements and widgets to abide by embedder’s policies.

Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Tentative interest

We've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables.

We solicited feedback a number of times (https://www.w3.org/2011/webappsec/draft-minutes/2017-02-21-webappsec-minutes.html#item08, https://www.w3.org/2011/webappsec/draft-minutes/2016-12-21-webappsec-minutes.html#item03, F2F at TPAC, etc). I'd agree with Andy's characterization of folks' reactions as being generally positive, but I'd caution that I don't think other vendors have carefully reviewed the spec.

We've upstreamed our tests to https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/embedded-enforcement, and I think our coverage is reasonable.

There has been tentative interest expressed by developers around this feature.

https://twitter.com/0x6D6172696F/status/810054093620346880 and https://twitter.com/cramforce/status/780411030316863488 are completely representative and not-at-all-cherry-picked examples.

 

Compatibility risk
Low. Existing content that doesn't use the `csp` attribute won't be affected at all.

I think the design and functionality makes sense, and the light review we've gotten from other vendors seems to confirm that, but if it turns out that we've gotten this terribly wrong, we'll be able to revert it fairly easily as it's entirely an additive security mechanism. In that case, frames would simply revert to the status quo with no long-term side-effects.

-mike

[Philip Jägenstedt]

Looks like this didn't go through TAG review, and now it's too late to block on it, but have CSP things generally gone to the TAG?

There's just a tiny bit of IDL for this feature, but I took a look. As implemented, the csp attribute is simply reflected, but the spec says some more elaborate things. Which should change?

There's also a bunch of "upstream this" FIXMEs in the spec, is that underway?

P.S. I enjoyed the 💩

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdvWs2SBUSWinex6mob5LAr0r2Dr1TZycDXd%3DbsamzQpA%40mail.gmail.com.

[Mike West]

On Thu, Jun 1, 2017 at 1:44 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Looks like this didn't go through TAG review, and now it's too late to block on it, but have CSP things generally gone to the TAG?

Hrm. I thought we talked about embedded enforcement as part of https://github.com/w3ctag/design-reviews/issues/42, but looking at the notes, I think you're right that it didn't come up. :(

There's just a tiny bit of IDL for this feature, but I took a look. As implemented, the csp attribute is simply reflected, but the spec says some more elaborate things. Which should change?

It should just be reflecting. We moved the policy validation to block setting the `Sec-Required-CSP` request header, but I apparently missed cleaning up the attribute integration. The tests look correct, though, so I think it's just an oversight in the spec.

 

There's also a bunch of "upstream this" FIXMEs in the spec, is that underway?

I haven't started pushing patches upstream to HTML and Fetch. Anne has generally been reticent to land those patches when there wasn't clear implementation intent from more than one browser. *shrug* If you'd like me to queue up patches that we can rebase when other vendors hop on board more actively, I'm happy to start that process.

[Philip Jägenstedt]

On Thu, Jun 1, 2017 at 2:19 PM Mike West <mk...@chromium.org> wrote:

On Thu, Jun 1, 2017 at 1:44 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Looks like this didn't go through TAG review, and now it's too late to block on it, but have CSP things generally gone to the TAG?

Hrm. I thought we talked about embedded enforcement as part of https://github.com/w3ctag/design-reviews/issues/42, but looking at the notes, I think you're right that it didn't come up. :(

If you think it'd be useful you could file another, but as I said it couldn't block this intent. (We should fix the process if we want that to be possible.)

 

There's just a tiny bit of IDL for this feature, but I took a look. As implemented, the csp attribute is simply reflected, but the spec says some more elaborate things. Which should change?

It should just be reflecting. We moved the policy validation to block setting the `Sec-Required-CSP` request header, but I apparently missed cleaning up the attribute integration. The tests look correct, though, so I think it's just an oversight in the spec.

Fixed in https://github.com/w3c/webappsec-csp/commit/3ac127abb700a5d36ff69b4e4afe7b68c91afd9d, thanks!

 

There's also a bunch of "upstream this" FIXMEs in the spec, is that underway?

I haven't started pushing patches upstream to HTML and Fetch. Anne has generally been reticent to land those patches when there wasn't clear implementation intent from more than one browser. *shrug* If you'd like me to queue up patches that we can rebase when other vendors hop on board more actively, I'm happy to start that process.

I see, we do seek 2+ interested implementers for changes in HTML. If it's just extension points (hooks) you need then I think that should be OK, but putting the normative bits in HTML should probably wait then.

Anyway, what to do depends on how unhappy you are with the integration, and how likely it is that preparing the patches would reveal new and consequential issues. You decide :)

LGTM1

[Rick Byers]

LGTM2

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfjCeAW7%2BcXYvC3ScdHCPgr%3DyiN4HVx0Lg0gWFrL%2BR8cw%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_0am%3DbnC3fmMYyfNV5UvFWO9%2BA1hN%3DwzwbtK%2Bjmn%3Dk8Q%40mail.gmail.com.