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

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:
>
>> 1. How are keyup/down/press restrictions useful for password protection?
>> Actually they seem more useful for CSRF instead.
>>
> These events are some of the many ways in which the data being typed into
> a particular field is exposed to script. If we're going to call the field
> writeonly, we need to lock those down. That said, they only protect that
> particular field: attackers can easily bypass this restriction by doing
> more work (overlaying a new form, etc).
>
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.

How are they useful for CSRF? I don't see the link.
>
Let's not go into it. But if you lock down an origin as described in the
spec, and send a FormData via XHR then one could authenticate an action
came as a result of a user action. Anyway, I shouldn't have said that, the
solution is incomplete since value="" prefilling would also have to be
disabled for that to work.

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

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

> Imagine if the password manager, instead of just syncing passwords around
>> also moved an httpOnly cookie. And whenever it detects the password going
>> by it appends the httpOnly cookie.
>>
>> If the server detects such cookie in the request it concatenates it after
>> the password and uses that as the auth credential.
>>
>> On the server, this only requires a one line change (adding he cookie at
>> the end if present), on the client the APIs already exist.
>>
>> Same can be done with Channel ID with the further advantage that the OBC
>> can't be copied. The advantage of the cookie approach is that it can be
>> morphed and generated more easily.
>>
> 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?

> Also, as a point of reference we've redone authentication many more times
>> in a lot less time with a lot less resources than deployed CSP across all
>> of Google. So yes, it's easier.
>>
> That surprises me.
>
> Still, I suspect both are significantly more work than adding an attribute
> to a form field.
>
> --
> 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 10:17:21 UTC