- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Wed, 15 Oct 2014 09:27:45 -0700
- To: Mike West <mkwst@google.com>
- Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>, Jonas Sicking <jonas@sicking.cc>
So I might have started this on the wrong foot, but let's consider the broader threat model. What do we want to protect against? 1) XSS stealing the passwords / CC numbers entered by the user manually? This is probably not possible with this proposal; the evil payload may construct a form where the writeonly attribute is not set. 2) XSS stealing the passwords entered by the password manager? To do this, I feel that we need a taint-tracking system coupled with a password manager that remembers that some passwords can go only into writeonly fields, and which URLs and methods they need to be submitted to. The CSP solution + blocking GET feels like a crutch that won't work in practice; my main concern is that writing site-wide policies is hard as-is, and that the likelihood of well-scoped per-page policies, especially with path granularity, is low. But if we go the CSP route, breaking writeonly fields if form targets are not policed may be the best we can do. (Also note that my attack #3 will work simply if XSRF tokens are user- but not action-bound, which is a common pattern.) I also expect many other corner cases to crop up when others look at the implementations later on. 3) Regular compromised renderers / malware stealing the data manually entered or automatically populated by the browser? Not doable. 4) Future Chrome origin-bound sandboxed renderers stealing the data manually entered by the user? Probably not doable, by analogy with #1. 5) Future Chrome origin-bound sandboxed renderers stealing the data auto-populated by the password manager? Feels like for this, we need taint tracking; otherwise, the renderer can ask for the password under false pretenses, perhaps after loading a sub-page with different or no CSP rules. We could try giving the renderer a token that is converted to a password on an ongoing request by the network stack, but there is no way to confirm that the request is being made to the right destination and in good faith. ... The reason why I was previously skeptical of proposals of write-only fields is pretty much because the threat model is so complicated and the solutions are so fragile - but maybe I'm in the wrong on this. /mz
Received on Wednesday, 15 October 2014 16:28:49 UTC