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

[andypaicu]

…mpatibility and removed WIP tag

---

Preview | Diff

[andypaicu]

Not sure what to make of the error, I've raised a bug against bikeshed. speced/bikeshed#1110

[andypaicu]

Also I've just added people that I saw in #13, if you know of anyone else who would have input please add them.

[mikewest]

@devd, @hillbrad, @arturjanc, @mozfreddyb, @dveditz, @dbates-wk, @AngeloKai: We've had unsafe-hashed-attributes floating around for years now. I think we need to either decide to ship it or punt on the feature. My intuition is that shipping it as-is would be better than either not shipping it or building some convoluted backwards-compatibility story (e.g. "sha256+hashhashhash instead of sha256-hashhashhash means handlers match!").

WDYT?

[arturjanc]

To me the most important signal is how other browser vendors feel about this -- it would be nice to have 'unsafe-hashes-attributes', but it's probably not a hill anyone wants to die on ;-)

FWIW we have several places at Google where we would use this feature (e.g. to generate policies based on hashes for all static HTML documents) and it would allow interesting modes for automated CSP deployments. I expect there are other developers who would use it for a similar purpose.

[devd]

I am not particularly excited by this.

I agree it will be useful, but there is a cost to the additional complexity in the spec and, from the web app side, the need to understand the CSP support matrix all the different browsers. We do need to be careful around adding more to CSP only if there is a significant win.

From the security side, there are some concerns: in particular, see https://twitter.com/kkotowicz/status/915928032988270597 e.g. and other cases. If we are going to do this, I think the hash should include the attribute name that it applies to. When you add it all up, the list of hashes will be gigantic and painful to manage. A signature scheme or a nonce based scheme is a lot easier to deploy than this, IMO.

I am also not convinced by Artur's point about static HTML pages (sorry Artur!). Is there a reason those can't be rewritten to use script tags? This can be done mostly automatically---you will have to parse the static HTML to anyways create the hash list; parsing and rewriting to use script tags seems not unreasonable. OR, parsing and rewriting to enforce a stronger csp policy after DOMContentLoaded also seems that it will fix this.

So, yeah---taken all together, my point is that I am not sure it adds enough security value for the increase in complexity.

[arturjanc]

I agree that if people dislike the feature and believe the cost of U-A sniffing (which is my least favorite part of this) is too high, then we can abandon it. However, it will come at a cost of not being able to deploy CSP in fairly important parts of the web (e.g. the static content case, which is the main difficulty for authors who use nonces, and where DOM XSS bugs are disproportionately likely to happen).

Maybe we should leave this to suborigins, but as it stands there is nothing to help solve this problem, and 'unsafe-hashed-attributes' would be a fairly low-effort mitigation given that per-page CSP policies could be generated automatically.

I also think there are significant misunderstandings of both the insecurity of whitelsting scripts by a hash (1), and the (IMO illusory) value of tying the script to a particular event handler (2):

1. We've long known of the <script>i++; if (i > 3) { blowUp() } </script> case for CSP2 hashes. This is certainly not ideal, but compared to the alternative, which is unconstrained execution of JS affecting the entire origin, it doesn't sound particularly scary. I haven't yet seen a realistic bypass of a hash-based policy which would be close to the badness of full XSS; I'm hard-pressed to see how this would be different with event handlers.

2. The vast majority of inline event handlers are onload/onerror, onclick, and onmouse*. In the first case attaching the handler name has no value (the event gets triggered automatically on attacker-inserted DOM elements); for clicks and other mouse events an attacker can almost always use CSS present in the application create invisible elements which will trigger events when the user interacts with the page in any way.

I have significantly more faith in the security benefit of a whitelist of allowed expressions than in constraining the attacker to only a few chosen event handlers, given that the attacker has control of the DOM. IOW, as an attacker, I likely won't be able to get arbitrary script execution if my payloads are checked against a whitelist, but I will totally bypass event handler name restrictions in a small amount of time for any realistic application.

Re: rewriting static event handlers as script tags, keep in mind that ~90% of pages with CSP set 'unsafe-inline' without nonces or hashes (https://research.google.com/pubs/pub45542.html). We certainly can tell everyone they should refactor their markup but in practice it's not going to happen (I can elaborate on all the reasons why it can't happen at Google where we have many competent engineers, both in security and product teams; I can imagine this is even harder in other places).

The practical choice we're facing is unfortunately either CSP with carveouts for existing scripts/event handlers -- and, sadly, with User-Agent sniffing -- or no CSP at all. FWIW I think both of these choices are legitimate, which is why getting opinions from the few people who understand the nuances here seems like a good way to settle this.

[briansmith]

I can elaborate on all the reasons why it can't happen at Google where we have many competent engineers, both in security and product teams

Please do.

[devd]

Does the "insert new policy after DOMContentLoaded" not work either? Would a CSP header that tells the browser to enforce CSP after domcontentloaded solve your use case? I feel better about that than the complexity of the hash src for event handlers

[andypaicu]

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

[andypaicu]

This is out-of-date closing in favor of #311