Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Inline event handlers not whitelisted by hashes? #468

Closed
kravietz opened this issue Sep 8, 2015 · 8 comments
Closed

Inline event handlers not whitelisted by hashes? #468

kravietz opened this issue Sep 8, 2015 · 8 comments
Labels
CSP
Milestone
CSP 3

Comments

@kravietz
Copy link

kravietz commented Sep 8, 2015

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).
@hillbrad
Copy link
Contributor

hillbrad commented Sep 8, 2015

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 notifications@github.com
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
#468.

@mikewest mikewest added this to the CSP 3 milestone Sep 8, 2015
@mikewest mikewest added the CSP label Sep 8, 2015
@mikewest
Copy link
Member

mikewest commented Sep 8, 2015

  1. Chrome's error message is bad. I should fix that.
  2. 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.

@kravietz
Copy link
Author

kravietz commented Sep 8, 2015

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.

@hillbrad
Copy link
Contributor

hillbrad commented Sep 8, 2015

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 notifications@github.com
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
#468 (comment).

@kravietz
Copy link
Author

kravietz commented Sep 8, 2015

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.

@kravietz
Copy link
Author

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

@mikewest mikewest mentioned this issue Oct 7, 2015
Closed
@mikewest
Copy link
Member

mikewest commented Oct 7, 2015

This issue was moved to w3c/webappsec-csp#13

@mikewest mikewest closed this as completed Oct 7, 2015
@mikewest mikewest mentioned this issue Nov 14, 2016
Closed
@esserj
Copy link

esserj commented Mar 24, 2020

you can always add 'unsafe-hashes' to your script-src (or style-src) if you want to allow them.

<!DOCUMENT html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="default-src none; script-src 'unsafe-hashes' '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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CSP
Projects
None yet
Milestone
CSP 3
Development

No branches or pull requests
4 participants
@mikewest @kravietz @esserj @hillbrad