- From: Roger Hågensen <rescator@emsai.net>
- Date: Thu, 16 Oct 2014 05:05:48 +0200
- To: whatwg@lists.whatwg.org
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