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

On Thu, Oct 16, 2014 at 3:07 PM, Mike West <mkwst@google.com> wrote:

> 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.
>
Well, it doesn't today. But maybe you mean in the future.

But the point is that there are many ways to exfiltrate, these are just the
first thing that comes to mind but others like <input pattern> also are an
info leak, and I mean, these are just ideas coming up the top of my mind,
the browser wasn't designed to solve this problem and it's dubious if it's
really feasible to do so without reinventing a lot of things.


> 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.
>

The user would just have to type the full password (including the extra
cookie-random value that the password manager backed up). The caveat of
course is that the user has to write this suffix somewhere, but that is
what makes the password strong anyway.

And anyway, to be clear, this is just a discussion on an alternate design
that has the same properties and is significantly easier to implement for
both, authors and UAs, but it's by no means the only solution. My point is
that there are probably simpler solutions that have similar security
guarantees.

--
> 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 14:29:42 UTC