New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 674105 link

Starred by 0 users
Status: WontFix
Owner:
█ vabr@chromium.org
hobby only
Closed: Dec 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Cross filling passwords on a broken HTTPS site (llvm.org)

Project Member Reported by vabr@chromium.org, Dec 14 2016 
This is a security issue with filling passwords.

What happened:

* Long time ago, the user stored their username/password pair for llvm.org/bugs both on HTTP and HTTPS version of that site.
* If the user visits chrome://settings/passwords, they only see one entry for llvm.org, associated with the HTTP URL.
* Today, the user visited https://llvm.org/bugs, but Chrome signals red flags: "Your connection to this site is not secure. You should not enter any [...] passwords [...]". Yet at the same time, Chrome fills the HTTPS credentials it stored into this broken HTTPS page.

There are two issues:
(1) Chrome does not show that the user has a HTTPS credential saved at all.
(2) Chrome warns the user against entering passwords in a site, yet at the same time Chrome autofills the saved password.
llvm_bugzilla.png
21.4 KB View Download
llvm_password_internals.txt
3.8 KB View Download

Comment 1 by vabr@chromium.org, Dec 14 2016 

So fortunately, the cross-origin filling is not happening. The user (I) has both versions (HTTP and HTTPS) of the credential stored. I found out by looking into my Gnome Keyring directly. passwords.google.com also indicates the two origins, despite grouping them in one entry. The native chrome://settings/passwords group them without even showing all of them, picking the HTTP one as a random representative. This is certainly a bug, will change the description to mention it. The respective code seems to make an effort to differentiate [1], not sure what is wrong.

As for (2), the attached internals log shows that ChromePasswordManagerClient::DidLastPageLoadEncounterSSLErrors did not understand that the page has issues. Need to investigate that as well.

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/passwords/password_manager_presenter.cc?q=passwordmanagerpresenter&sq=package:chromium&dr=CSs&l=107

Comment 2 by vabr@chromium.org, Dec 14 2016

Description: Show this description

Comment 3 by vabr@chromium.org, Dec 14 2016

Owner: vabr@chromium.org
Status: Assigned (was: Available)
I forgot to say the above was encountered with Chrome 55.0.2883.87. 56+ seems to be better at preventing users to go to that page at all, which may at least mitigate the issue. I will investigate further.

Comment 4 by vabr@chromium.org, Dec 14 2016

Status: WontFix (was: Assigned)
On 57.0.2952.0, ChromePasswordManagerClient::DidLastPageLoadEncounterSSLErrors understands already that the SSL status is bad and refuses to fill anything.

That might be related to the fact that on 57, unlike 55, the user needs to click through the "unsafe HTTPS" interstitial. Not sure if the situation from 55 is reproducible on other pages in 57. The password manager uses net::IsCertStatusError to check whether to fill/save or not, which seems like the appropriate solution.

As for (1), this is actually  bug 658981 , and has been fixed since (works fine in 57).

Phew.

Comment 5 by rsleevi@chromium.org, Dec 14 2016 

For 55, SHA-1 only affected the omnibox UI's representation of secure - for purposes of autofill and features, the page was considered secure. This was part of a multi-release signal that ...

For 56, the page would not be treated as secure and require a click through.

Comment 6 by vabr@chromium.org, Dec 15 2016 

Thanks for the clarification in #5! Glad to hear that this was just a transitional state.
►

Sign in to add a comment