Intern to Implement Content Security Policy: Embedded Enforcement

[Malika Aubakirova]

Contact emails
ama...@google.com, 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 the required policy as a `Content-Security-Policy` response header.

If it doesn't explicitly opt-in, then the response will be 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: No signals

We've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables, but there hasn't been any real progress over the last few months. The goal here is to prototype the functionality so that developers can play around with it to see if it meets their needs, and browser vendors can evaluate whether or not it addresses the intended problem space in a reasonable way.

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

[Mike West]

On Mon, Sep 26, 2016 at 1:25 PM, 'Malika Aubakirova' via blink-dev <blin...@chromium.org> wrote:

We've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables, but there hasn't been any real progress over the last few months. The goal here is to prototype the functionality so that developers can play around with it to see if it meets their needs, and browser vendors can evaluate whether or not it addresses the intended problem space in a reasonable way.

Based on conversations at TPAC, there's high-level interest from developers at places like Facebook in using a mechanism like this one to confine their cross-origin embedees. Other browser vendors still seem to be taking a wait-and-see approach, but I'd cautiously categorize their stance as interest. Other than some questions from Anne about adding yet another request header, complicating the CORS story (https://github.com/w3c/webappsec-csp/issues/115), no objections have been raised in the group.

CCing Ilya and Ojan, as there's also some reasonable overlap with things like the {Feature,Size,Whatever,...} Policy proposals, especially in terms of opt-in strategy. As we proceed with the design, we should make sure it fits into the rest of the policy language we're spelling out.

-mike

[Ojan Vafai]

+Raymes Khoury and +Ian Clelland 

This description and title are a bit confusing. This is just adding the "csp" attribute on iframe and the new request header, right?

Which requests get the new request header? Just the main resource for the frame?

[Mike West]

On Monday, 26 September 2016, Ojan Vafai <oj...@chromium.org> wrote:

+Raymes Khoury and +Ian Clelland 

This description and title are a bit confusing.

 

Sorry for the confusion. What can we clarify?

This is just adding the "csp" attribute on iframe and the new request header, right?

And the blocking behavior for the resource of it doesn't explicitly or implicitly opt-in to the policy provided by the embedder.

 

Which requests get the new request header? Just the main resource for the frame?

Yup. The integration in step 6 of https://w3c.github.io/webappsec-csp/embedded/#html-integration isn't spelled out in enough detail, but the goal is to limit the new request header (and blocking behavior) to the request for the embedded document itself.

We might end up cascading the value down into child frames (still with the opt-in), but it would still just be the main resource request.

On Mon, Sep 26, 2016 at 3:41 PM Mike West <mk...@chromium.org> wrote:

On Mon, Sep 26, 2016 at 1:25 PM, 'Malika Aubakirova' via blink-dev <blin...@chromium.org> wrote:

We've talked about this feature a little bit in the WebAppSec working group, and folks are generally positive about the behavior it enables, but there hasn't been any real progress over the last few months. The goal here is to prototype the functionality so that developers can play around with it to see if it meets their needs, and browser vendors can evaluate whether or not it addresses the intended problem space in a reasonable way.

Based on conversations at TPAC, there's high-level interest from developers at places like Facebook in using a mechanism like this one to confine their cross-origin embedees. Other browser vendors still seem to be taking a wait-and-see approach, but I'd cautiously categorize their stance as interest. Other than some questions from Anne about adding yet another request header, complicating the CORS story (https://github.com/w3c/webappsec-csp/issues/115), no objections have been raised in the group.

CCing Ilya and Ojan, as there's also some reasonable overlap with things like the {Feature,Size,Whatever,...} Policy proposals, especially in terms of opt-in strategy. As we proceed with the design, we should make sure it fits into the rest of the policy language we're spelling out.

-mike

--
-mike

[PhistucK]

A side note - next time, try to make sure you do not remove the colon from the subject (Intent to implement: .... instead of Intent to implement ...), because automated tools are collecting those intents for tracking.

I remember reading about an intent (in the non-blink-dev sense :)) to change the syntax of Content Security Policy to use JSON. That means there will have to be quotes within the value of the attribute, which add up a lot of bytes to the HTML (I realize that <meta http-equiv="Content-Security-Policy" value="..." /> shares the same issue) and is generally an uncommon way of embedding JSON in HTML.

I am not really sure what I am asking here, to be frank. :) But is there a plan to handle things differently given that evolution?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.