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

- Would one be able to validate the password field (eg, to detect an empty
password)? Is HTML5 validation allowed on a writeonly field.
- Could a cross-domain XHR be made? Could FormData from such a field be
limited to the same domain.
- Something that could be interesting is if the password field only exposed
an encrypted or hashed value. For example, it'd be pretty awesome if a
website could put a public key and say "when a user types in a password
here, encrypt it with the public key before sending to the server". This
could prevent an attacker from ever seeing the plain text password. Today
you could do this with JS, but it would prevent one from using the
writeonly attribute.

On Wed, Oct 15, 2014 at 4:15 PM, Mike West <mkwst@google.com> wrote:

> # 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 16:27:33 UTC