1926025 - Inline event handler execution CSP violation logged during parsing, not when executing that handler

Status: UNCONFIRMED

(Core :: DOM: Security, defect, P3)

Description

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Attachment: x.html

STR:

0. Download the attached example.
1. Start a local web server, e.g. via python3 -m http.server.
2. Open the example with a hash, e.g.: http://0.0.0.0:8000/x.html#alert(1).
3. Open the developer console to observe the logged errors.

Actual: Firefox's (current release) logs:

Uncaught EvalError: call to eval() blocked by CSP
    <anonymous> http://0.0.0.0:8000/x.html#alert(1):5
x.html:5:1
Content-Security-Policy: The page’s settings blocked a JavaScript eval (script-src) from being executed because it violates the following directive: “script-src 'nonce-x'” (Missing 'unsafe-eval') x.html:5:1
Content-Security-Policy: The page’s settings blocked an event handler (script-src-attr) from being executed because it violates the following directive: “script-src 'nonce-x'”
Source: location.href = malicious

Expected: no CSP violation for the event handler. That's also Chrome's behavior.

Credits to https://github.com/w3c/webappsec-csp/issues/322#issuecomment-811135901 for inspiring the example.

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:freddy, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Frederik Braun [:freddy]]

I believe the test case is confusing and doing three things at the same time.

• The nonced script is fine as inline-script because of the nonce
• The content of the nonced script ends up calling eval() which is not fine because the CSP lacks unsafe-eval.
• The onclick event handler violates script-src (which is the fallback directive if no script-src-attr or script-src-elem are present).

Why do you believe that the inline script in onclick=... should be allowed?

Comment 3

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Attachment: x.html

Comment 4

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

(In reply to Frederik Braun [:freddy] from comment #2)

I believe the test case is confusing and doing three things at the same time.

• The nonced script is fine as inline-script because of the nonce
• The content of the nonced script ends up calling eval() which is not fine because the CSP lacks unsafe-eval.

Removed the call of eval to simplify the test.

• The onclick event handler violates script-src (which is the fallback directive if no script-src-attr or script-src-elem are present).

Why do you believe that the inline script in onclick=... should be allowed?

It should be forbidden.

It's only confusing that Firefox emits a CSP violation when loading the document and Chrome emits a CSP violation only when clicking, not before.

Comment 5

[Frederik Braun [:freddy]]

Thanks for the clarification. It appears that we report about the presence of event handlers rather than their execution? Interesting.

Comment 6

[Simon Friedberger [:simonf]]

I couldn't find anything in the spec that says reporting should happen on execution. Is there an actual security issue here that I am missing or is this just behavior that is not aligned with Chrome?

Comment 7

[Tom Schuster (Away until Aug 31)]

(In reply to Frederik Braun [:freddy] from comment #5)

Thanks for the clarification. It appears that we report about the presence of event handlers rather than their execution? Interesting.

That seems definitely preferable to me, because it makes it much easier to replace those non working event handlers.

Comment 8

[Daniel Veditz [:dveditz]]

Our event handler behavior is consistent with how <script> elements are handled, which is at JS parse time. It's possible Chrome is doing that, too, but maybe they store event handlers as strings and don't JS-parse them until they are needed? Dunno.

We handle it much like style= attributes, which says if inline is blocked by CSP "then the style rules defined in the attribute's value must not be applied to the element." https://html.spec.whatwg.org/#the-style-attribute

For event handlers the specs look like they conflict a little. The steps for setting an event handler attribute in HTML say to do what we do: https://html.spec.whatwg.org/#event-handler-content-attributes

The following attribute change steps are used to synchronize between event handler content attributes and event handlers: [DOM]
...
5. Otherwise:
1. If the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when executed upon element, "script attribute", and value, then return. [CSP]
...
NOTE: Per the DOM Standard, these steps are run even if oldValue and value are identical (setting an attribute to its current value), but not if oldValue and value are both null (removing an attribute that doesn't currently exist). [DOM]

So it seems clearly aimed at the time when the attribute is set (parsed).

The CSP spec seems to say something different https://w3c.github.io/webappsec-csp/#html-integration

6. § 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.

What does "during handling of" mean? Handling setting the attribute (as in the HTML spec) or handling the event when it happens? Personally I favor the careful steps of the HTML spec over the CSP spec's bullet point descriptions here.