W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Wed, 15 Oct 2014 09:27:45 -0700
Message-ID: <CALx_OUA-H5CjPfYDsm5Ahk-ci9kJcWB=9=39pZ_YLRjQY6Y2OQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC