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

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

From: Mike West <mkwst@google.com>
Date: Wed, 15 Oct 2014 16:15:15 +0200
Message-ID: <CAKXHy=eVkSPmKApcNCMB0NLiVWw_eiJ+iLYFAM0KQKH9e8uJ9A@mail.gmail.com>
To: WHAT Working Group Mailing List <whatwg@whatwg.org>
Cc: Jonas Sicking <jonas@sicking.cc>
# Problem

A user’s credentials are valuable, and are often the key target of phishing
and content injection attacks. If a content injection attack can trick a
user's credential manager into autofilling her credentials, then the user’s
credentials will be available to the attacker directly via DOM APIs or
indirectly via form submission to a malicious endpoint. The latter risk can
be mitigated via the Content Security Policy `form-action` directive, but
the former is a real problem. If passwords are a simple value accessor
away, users are at risk.

## Proposal

We could mitigate this latter risk by allowing sites to opt-in to denying
DOM access to an element's content. If JavaScript can't grab the value,
then script injection attacks have a much more difficult time exfiltrating
interesting data. This might be as simple as adding a writeonly attribute
to submittable elements:

    <input writeonly type="password">

This would throw an `InvalidStateError` on `value*` accessors, bar the
element from constraint validation, block `keydown`, `keyup`, `keypress`
events, and probably other things I haven't considered yet.

`FormData` objects created from forms including these writeonly elements
would be "opaque". You could use them to submit an XHR request, but you
couldn't read the values directly from script.

This state could also be controlled via a Content Security Policy directive
which would set writeonly state for some arbitrary set of submittable
elements, perhaps based on autocomplete attribute values. Perhaps:

    Content-Security-Policy: form-writeonly cc-number cc-csc ...
current-password new-password

## Spec Suggestions

I've strawmanned out the monkey-patching this would require of XHR, Fetch,
and HTML in a bit of detail at
https://mikewest.github.io/credentialmanagement/writeonly/, and there was a
short-lived public-webapps thread at
http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0165.html (and
a shorter-lived discussion at
http://specifiction.org/t/write-only-input-fields/598).

## Implementer Interest

I'd like to implement pieces of this in Chrome to harden our password
manager; if we can use this state as a heuristic to mark particular
credentials as writeonly, we can keep them out of the renderer process
entirely, which would be a nice win for security.

I've also talked about it tangentially with Anne and Jonas at Mozilla (the
former in relation to Fetch, the latter in relation to a proposed
Credential Management API). Neither jumped on it as the best thing ever,
but they were both more than marginally supportive.

Thanks!

--
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:16:01 UTC

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