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

On 2014-10-15 18:10, Tab Atkins Jr. wrote:
> On Wed, Oct 15, 2014 at 8:59 AM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
>> For the XSS attacker, couldn't they just use `theInput.removeAttribute("writeonly"); alert(theInput.value);`?
>>
>> Or is this some kind of new "un-removable attribute"?
> Doesn't matter if it is or not - the attacker can still always just
> remove the <input> and put a fresh one in.
>
> Nothing in-band will work, because the attacker can replace arbitrary
> amounts of the page if they're loaded as an in-page script.  It's
> gotta be *temporally* isolated - either something out-of-band like a
> response header, or something that has no effect by the time scripts
> run, like a <meta> that is only read during initial parsing.
>
> ~TJ
>

There is also legitimate needs for being able to edit the password field 
from a script.
I have a custom login system (that is currently in public use) that 
takes the password, does a HMAC on it (plus a salt and some time limited 
info).
This allows login in without having to send the password in the clear. 
It's not as secure as https but it's better than plaintext.

A writeonly password field would have to be optional only or my code 
would break.
And I'm not the only one. SpiderOak.com also uses this method (they use 
bcrypt on the password to ensure that SpiderOak has Zero-Knowledge).

Any limitations on form manipulations should be based on same origin 
limitations instead, such that only a javascript with the same origin as 
the html with the form can read/write/manipulate the form.


-- 
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/

Received on Thursday, 16 October 2014 03:23:16 UTC