Yes. Two things about service workers:
1. If you can spin up a service worker, the site is already very much in
trouble.
2. I have handwavey ideas about ensuring that the FormData object which
would be readable via the Request object in the service worker would retain
the opaque flag. The spec
input writeonly type=password
I think that one huge problem with this is that the attacker will have
many other, indirect ways to get the value even if you protect direct
access to the field. Two most obvious options include:
1) Change the action value for the form to point to evil.com,
Good feedback, Michal. Thanks!
On Wed, Oct 15, 2014 at 4:41 PM, Michal Zalewski lcam...@coredump.cx
wrote:
input writeonly type=password
I think that one huge problem with this is that the attacker will have
many other, indirect ways to get the value even if you protect direct
access
1) Change the action value for the form to point to evil.com, where
evil.com is in attacker's control,
I hope that this is mitigated by the `form-action` CSP directive, which
allows the site to control the valid endpoints for form submission, and
`connect-src`, which allows the same for XHR,
Fair enough - although I worry that the likelihood of people using
this in conjunction with tightly-scoped per-document CSP (versus the
far more likely scenario of just having a minimal XSS-preventing
site-wide or app-wide policy that will definitely not mitigate #3 and
probably do nothing
On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski lcam...@coredump.cx
wrote:
Fair enough - although I worry that the likelihood of people using
this in conjunction with tightly-scoped per-document CSP (versus the
far more likely scenario of just having a minimal XSS-preventing
site-wide or
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?
- Would one be able to validate the password field (eg, to detect an empty
password)? Is HTML5 validation allowed on a writeonly field.
- Could a cross-domain XHR be made? Could FormData from such a field be
limited to the same domain.
- Something that could be interesting is if the password field
So I might have started this on the wrong foot, but let's consider the
broader threat model. What do we want to protect against?
1) XSS stealing the passwords / CC numbers entered by the user
manually? This is probably not possible with this proposal; the evil
payload may construct a form where
On Wed, Oct 15, 2014 at 5:59 PM, Domenic Denicola
dome...@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?
The strawman suggests setting a flag on the
On Wed, Oct 15, 2014 at 6:10 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
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
Yea the keyup/down/press restrictions are definitely not useful, at least
for password protection since the user has clearly no way to know if the
field is safe or not.
The tainting is never gonna work reliably and consistently as Michal hinted
(say, a blob: URL would run in the same origin but
On 2014-10-15 18:10, Tab Atkins Jr. wrote:
On Wed, Oct 15, 2014 at 8:59 AM, Domenic Denicola
dome...@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?
Was Re: [whatwg] Proposal: Write-only submittable form-associated
controls.
On 2014-10-16 01:31, Eduardo' Vela Nava wrote:
If we have a password manager and are gonna ask authors to modify their
site, we should just use it to transfer real credentials, not passwords..
Passwords need to die
14 matches
Mail list logo
