Bug 160960 - CSP3: Inline event handler should be blocked when set
Summary: CSP3: Inline event handler should be blocked when set
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: Safari 9
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-08-18 09:25 PDT by April King
Modified: 2016-08-18 11:37 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description April King 2016-08-18 09:25:05 PDT
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
Comment 1 Daniel Bates 2016-08-18 11:31:59 PDT
(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)
Comment 2 Radar WebKit Bug Importer 2016-08-18 11:34:54 PDT
<rdar://problem/27909274>