Intent to Implement and Ship: CSP3: `script-src-attr`, `script-src-elem`, `style-src-attr`, `style-src-elem` directives

[Andy Paicu]

Contact emails

andy...@chromium.org

Explainer

https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing (the "Directives specific for script and style attributes and elements (option 2)" section in particular).

Spec

https://w3c.github.io/webappsec-csp/#directive-script-src-attr https://w3c.github.io/webappsec-csp/#directive-script-src-elem https://w3c.github.io/webappsec-csp/#directive-style-src-attr https://w3c.github.io/webappsec-csp/#directive-style-src-elem

I did not submit a TAG review as the new directives are versions of the existing `script-src` and `style-src` directives that can be applied specifically to elements/attributes.

Summary

The `script-src-attr`, `script-src-elem`, `style-src-attr`, `style-src-elem` directives provide the same capabilities as `script-src` and `style-src` but only applied to inline event handlers, <script> elements (inline or not), style attributes or stylesheets respectively.

This means that you can allow - for example - all "style" attributes but have a more strict policy for linked stylesheets or inline <style> blocks:

Example code:

With the following policy header:

Content-Security-Policy: style-src-attr 'unsafe-inline'; style-src-elem 'nonce-abc'

These would work:

<p style="background: green">  # style-src-attr 'unsafe-inline' is checked

<style nonce="abc">    

  p { background: green; }  # style-src-elem 'nonce-abc' is checked

</style>

<link nonce="abc" rel="stylesheet" type="text/css" href="mystyle.css">  

# style-src-elem 'nonce-abc' is checked

And these would not work:

<style>    

  p { background: green; }  # style-src-elem 'nonce-abc' is checked

</style>

<link rel="stylesheet" type="text/css" href="mystyle.css">  # style-src-elem 'nonce-abc' is checked

Motivation

There are multiple scenarios that motivate the new directives:

1. This allows website authors to enable only `unsafe-inline` attributes but not elements or the reverse. This is particularly relevant for styles because `style` attributes don't have the same capabilities as stylesheets or `style` blocks (because they apply to the element and don't have selectors). This can be used to prevent all sorts of CSS-based attacks without a blanket disable of all inline behaviour (example CSS attack: https://jakearchibald.com/2018/third-party-css-is-not-safe/).
2. The current behaviour of CSP disables any sort of inline attributes/event handlers as soon as a nonce or hash is present in the policy. This means that often a lot of refactoring work is needed to adopt CSP in a meaningful manner. Often 'unsafe-inline' is just used instead which provides little protection in the first place. The split directives provides an alternative and should help drive the 'unsafe-inline' usage down (paper around statistics of CSP keyword usage: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf)
3. Using 'unsafe-hashes' (https://w3c.github.io/webappsec-csp/#unsafe-hashes-usage) sometimes makes more sense if applied only to attributes, for example in a nonce-based policy that also needs to somehow whitelist event handlers (which can't use nonces). This is also a practical scenario that the SEAM Google team hit and would use this for.

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

Yes

Risks

Interoperability and Compatibility

The new feature should be easy to integrate as the CSP fallback mechanism allows developers to write policies that take advantage of this feature while also functioning (but obviously providing less security) in user-agents that implement older versions of CSP.

Edge/Firefox/Safari/Opera: Lukewarm The explainer above has been discussed at TPAC as well as during WebAppSec meetings and it was considered a useful feature.

https://www.w3.org/2018/04/18-webappsec-minutes.html

https://www.w3.org/2018/05/16-webappsec-minutes.html

Web developers: positive

The SEAM Google team has plans for using this feature for a static page automatic CSP system.

Also interest has been expressed for a method of only enabling "style" attributes to prevent CSS based attacks (as the one linked above).

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

Probably together with the rest of CSP.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

Should not have any significant impact on the Chrome performance.

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

No

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

It seems wpt.fyi has not caught up yet but here are some hand-crafted links:

https://wpt.fyi/results/content-security-policy/script-src-attr-elem?complete=true

https://wpt.fyi/results/content-security-policy/style-src-attr-elem?complete=true

The tests have been added recently to the WPT repository:

https://github.com/web-platform-tests/wpt/tree/master/content-security-policy/script-src-attr-elem

https://github.com/web-platform-tests/wpt/tree/master/content-security-policy/style-src-attr-elem

Entry on the feature dashboard

https://www.chromestatus.com/feature/5141352765456384

--

Regards,

Andy Paicu

[Joe Medley]

Andy,

Do you have a tracking bug I can star? Chrome Status needs it too.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYiYpJUKtbDWxCmw7z-FJiiPgoUMsouFT6Z_kXKCW00O6g%40mail.gmail.com.

[Andy Paicu]

Hi Joe,

Yes I do, I forgot to link it to the chrome status feature

http://crbug.com/880816

--

Regards,

Andy Paicu

[Joe Medley]

Thanks! 

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Philip Jägenstedt]

Hi Andy,

You said "lukewarm" for other engines. Can you summarize the concerns from the meetings at TPAC?

Great to see WPT for this!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG8wa2wZ0ab23qk1NW7Bum9E%2BYjSSZpZ5cJ%3D%2B%3Dccrdqf8w%40mail.gmail.com.

[Mike West]

LGTM1.

To Philip's question:

I don't think other vendors are very excited about adding more functionality to CSP, but I think there's some recognition that the problem this proposal addresses is real. Folks at TPAC last year seemed reluctantly to agree that additional directives in the style Andy's proposed were a better solution for backwards compatibility than additional keywords or differently-spelled hashes (see https://www.w3.org/2017/11/06-webappsec-minutes.html#item08), and we have very clear indications from developers on Google's security team that this general split will allow them to apply strong policies to pages they otherwise would not be able to protect.

There's additional indication from developers (from Mozilla and elsewhere) in https://github.com/w3c/webappsec-csp/issues/45 that the distinction between style blocks and inline style is a meaningful one which blocks some developers from constructing strong policies.

I think we're rapidly hitting diminishing returns on further investment in CSP, but this does seem like an addition worth supporting. I think we should ship it.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYd34ORb9n-rEZKWbXA1tsTRXhjv0qPKz%2BQW8Mak0FYXxw%40mail.gmail.com.

[Philip Jägenstedt]

Thanks Mike. Due to those diminishing returns, I take it we won't we be extending CSP by much more, so that there isn't going to be a continuous trickle of CSP directives? If we're approaching 90+% of the final size of CSP already, a design that made it into the spec and no explicit "no thanks" from any vendor, then the interop risk doesn't seem too serious, and being able to construct tighter policies seems like a win. LGTM2.

[Mike West]

On Wed, Sep 12, 2018 at 10:47 AM Philip Jägenstedt <foo...@chromium.org> wrote:

Thanks Mike. Due to those diminishing returns, I take it we won't we be extending CSP by much more, so that there isn't going to be a continuous trickle of CSP directives? If we're approaching 90+% of the final size of CSP already, a design that made it into the spec and no explicit "no thanks" from any vendor, then the interop risk doesn't seem too serious, and being able to construct tighter policies seems like a win.

I know there are some ongoing conversations around WebRTC and WebASM that might result in additional directives. Still, I very much want to close the door on CSP3, call it done, and move on. I don't anticipate much new landing in CSP once the currently open conversations close out, one way or the other.

[Philip Jägenstedt]

On Wed, Sep 12, 2018 at 12:05 PM Mike West <mk...@chromium.org> wrote:

On Wed, Sep 12, 2018 at 10:47 AM Philip Jägenstedt <foo...@chromium.org> wrote:

Thanks Mike. Due to those diminishing returns, I take it we won't we be extending CSP by much more, so that there isn't going to be a continuous trickle of CSP directives? If we're approaching 90+% of the final size of CSP already, a design that made it into the spec and no explicit "no thanks" from any vendor, then the interop risk doesn't seem too serious, and being able to construct tighter policies seems like a win.

I know there are some ongoing conversations around WebRTC and WebASM that might result in additional directives. Still, I very much want to close the door on CSP3, call it done, and move on. I don't anticipate much new landing in CSP once the currently open conversations close out, one way or the other.

Thanks Mike, that definitely sounds like "almost there" and so not really a risk of having this come up over and over again. 

[Daniel Bratell]

LGTM3

/Daniel

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdW3W%2B_hrxFGj3wAn-LjJojSAbvyrqaCtkYFreEoksMoA%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[vl...@stiganmedia.com]

Does script-src-elem not Fallback to default-src ???

Current behaviour is "Refused to load the script because it violates the following Content Security Policy directive: "script-src-elem ..."

Thank you

[Andy Paicu]

`script-src-elem` falls back on `script-src` which in turn falls back on `default-src`: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/csp/csp_directive_list.cc?q=script-src-elem+fallback+file:%5Esrc/+package:%5Echromium$&g=0&l=1380

Please note that in reports the effective directive is reported which according to spec is the most specific directive for the check that is being done (https://www.w3.org/TR/CSP3/#effective-directive-for-a-request, https://www.w3.org/TR/CSP3/#effective-directive-for-inline-check).

I suspect your `default-src` or your `script-src` directive is blocking the script you're trying to run (assuming you don't have a `script-src-elem` since you're asking about fallback).

Feel free to send me an email with more details on what you're doing so we can figure out what is going wrong.

Regards,

Andy Paicu

Software Engineer

andy...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/595f3033-ab95-412e-a2ec-674c3cea1ec8%40chromium.org.

[suni...@nseit.com]

Hi Andy,

Even I am getting the same issue only with chrome browser.

Refused to load the script 'http://localhost/xyz/xyz.js' because it violates the following Content Security Policy directive: "script-src 'unsafe-inline' 'unsafe-eval' 'self'". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

Here I am using two server one XAMPP server(xyz application) and another Wildfly 10. My application is launched on Wildfly .

I have added <meta> tag for Content Security policy in Header section.

Please let me know what else details are needed.

Thanks,

Sunitha

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.