Content Security Policy (CSP) implement unsafe-hashes
Categories
(Core :: DOM: Security, task, P3)
Tracking
()
People
(Reporter: luke.semerau, Assigned: tschuster)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-complete, parity-chrome, Whiteboard: [domsecurity-backlog1])
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Steps to reproduce:
Example HTML:
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-hashed-attributes' 'sha256-XTqNqFSUlZHAW7f/OGNYSOEzxKhjdAAGMXoid2VEbJk=';">
</head>
<body>
<button onclick="alert('hi')">click me to say hi</button>
</body>
</html>
Click on button.
Actual results:
console:
Content Security Policy: Couldn’t parse invalid host 'unsafe-hashed-attributes'
Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src 'sha256-XTqNqFSUlZHAW7f/OGNYSOEzxKhjdAAGMXoid2VEbJk='”). Source: onclick attribute on BUTTON element.
Expected results:
Alert with 'hi' should shown.
https://w3c.github.io/webappsec-csp/#unsafe-hashed-attributes-usage
|
||
Updated•7 years ago
|
|
||
Comment 2•5 years ago
|
||
This seems to have been renamed to 'unsafe-hashes'
|
||
Updated•4 years ago
|
| Comment hidden (spam) |
| Comment hidden (spam) |
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
| Comment hidden (spam) |
| Comment hidden (spam) |
|
||
Comment 7•1 year ago
|
||
did you fix it? if so, how?
|
Assignee | |
Comment 8•1 year ago
|
||
|
||
Updated•1 year ago
|
Pushed by tschuster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/734d03776a9c CSP: Enable the 'unsafe-hashes' keyword by default. r=freddyb
| Comment hidden (spam) |
|
||
Comment 11•1 year ago
|
||
| bugherder | ||
|
||
Comment 13•1 year ago
|
||
We've received multiple reports about Microsoft Azure data factory breaking since changes in bug1797070. It's currently broken on release (108) and fixed in Nightly (110) by this patch (confirmed with mozregression --find-fix).
Hi Tom, following up on your comment3 from bug1806845 , wonder if it's possible to uplift this patch to Beta and maybe release since there might be a lot of users affected?
|
|
Assignee | |
Comment 14•1 year ago
|
||
Comment on attachment 9308661 [details]
Bug 1343950 - CSP: Enable the 'unsafe-hashes' keyword by default. r?freddyb
Beta/Release Uplift Approval Request
- User impact if declined: Previously working websites were broken. Hard to workaround for websites without decreasing their security.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This was tested in Nightly already. Most of the code already existed, but now is "opt-in" (via 'unsafe-hashes') for websites.
- String changes made/needed: n/a
- Is Android affected?: Yes
|
||
Comment 16•1 year ago
|
||
Comment on attachment 9308661 [details]
Bug 1343950 - CSP: Enable the 'unsafe-hashes' keyword by default. r?freddyb
Not super crazy about taking this so late in the beta cycle, but I'm also not crazy about leaving sites broken for another cycle. Approved for 109.0b8 but let's be on the lookout for any regressions.
|
|
||
Comment 17•1 year ago
|
||
| bugherder uplift | ||
|
||
Comment 19•1 year ago
|
||
Tracking issue for MDN updates https://github.com/mdn/content/issues/23679
|
||
Updated•1 year ago
|
Description
•