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

Issue metadata

Status: Fixed
Owner:
50% in 2018
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug



Sign in to add a comment

Security: Overzealous password autocomplete unmasks Incognito users

Project Member Reported by elawrence@chromium.org, Aug 10 2016

Issue description

VULNERABILITY DETAILS
Google Chrome's password autofill can take place automatically even while Incognito, allowing a website to correlate a user's Incognito activity with their non-Incognito activity.

This is a variant of the issue IE had a for a short period: http://webdbg.com/ie/InPrivateInfoDisc.htm

VERSION
Chrome Version: Version 54.0.2825.0 canary (64-bit)
Operating System: Windows 7

REPRODUCTION CASE
1. Outside of Incognito, in a non-corp account that allows SmartLock password autofill, visit https://whytls.com/password.htm. 
2. Enter a password and submit the form.
3. Elect to save the password.

4. Close the browser and open a new Incognito instance.
5. Visit https://whytls.com/password.htm. 
6. Click anywhere outside of the autofill box.

OBSERVE: Password field autofills.
 

Comment 1 by och...@chromium.org, Aug 10 2016

Cc: vabr@chromium.org vasi...@chromium.org
Components: UI>Browser>Incognito Privacy
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Restrict-View-Google Type-Bug
+some privacy folks, and flipping labels.

s/RVST/RVG/ just in case.

Comment 2 by vabr@chromium.org, Aug 11 2016

Cc: -vabr@chromium.org
Labels: Hotlist-Polish OS-Linux Pri-2
Owner: vabr@chromium.org
Status: Started (was: Unconfirmed)
Oops, this is a bug, and I can also reproduce on Linux. Thankfully it is not the case on every website (e.g., rsolomakhin.github.io/autofill/ works fine), but still a bug.

Looking into it.

Comment 3 by vabr@chromium.org, Aug 11 2016

PasswordAutofillAgent::TextFieldDidEndEditing feels the need to fill the current password field in cases when the "don't autofill" flag is on. This causes the observed bug.

I'm looking further into the code to understand why PasswordAutofillAgent::TextFieldDidEndEditing behaves in this way.

Comment 4 by vabr@chromium.org, Aug 11 2016

Cc: dvadym@chromium.org
The code there is to allow filling after the user typed the username without actually selecting suggestions. It is unclear why this only happens in the case when Chrome decides against autofilling. The behaviour has been there since porting from WebKit in 2010 https://chromium.googlesource.com/chromium/src/+/03f57072cd19125c59fbc1d7c76f2856ca200850.

It is unclear what this behaviour's benefits are. It even seems like contraproductive in cases when the user tries to type in their username without using suggestions to prevent autofilling. Getting rid of this code would make PasswordAutofillAgent simpler again, in addition to fixing this bug. I spoke to dvadym@, and it looks like a good idea to us to remove the code. I will give heads-up about this on today's team meeting as well.
Able to reproduce the issue with https://whytls.com/password.htm on mac win and Linux using chrome version 52.0.2743.116 and canary 54.0.2826.0

This is working fine with rsolomakhin.github.io/autofill/

Comment 6 by vabr@chromium.org, Aug 11 2016

Uploaded https://codereview.chromium.org/2236413002, waiting for bots to turn green before sending out for review.
Project Member

Comment 7 by bugdroid1@chromium.org, Aug 11 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/36c4ef576660b52e1a5750b313ae3031ea1b4e81

commit 36c4ef576660b52e1a5750b313ae3031ea1b4e81
Author: vabr <vabr@chromium.org>
Date: Thu Aug 11 15:22:50 2016

Remove PasswordAutofillAgent::TextFieldDidEndEditing

PasswordAutofillAgent::TextFieldDidEndEditing provided special handling for
situations when automatic filling was blocked (Incognito, PSL-matched
credentials, etc.): in those cases, when the user filled the username to match
some of the fillable credentials, that credential was filled even though the
user did not select a fill suggestion.

It is no longer clear what was the motivation for this behaviour. The code has
been like this before it was ported from WebKit in 2010. It seems unnecessary,
a little unexpected, and leads to a bug when a page can trigger autofill of
credentials with empty usernames in cases where they should not be autofilled
(e.g., Incognito).

Therefore, this CL removes PasswordAutofillAgent::TextFieldDidEndEditing and
the associated functionality: credentials are now only filled when the user
selects a suggestion (or when the credentials are fit for automatic filling).

R=dvadym@chromium.org
BUG= 636461 

Review-Url: https://codereview.chromium.org/2236413002
Cr-Commit-Position: refs/heads/master@{#411335}

[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/components/autofill/content/renderer/autofill_agent.cc
[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/36c4ef576660b52e1a5750b313ae3031ea1b4e81/components/autofill/content/renderer/password_autofill_agent.h

Comment 8 by vabr@chromium.org, Aug 11 2016

Status: Fixed (was: Started)
elawrence@, can we lift the view restriction?
Labels: -Restrict-View-Google
Sure, done.

Sign in to add a comment