- From: Mike West <mkwst@google.com>
- Date: Wed, 15 Oct 2014 16:15:15 +0200
- 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