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

On Wed, Oct 15, 2014 at 6:27 PM, Michal Zalewski <lcamtuf@coredump.cx>
wrote:

> So I might have started this on the wrong foot


Naah. Your criticism is a) not unexpected, and b) totally accurate. I
hopefully believe that you're overstating the negatives, and
underestimating the positives, but that's kinda your job. :)

Also, I did a poor job of making my actual desire clear; I should have
focused more on the problem, and less on the proposed solution. I'll try to
be more general going forward: In a nutshell, Chrome's non-browser
processes are corrupted significantly more often than it's browser process.
Reducing their ability to request credential data seems like a
straightforward win. In order to do that without breaking valid use-cases,
we need a signal from the page that it's not intending to touch the value.
This signal is conceptually similar to CSP's broader "I'm not going to use
eval()." or "I'm not going to use XHR." statements, and would allow
password managers to flag credentials as writeonly, similar to how we flag
cookies as httponly today.

"writeonly" is only one way to provide this signal. Its advantage is
simplicity: existing sign-in forms can add this attribute today without
changing anything else at all in their flow.

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.
>

Yup. That's not a scenario that this proposal improves in the slightest. If
the user is typing something into a corrupted page, attackers can read that
something in a number of ways.


> 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.
>

This is the scenario I'm focusing on.

We already track much of the form's context in Chrome's password manager in
order to determine which credential to insert into a given form. I imagine
other password manager do likewise. We're not using that data in this way
yet, but it's certainly a direction I'd like to explore.


> The CSP solution + blocking GET feels like a crutch that won't work in
> practice;


(Restricting browser's autofill of password and credit card data to POST is
probably something we should do regardless of this proposal.)


> 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.


On the web at large, yes. For particular form fields that we know to be
interesting, maybe no. I just tried Google, Facebook, and PayPal's sign-in
forms: none touched the password field before sending it out on the wire.
Allowing them to assert that they're not going to, and to protect users'
saved credentials based upon that assertion, seems like a reasonable goal.


> 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 there's no reason that the password manager couldn't mark
form fields as writeonly when inserting known-to-be-writeonly
credentials  (or simply refuse to autofill into a read/write field). We
don't have to rely on the field being pre-protected if we know that it
asserted certain things in the past when we saved the credential in
question. Both CSP and the inline attribute could be treated as persistent
signaling mechanisms, conceptually similar to httponly or HSTS, which
mitigates some of the risk you're pointing to here.


> (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.
>

Granted.


> 3) Regular compromised renderers / malware stealing the data manually
> entered or automatically populated by the browser? Not doable.
>

Assuming that we ever send the information to the renderer, granted. I'd
like to avoid doing that by, for example, sending a nonce to the renderer,
and replacing that nonce in the browser process before sending the request
out onto the network.


> 4) Future Chrome origin-bound sandboxed renderers stealing the data
> manually entered by the user? Probably not doable, by analogy with #1.
>

Granted. Data the user types into a page is always readable, one way or
another.


> 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.


Consider that we can use this signal to flag the _credential_ as writeonly.
We don't have to rely on the form _always_ being so flagged.


> 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.
>

This is more of a problem for things like credit cards which are reused
everywhere than for credentials, which are not.

Like most other things in security, this proposal would make an attacker's
job harder, but certainly not impossible. It is not revolutionary in any
sense, but throws up some new roadblocks, and is _trivial_ for a website
author to implement. That last bit is important.


> 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.
>

I hope you are, as this is a problem I'd like to address.

-mike

Received on Thursday, 16 October 2014 07:31:01 UTC