Username value revealed to JavaScript on back navigation |
||||||
Issue descriptionChrome Version: 65.0.3325.0 OS Version: Windows 10.0, Android 8.1 What steps will reproduce the problem? 1. Visit https://bayden.com/test/password/gatekeeper.asp and submit a username/password combination. Elect to store the password. 2. Revisit https://bayden.com/test/password/gatekeeper.asp 3. Observe: Username and Password fill but are not shown in the green bar (which polls the input fields for their value via JavaScript) 4. Click the "Goto example.com" link. Observe: Username and password appear in the green bar before navigation, due to the link click being a user gesture. 5. Click Back. OBSERVE: Username value remains exposed to JavaScript but Password value does not. What is the expected result? Neither username or password value exposed until a user-gesture.
,
Jan 23 2018
,
Jan 23 2018
Able to reproduce the issue on reported chrome version 65.0.3325.0 and on the latest chrome version 66.0.3329.0 using Windows 10, Ubuntu 14.04 and Mac 10.12.6. As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking it as Untriaged. Thanks!
,
Jan 23 2018
,
Jan 23 2018
,
Jan 23 2018
Re #4: It's true that this repros in prior versions, but the feature that masks the username value didn't land until M65 in Issue 798492.
,
Jan 24 2018
I found why it works it this way. 1.When the user clicks on a link, then username/password are revealed for to JS (because of user action). 2.On back navigation the DOM that was before the link clicked is restored, including input elements values, excluding <input type=password> fields. So usernames are restored. So it has nothing to do with Password Manager. On other hand, if there was no user gesture, username is not revealed to JS after navigation back, since it had not been part of DOM. Anyway showing username after back navigation doesn't make things worse, since the username was revealed after link clicked, so JS can save username before navigation. So I'm inclined to close this bug as WontFix. elawrence@ WDYT?
,
Jan 25 2018
RE #8: Interesting. I confirmed that the password isn't revealed after programmatic navigation (e.g. navigate the user forward, then user clicks back) so this shouldn't be useful as an automatic unmasking measure. While it's certainly /possible/ that the "evil" script only gets to run the second time the page loads and thus this issue /could/ matter, this seems pretty unlikely. So yeah, this can probably be WONTFIX.
,
Jan 26 2018
Closing as WontFix according to explanation in #8 |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by elawrence@chromium.org
, Jan 22 2018