Prevent a site from injecting fake passwords to save |
|||||
Issue descriptionThe following attack seems to have been made easier by the Credential Manager API: 1. A user visits example.com and logs in. 2. The attacker has temporary control over that page, and changes the saved password to a value known to the attacker. 3. Chrome saves the compromised password and keeps filling it for that user. As a result, the stays unaware of the attacker's ability to access their account, which persists even after the attacker loses the control over example.com. The Credential Manager API makes this easier in 2 ways: (A) The website supplies the password to be stored through the API. (B) The API also allows silent updating of already saved credentials. This attack may potentially also happen with the old password manager, but it is less likely, because: (A') The password manager does its best to ignore the site's modifications to the password field value. Ideally, whatever the user typed into the password field is what Chrome saves, JavaScript-based modifications of the value are disregarded. (B') Updating of a stored password is no longer silent, it triggers a confirmation bubble. To address this issue, we may consider two changes: (i) Add the ability to view the password in the confirmation prompt for saving/updating. (ii) Change the behaviour of the Credential Manager API to also prompt on updating. Adding mkwst@ and jww@ in Cc, because they are the API author and security reviewer, respectively. I already briefly chatted with mkwst about this, and would be interested in the view of both of you on how important this issue is and suggestions about fixing it. I keep the visibility restricted, because I'm unsure. If you think this is fit to be public, feel free to remove the restriction.
,
Mar 15 2016
As usual, I'm confused ;-) Regarding (b), I thought that if the credentials updated, it would prompt the user regarding the update? If not, why not? It seems like that would be a simple enough way to mediate this problem, and it also applies the "principle of least surprise" (e.g. if I'm credentials were updated silently by a site, I'd find that shocking, to say the least). I'm not so worried about this as an attack, per se, but as a usability issue, which could cause mistrust in the password manager/Smart Lock, which is a security issue.
,
Mar 15 2016
Sorry, I *do* think it is a pretty serious attack to worry about as well :-) A simple XSS, it seems, would allow a user to persistently attack the login state of a user, which can have really nasty consequences, and is a big privilege escalation. I believe the CM API UX should be *at least* as good as the Password Manager UX, which, as you mentioned, at least alerts the user of an update so they can react if this was unexpected.
,
Mar 16 2016
I can confirm that the CM API-triggered updates do not currently pop up any bubble. At the point this was implemented, that was how the normal password manager behaved (in fact, this is how it still behaves on mobile, IIRC, we are in the process of enabling the update UI everywhere). I vaguely remember that there was a reason to support the silent updates in the API, but I don't remember what it was -- perhaps mkwst@ or sabineb@ know? Or someone on the document comment with Adam Dawes I Cc-ed you into.
,
May 31 2016
,
Jun 7 2016
After a round of discussion with the password manager team, I realised I could not construct the attack so that the attacker would be able to create the account with the updated password without involving a step where the attacker would be able to actually steal the original password as well.
,
Sep 13 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 29
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by vabr@chromium.org
, Mar 14 2016