Chrome does not block saving credentials via HTTP if some credentials are saved via HTTPS on the same host
Reported by
komis...@yandex-team.ru,
Sep 26
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3563.0 Safari/537.36 Steps to reproduce the problem: Let example.com/login be a password form available via both HTTP and HTTPS. 1. Enter and save some credentials on https://example.com/login. 2. Enter and save another credentials on any form with a different host. 3. Enter another credentials on http://example.com/login. What is the expected behavior? Chrome does not offer to save the credentials for http://example.com/login. What went wrong? Chrome does offer to save the credentials for http://example.com/login. Did this work before? N/A Chrome version: 71.0.3563.0 Channel: n/a OS Version: OS X 10.13.6 Flash Version: Related to crbug.com/571580 (see last comment).
,
Sep 26
,
Sep 27
+vasilii who thought about these cases recently.
,
Sep 27
My understanding of the intended behavior is that Chrome offers to save the credentials for http://example.com/login but does not allow to override them for https://example.com/login.
,
Sep 27
I don't follow why Chrome should not offer to save the password on http://example.com. If the site is fully migrated to HTTPS they should use HSTS flag to prevent the http version from being loaded. If the http version of the site is available it can be a "Man in the middle" attack of course. However, most likely it's the same site that wasn't fully migrated. We don't want to break the valid user flow in such a case.
,
Sep 27
The problem is an inconsistency. If we exclude step 2, Chrome will not offer to save the credentials even as new ones (such behavior was proposed at crbug.com/571580 ). But if we save some credentials on another host or just restart Chrome, the behavior will differ. I suppose that both cases should lead to the same behavior.
,
Sep 27
Ahh, I remember that "feature". It came from the security team many years ago. Jan, as an owner of the CL (https://codereview.chromium.org/2607413003/), can you ask the security team if we could drop it? If so, let's do it. |
||||
►
Sign in to add a comment |
||||
Comment 1 by vamshi.kommuri@chromium.org
, Sep 26