Intent to Implement: 'unsafe-hashes' in CSP3
Andy Paicu
Contact emails
Spec
https://w3c.github.io/webappsec-csp/#unsafe-hashed-attributes-usage
+PR that will land soon that removes WIP tag and changes the name to 'unsafe-hashes':
https://github.com/w3c/webappsec-csp/pull/311
Summary
Explainer: https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing
'unsafe-hashes' is a feature in CSP3 that allows developers to whitelist by hash event handlers, style attributes and `javascript:` URLs.
Currently the way to do this is by using 'unsafe-inline' which provides basically on defense if used. If website authors wish to also use hashes or nonces as part of their policy, inline event handlers/style attributes or `javascript:` URLs can't be used at all.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes (in progress).
Current tests: https://wpt.fyi/results/content-security-policy/unsafe-hashed-attributes
CR in progress to have full tests: https://chromium-review.googlesource.com/c/chromium/src/+/1095217
Entry on the feature dashboard
https://www.chromestatus.com/feature/5867082285580288
Philip Jägenstedt
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYgmCt76aMdzT5JvzyJVe82n35uu9ZgnNyQN3TA%3DJeCEUg%40mail.gmail.com.
Yoav Weiss
Contact emails
Spec
https://w3c.github.io/webappsec-csp/#unsafe-hashed-attributes-usage
+PR that will land soon that removes WIP tag and changes the name to 'unsafe-hashes':
Summary
Explainer: https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing
'unsafe-hashes' is a feature in CSP3 that allows developers to whitelist by hash event handlers, style attributes and `javascript:` URLs.
Currently the way to do this is by using 'unsafe-inline' which provides basically on defense if used. If website authors wish to also use hashes or nonces as part of their policy, inline event handlers/style attributes or `javascript:` URLs can't be used at all.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Interoperability and CompatibilityEdge/Firefox/Safari/Opera: LukewarmThe explainer above has been discussed at TPAC as well as during WebAppSec meetings and it was considered a useful feature as there are currently no reasonable alternatives for whitelisting inline event handlers in CSP.There are concerns about growing complexity of CSP but I don't know enough about the people to link them to specific browsers.
--Web developers: PositiveThe Security Enhancements and Mitigations team also have applications for this feature.Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
Yes (in progress).
Current tests: https://wpt.fyi/results/content-security-policy/unsafe-hashed-attributes
CR in progress to have full tests: https://chromium-review.googlesource.com/c/chromium/src/+/1095217
Entry on the feature dashboard
https://www.chromestatus.com/feature/5867082285580288
Regards,Andy Paicu
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Andy Paicu
On Thu, Jun 21, 2018 at 1:51 PM 'Andy Paicu' via blink-dev <blin...@chromium.org> wrote:Contact emails
Spec
https://w3c.github.io/webappsec-csp/#unsafe-hashed-attributes-usage
+PR that will land soon that removes WIP tag and changes the name to 'unsafe-hashes':
Unrelated bikeshed comment: the name seems confusing. Is using that attribute considered "unsafe"? Isn't this supposed to fix the "unsafe" bits in `unsafe-inline`?
Summary
Explainer: https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing
'unsafe-hashes' is a feature in CSP3 that allows developers to whitelist by hash event handlers, style attributes and `javascript:` URLs.
Currently the way to do this is by using 'unsafe-inline' which provides basically on defense if used. If website authors wish to also use hashes or nonces as part of their policy, inline event handlers/style attributes or `javascript:` URLs can't be used at all.
That feature seems very much needed to help developers deploy CSP in the wild, on existing sites, with their multitude of inline handlers. At the same time, there can be *many* hashes on a typical site. Have y'all looked at what the policy of a typical target site look like? How many hashes would be needed?
Yoav Weiss
There is no TAG review, I will take care of it.On Thu, Jun 21, 2018 at 3:24 PM Yoav Weiss <yo...@yoav.ws> wrote:On Thu, Jun 21, 2018 at 1:51 PM 'Andy Paicu' via blink-dev <blin...@chromium.org> wrote:Contact emails
Spec
https://w3c.github.io/webappsec-csp/#unsafe-hashed-attributes-usage
+PR that will land soon that removes WIP tag and changes the name to 'unsafe-hashes':
Unrelated bikeshed comment: the name seems confusing. Is using that attribute considered "unsafe"? Isn't this supposed to fix the "unsafe" bits in `unsafe-inline`?There's a section in the explainer about why it's still not entirely "safe" and it needs the "unsafe-" prefix and it goes into more detail. It is still a bit unsafe as it allows an attacker that has DOM injection capabilities to execute whitelisted event handlers from the page. It's far far far better than 'unsafe-inline' which just allows arbitrary code execution.
The "safe" alternative is not using even handlers but that requires a refactoring effort that is not always reasonable to expect from developers.
Summary
Explainer: https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit?usp=sharing
'unsafe-hashes' is a feature in CSP3 that allows developers to whitelist by hash event handlers, style attributes and `javascript:` URLs.
Currently the way to do this is by using 'unsafe-inline' which provides basically on defense if used. If website authors wish to also use hashes or nonces as part of their policy, inline event handlers/style attributes or `javascript:` URLs can't be used at all.
That feature seems very much needed to help developers deploy CSP in the wild, on existing sites, with their multitude of inline handlers. At the same time, there can be *many* hashes on a typical site. Have y'all looked at what the policy of a typical target site look like? How many hashes would be needed?There was research done on pages that the SEAM team would like to use this on. Not sure how representative it is for the entire web ecosystem but on those pages we had only 0.23% of pages having more than 20 event handlers and none over 50 which should not be a problem.I imagine large pages might not be using this at all anyway as they maybe opt for nonces and script libraries.