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

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

From: Mike West <mkwst@google.com>
Date: Thu, 16 Oct 2014 15:07:53 +0200
Message-ID: <CAKXHy=eg-LUzxymAqU6FyCRWW8BJDkvEj=8OBmNLt0Bo6epwqA@mail.gmail.com>
To: "Eduardo' Vela <Nava>" <evn@google.com>
Cc: WHAT Working Group Mailing List <whatwg@whatwg.org>
On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela" <Nava> <evn@google.com>
wrote:

> On Thu, Oct 16, 2014 at 11:59 AM, Mike West <mkwst@google.com> wrote:
>
>> On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela" <Nava> <evn@google.com>
>> wrote:
>>
> OK, so it's just being locked down out of a formality, but has no security
> purpose. Sure, so it's not useful for any security purposes.
>

Well, no. It doesn't solve the problem, but it introduces a hurdle. Making
an attacker do more work is good.

> 2. How is the tainting problem simplified by focusing on write only?
>>>
>>  Focusing on autofill means that we're moving the flag up to the
>> credential, so we can ensure that the browser only autofills into writeonly
>> form fields. To your specific example, it means we don't have to care about
>> blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in
>> iframes.
>>
>
> The blob: URL would simply steal the FormData from the other page (it's
> same origin), and submit it via XHR to another origin..
>

Ah, that's clever! However: blobs inherit the CSP of their parent frame, so
the same mitigations apply.

Moreover, if we're doing the network-stack replacement thing, and we know
details about the credential, then we can refuse to do the replacement in
the browser process if the destination doesn't match the details we have
stored for the credential, CSP or not.

> 3. How is tagging the credential as write-only help with the secure
>>> deployment of a site-wide CSP policy?
>>>
>> It doesn't. The two are completely unrelated.
>>
>> My point was simply that if we tag a credential as writeonly, we wouldn't
>> fill it into a form that lacked the writeonly flag in a page that lacked
>> the writeonly CSP. Solving CSP deployment isn't a precondition of this
>> scheme.
>>
>
> I see, so it wouldn't be sufficient to make a field writeonly, you would
> also need to declare that in the CSP.
>

Let me rephrase: if we tag a credential as writeonly, we wouldn't fill it
into a form field that wasn't writeonly. Form fields are tagged writeonly
either by virtue of an inlined attribute, or a CSP on the page.

Either individually signals to the browser that the site does not intend to
make programmatic use of the field's value. We wouldn't need both in order
to decide when to tag a credential as writeonly.


> The whole website would have to have connect-src policies stricly
> restricting the exfiltration of data from the domain. Is there any
> (relevant/important) website where locking down connect-src for the whole
> origin is possible or feasible? Or are we assuming every website has their
> login form in a unique origin? (Are you expecting to have per-page
> suborigins implemented before this is feasible?).
>
> 4. Why are sites that echo passwords in password fields shooting
>> themselves in the foot?
>>
> Echoing sensitive data in a place where an injected XHR can read it is a
>> general problem. This proposal doesn't make that worse.
>>
>
> Sensitive data is echoed in places where XHRs can read all the time. Your
> email, your authentication credentials (OAuth, etc), your bank statements.
> This isn't a general problem.
>

It is a general problem, given the attack vector you're proposing: if I can
inject a same-origin XHR, I can read sensitive data. That includes
passwords, if the passwords are echo'd out in the page's contents. I'm
agreeing with you that writeonly doesn't solve this problem.

I'd suggest that sites themselves could solve it by echoing a nonce rather
than the original password, but that's obviously up to them and not
something we could spec.

> Sounds like a great way of hardening sign-in. It's not clear to me how
>>> that negates the problem of password theft, as I'd still need to be able to
>>> sign in on my friend's computer when I accidentally spill coke on my
>>> laptop, right?
>>>
>>
> How is the password manager able to sync your password to your friend's
> computer?
>

I wasn't clear: the server still needs to accept a bare username/password
pair, as it's not the case that users only log in a) using a password
manager, b) on a machine that's syncing. As long as that's the case, I
don't see how tying passwords to a cookie makes password theft less
problematic.

--
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 Thursday, 16 October 2014 13:08:45 UTC

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