Bug 160960 – CSP3: Inline event handler should be blocked when set

• Status: NEW
• Component: WebCore Misc.

[April King]

OS Version: OS X 10.11
URLs (if applicable) : http://output.jsbin.com/togusapobi / http://output.jsbin.com/wutojesugi
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
       Safari: FAIL
   Firefox 48: OK
     IE 7/8/9: N/A
         Edge: OK
    Chrome 52: FAIL

What steps will reproduce the problem?
1. Set Content-Security-Policy to block 'unsafe-inline'
2. Add an event handler to an attribute via setAttribute('onclick') or via onclick attribute added to DOM node

What is the expected result?

In Firefox and Edge, this code will be successfully blocked on being set:

document.querySelector('button').setAttribute('onclick', 'alert(1)')

As will this inline event handler:

<button onclick="alert(1);">yay</button>

What happens instead of that?

WebKit-based browsers block it upon execution, in violation of the CSP specification:

>  When an event handler content attribute is set, execute the following steps:
>  
>    If the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when executed upon the attribute's element, "script attribute", and the attribute's value, then abort these steps. [CSP]

See also:
https://bugs.chromium.org/p/chromium/issues/detail?id=638957
https://bugzilla.mozilla.org/show_bug.cgi?id=1296027

[Daniel Bates]

(In reply to comment #0)
> >  When an event handler content attribute is set, execute the following steps:
> >  
> >    If the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when executed upon the attribute's element, "script attribute", and the attribute's value, then abort these steps. [CSP]
> 

This quote is from section Events handlers of the HTML5 spec. <https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers> (18 August 2016).

This wording is consistent with section Should element’s inline type behavior be blocked by Content Security Policy? of the CSP Level 3 specification (Editor's Draft, 18 August 2016). Though this section of the CSP spec. and the quote from the HTML5 spec. seem inconsistent with the wording used in (5) of section Integration with HTML of the CSP Level 3 specification:

"§4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? is called during handling of inline event handlers (like onclick) and inline style attributes in order to determine whether or not they ought to be allowed to execute/render."

The phrase "allowed to execute" could be read as CSP blocks an inline event handler when it is invoked. I suspect this wording is an oversight. Regardless, the wording in the HTML5 spec. and in CSP Level 3 represents a change of behavior from CSP Level 2. Currently WebKit conforms to the inline event handler blocking and reporting behavior as defined in section script-src of the CSP Level 2 spec.:

[[
If 'unsafe-inline' is not in the list of allowed script sources, or if at least one nonce-source or hash-source is present in the list of allowed script sources:
...
Whenever the user agent would execute an inline script from an inline event handler, instead the user agent MUST NOT execute script, and MUST report a violation.
]]
<https://w3c.github.io/webappsec-csp/2/#directive-script-src> (Editor's Draft, 25 April 2016)

[Radar WebKit Bug Importer]

<rdar://problem/27909274>

[Brent Fulgham]

In 2022, I believe Safari, Chrome, and Edge behave the same here, with Firefox being the one outlier.

Maybe we should all change, but I'm not sure?

[Brent Fulgham]

@Patrick and @Kate: Do you have any feelings on this bug?