Skip to content
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

Closed
tjwudi opened this issue Mar 11, 2017 · 5 comments
Closed

User agent should/may not allow overriding "store" and "get" #63

tjwudi opened this issue Mar 11, 2017 · 5 comments

Comments

@tjwudi
Copy link

@tjwudi tjwudi commented Mar 11, 2017

If a malicious party is able to inject script into an origin, they could (among many other things you wouldn’t like) overwrite the behavior of store() to steal a user’s credentials as they’re written into the credential store.

I propose the following changes.

User agents *MAY*/*MUST* prevent overriding following methods.

- navigator.credentials.store
- navigator.credentials.get

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.

@mikewest
Copy link
Member

@mikewest mikewest commented Mar 11, 2017

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.

@tjwudi
Copy link
Author

@tjwudi tjwudi commented Mar 11, 2017

@mikewest
Copy link
Member

@mikewest mikewest commented Mar 13, 2017

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?

@tjwudi
Copy link
Author

@tjwudi tjwudi commented Mar 14, 2017

@mikewest
Copy link
Member

@mikewest mikewest commented Mar 14, 2017

Great!

@mikewest mikewest closed this Mar 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.