Inline event handlers not whitelisted by hashes? #13

mikewest · 2015-10-07T06:50:59Z

From @kravietz on September 8, 2015 15:54

Reading through section 7.15 of the latest CSP2 editor's draft it seems like you can't whitelist an inline event handler with its SHA256 hash. Is this intended exclusion?

Just to provide a bit of background, the following script will only result in one pop-up, from the whitelisted alert in the <script> tag:

<!DOCUMENT html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="default-src none; script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='; img-src data:">
</head>
<body>
<img src="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'/>"
onload="alert('Hello, world.');">
<script>alert('Hello, world.');</script>
</body>
</html>

The inline handler alert will not be shown and Chrome will display the following error message:

Refused to execute inline event handler because it violates the following Content Security Policy 
directive: "script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='". 
Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to
enable inline execution.

Which on the other hand suggests that a hash could be used to whitelist it (but this may be just a Chrome catch-all message).

Copied from original issue: w3c/webappsec#468

The text was updated successfully, but these errors were encountered:

mikewest · 2015-10-07T06:51:00Z

From @hillbrad on September 8, 2015 17:39

I would suggest that the Chrome-specific console text here is a bit
misleading.

Part of the difficulty here is that as a <script> block, one <script> is
roughly the same as another. But as an event handler, context is very
important. It's ok for "deleteAll()" to be attached to the big red button
that only appears after several confirmation steps, but not OK for an
injection to attach it to the "x" in the corner of an app install overlay.
So we would need to think a lot more about how to identify contexts, and
then you end up in a situation of potentially having to calculate running
hashes on much more of the DOM as it is parsed than is currently the case,
with potentially negative performance characteristics.

Maybe nonces are better for this use case, if we do need it?

And I'm not sure we do need it. On the application deployer side, where
the hash/nonce model is about processing/annotating legacy content to make
it CSP-compatible, it seems substantially as easy to "outline" these
handlers as it is to add a hash to them. See, e.g.
https://www.npmjs.com/package/noin

On Tue, Sep 8, 2015 at 8:54 AM Paweł Krawczyk [email protected]
wrote:

Reading through section 7.15 of the latest CSP2 editor's draft it seems
like you can't whitelist an inline event handler with its SHA256 hash. Is
this intended exclusion?

Just to provide a bit of background, the following script will only result
in one pop-up, from the whitelisted alert in the <script> tag:
<script>alert('Hello, world.');</script>
The inline handler alert will not be shown and Chrome will display the
following error message:

Refused to execute inline event handler because it violates the following Content Security Policy directive: "script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.

Which on the other hand suggests that a hash could be used to whitelist
it (but this may be just a Chrome catch-all message).

—
Reply to this email directly or view it on GitHub
w3c/webappsec#468.

mikewest · 2015-10-07T06:51:00Z

Chrome's error message is bad. I should fix that.
I didn't really intend for nonces or hashes to enable inline event handlers. It's something I suppose is worth reconsidering for CSP3, but the behavior for CSP2 (which is shipping in Chrome and Firefox) excludes them. As Brad notes, that's not at all a straightforward discussion.

mikewest · 2015-10-07T06:51:01Z

From @kravietz on September 8, 2015 18:41

Thanks, these are very helpful notes. I have already filed a Chrome bug report about this message, but wanted to confirm here what should be the correct browser's policy.

As for inline event handlers I do see quite a lot of them, especially if you include a Google AdSense code. While perhaps the correct approach should be to rewrite AdSense code not to use inline handlers, right now it is a real problem if you want to enable CSP on real world websites.

mikewest · 2015-10-07T06:51:01Z

From @hillbrad on September 8, 2015 18:49

Do those event handlers have to be inline? Is there a reason the necessary
elements can't be tagged by id or class and the event handlers added
imperatively by a script block?

On Tue, Sep 8, 2015 at 11:41 AM Paweł Krawczyk [email protected]
wrote:

Thanks, these are very helpful notes. I have already filed a Chrome bug
report about this message, but wanted to confirm here what should be the
correct browser's policy.

As for inline event handlers I do see quite a lot of them, especially if
you include a Google AdSense code. While perhaps the correct approach
should be to rewrite AdSense code not to use inline handlers, right now it
is a real problem if you want to enable CSP on real world websites.

—
Reply to this email directly or view it on GitHub
w3c/webappsec#468 (comment).

mikewest · 2015-10-07T06:51:02Z

From @kravietz on September 8, 2015 18:52

I'm sure they don't have to but in case of embedding a third party code such as Google AdSense you don't have much influence on how it's written. A workaround I came up with is to load AdSense code in a IFRAME from an URL that has a separate, more liberal CSP.

mikewest · 2015-10-07T06:51:02Z

From @kravietz on September 10, 2015 5:46

As for identifying context for whitelisting inline handlers I think it would be quite easy thing to do. For example for such handler:

<button id="action1" onclick="doSubmit()">

This might be whitelisted with the following hash expression:

sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY=#action1#click

joelweinberger · 2015-10-28T00:15:04Z

FWIW, this was a very specific choice we made in the design because there are quite a few corner cases around inline handlers. Of course, I can't recall any of them right now :-)

mikewest · 2016-02-18T15:37:34Z

Based on some feedback from folks implementing CSP, it would make things much easier to deploy if we allowed hashes to whitelist inline handlers. The risk boils down to an attacker taking a whitelisted action, and moving it to another element or handler. Honestly, that seems low-risk enough to not worry too much about the syntactical strangeness that #click#load#etc would introduce.

mikewest · 2016-02-18T15:38:18Z

Also, Firefox is apparently already doing this for style (and script?) according to https://code.google.com/p/chromium/issues/detail?id=546106.

@dveditz, WDYT?

michaelficarra · 2016-02-21T00:35:01Z

👎 I think there is a very real security risk here. A developer attempting to whitelist an inline script/style for a particular use may not be aware that it could be abused to apply malicious behaviour/styling to another element. And even if they were aware of this, it would be difficult to evaluate all the ways that this behaviour/styling could be used maliciously on every other element on the page.

mikewest · 2016-02-22T11:49:21Z

@michaelficarra: Would you be less sad if the developer had to opt-into this behavior with something like unsafe-apply-hashes-to-inline-event-handlers (or something shorter :) )?

michaelficarra · 2016-02-24T18:10:12Z

@mikewest Yes. Or something longer 😉.

dracos · 2017-11-07T11:26:30Z

"Do those event handlers have to be inline? Is there a reason the necessary elements can't be tagged by id or class and the event handlers added imperatively by a script block?" – I have stumbled across this issue because I wish to use <link rel="preload" href="style.css" as="style"> on a Content-Security-Policy-using site. All the docs (and the spec) for rel="preload" say I should then add onload="this.rel='stylesheet'" in order to activate the preload once loaded. But I cannot use inline event handlers on this site.

The best thing I can come up with is <link id="preload_base_css" rel="preload" href="style.css" as="style"> <script nonce="nonce">document.getElementById('preload_base_css').onload = function(){this.rel='stylesheet'}; but in testing (though I think with a few lines between the link and the script), if the CSS is already cached, say, it looks like it is possible for the link's onload event to trigger before the handler is attached, which makes it a bit useless. It might be okay like that, but I don't know if it's possible to guarantee the handler will be registered before it fires if it's not on the element itself?

Anyway, just saying this might be useful for that scenario, unless there's also a way I can add my CSP nonce to the <link> and have that permit inline event handlers or something else I haven't considered.

andypaicu · 2018-04-05T12:53:42Z

I have sent an e-mail on public-webappsec but in case someone follows this thread more closely, I will also leave a comment here.

I have put together an explainer for this and I would like to hear your thoughts.

https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing

ghost · 2019-03-10T00:49:56Z

Do those event handlers have to be inline? Is there a reason the necessary
elements can't be tagged by id or class and the event handlers added
imperatively by a script block?

It's my understanding that without unsafe-inline or at least to allow hashes for inline attributes that this affects scripts as well. Examples are Modernizr and loadCSS which set inline attributes programmatically. These scripts don't work unless you have unsafe-inline, which sort of defeats the point of having a CSP in the first place.

rehevkor5 · 2020-09-24T23:48:24Z

Another example of a library with inline event handler: https://git.shibboleth.net/view/?p=java-opensaml2.git;a=blob;f=src/main/resources/templates/saml2-post-binding.vm;h=b2f175013a1d0e953724ff1fe667a1eea6a19ed5;hb=HEAD#l15

This source expression allows hashes to match both event handlers and inline style attributes. Closes w3c/webappsec-csp#13. Closes w3c/webappsec-csp#40.

mikewest added the CSP label Oct 7, 2015

mikewest mentioned this issue Oct 7, 2015

Inline event handlers not whitelisted by hashes? w3c/webappsec#468

Closed

mikewest closed this as completed in a2bb43f Apr 14, 2016

mikewest mentioned this issue Nov 14, 2016

Make `unsafe-hashed-attributes' less unsafe #147

Closed

andypaicu mentioned this issue Oct 4, 2017

Add extra note for 'unsafe-hashed-attributes' to address backwards co… #247

Closed

brendt mentioned this issue Jul 26, 2018

responsive images and csp spatie/laravel-medialibrary#1128

Closed

bzbarsky mentioned this issue Nov 14, 2018

Broken references in "Integration with Fetch" section #367

Closed

ghost mentioned this issue Mar 10, 2019

Content Security Policy support filamentgroup/loadCSS#297

Closed

anno1985 mentioned this issue Aug 19, 2020

Make LightningJS support CSP olark/lightningjs#12

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Inline event handlers not whitelisted by hashes? #13

Inline event handlers not whitelisted by hashes? #13

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

joelweinberger commented Oct 28, 2015

mikewest commented Feb 18, 2016

mikewest commented Feb 18, 2016

michaelficarra commented Feb 21, 2016

mikewest commented Feb 22, 2016

michaelficarra commented Feb 24, 2016

dracos commented Nov 7, 2017

andypaicu commented Apr 5, 2018

ghost commented Mar 10, 2019

rehevkor5 commented Sep 24, 2020

Inline event handlers not whitelisted by hashes? #13

Inline event handlers not whitelisted by hashes? #13

Comments

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

mikewest commented Oct 7, 2015

joelweinberger commented Oct 28, 2015

mikewest commented Feb 18, 2016

mikewest commented Feb 18, 2016

michaelficarra commented Feb 21, 2016

mikewest commented Feb 22, 2016

michaelficarra commented Feb 24, 2016

dracos commented Nov 7, 2017

andypaicu commented Apr 5, 2018

ghost commented Mar 10, 2019

rehevkor5 commented Sep 24, 2020