New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User agent should/may not allow overriding "store" and "get" #63
Comments
I understand the concern, however, consider is the behavior of password-managing extensions. I think it's important that programs like LastPass, 1Password, etc, be able to interject themselves between the site and the browser. That's their whole point. If we make |
I agree. There are two ways user agents can provide that kind of
flexibility, either allowing injections to web pages like you mentioned or
they can provide API in their own extension/plugin ecosystem.
I would say the second is better because comparing to tools you mentioned,
protecting users personal data from compromised is way more important. Most
sites are not implementing anti-XSS correctly, and many users use simple
and consistent password on every service they use. So I think we should
still make those APIs unforgeable.
…On Fri, Mar 10, 2017 at 10:37 PM Mike West ***@***.***> wrote:
I understand the concern, however, consider is the behavior of
password-managing extensions. I think it's important that programs like
LastPass, 1Password, etc, be able to interject themselves between the site
and the browser. That's their whole point.
If we make store and get unforgeable, then we're locking those out of the
process, which seems bad.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#63 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFA6WH7QDvTz1cJODduuREqjPlK96nbHks5rkkEbgaJpZM4MaBkA>
.
|
Looking at this again, it's not at all clear to me what an attacker would actually gain by overriding Can you help me understand an attack scenario that |
Yeah makes sense. I missed the point that password is a private property in
native code. Let's close this. (Close #63)
On Mon, Mar 13, 2017 at 1:08 AM Mike West <notifications@github.com> wrote:
Looking at this again, it's not at all clear to me what an attacker would
actually gain by overriding store or get. get's arguments don't reveal any
interesting credential information (e.g. { password: true }), and store
gets a PasswordCredential object, but that object doesn't expose the
password field to JavaScript. Really, the attacker would need to override
the PasswordCredential constructor entirely. If they can do that, they can
just read the data out of the DOM at the time it's used to construct the
credential.
Can you help me understand an attack scenario that store and get
specifically enable?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#63 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFA6WLwDn8JPQkbm_vR0YKwL6xK3hSNQks5rlPlmgaJpZM4MaBkA>
.
|
Great! |
I propose the following changes.
This is doable, just like the non overridable
location.origin
. Ignoring this feature imposes users to the leak of personal credentials due to poor security implementations.I also want to point out strongly that we at least say user agents MAY implement this feature.
The text was updated successfully, but these errors were encountered: