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

Good feedback, Michal. Thanks!

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

> >     <input writeonly type="password">
>
> I think that one huge problem with this is that the attacker will have
> many other, indirect ways to get the value even if you protect direct
> access to the field. Two most obvious options include:
>

Note that there are two types of attacker I care about:

1. XSS. You've outlined some (of the probably many) ways to bypass the
kinds of protection I'd like to build here. Let's discuss below.

2. Renderer flaws. Currently, if someone can corrupt Chrome's renderer
process, she can request any and all passwords from the password store by
pretending to be various origins. If we can mark certain credentials as
"writeonly", we know we never have to send them to the renderer, and that
any such requests could be ignored. This is similar to what (I hope) we're
doing with `httponly` cookies (though I haven't checked, it seems like an
obvious optimization).


> 1) Change the action value for the form to point to evil.com, where
> evil.com is in attacker's control,
>

I hope that this is mitigated by the `form-action` CSP directive, which
allows the site to control the valid endpoints for form submission, and
`connect-src`, which allows the same for XHR, EventSource, WebSockets, etc.


> 2) Change the action of the form to GET while keeping the same method,
> let it submit, and then examine location.search.
>

Good idea. One way of avoid this would be to lock all forms with writeonly
data and XHR with opaque FormData to the POST method. That's probably what
we'd like folks to be doing anyway in order to keep potentially interesting
information out of server logs and browser history.


> 3) Change the action value of the form and the name of the password
> field so that the posted data is interpreted by the server as an
> attempt to, say, post a comment.
>

Again, mitigated (but by no means avoided) by path restrictions on the
`form-action` CSP directive.


> I worry that there's actually more, and that a lot of nasty "taint
> tracking" heuristics would be required to make it go away.
>

That's something I'd like to avoid, insofar as possible. I think it's
likely unavoidable to have some sort of opaque flag on request objects in
order to do the right thing with regard to ServiceWorkers, but since we
already track opaqueness for responses, I hope that's not an overly
burdensome taint to track.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Wednesday, 15 October 2014 14:57:15 UTC