Open Bug 616619 Opened 14 years ago Updated 2 months ago

Autocomplete allows sites to see what other sites a user has visited and possible data as well

Categories

(Toolkit :: Form Manager, defect)

defect

Tracking

()

People

(Reporter: reed, Unassigned, NeedInfo)

Details

(Keywords: privacy, sec-low, Whiteboard: [sg:low][affects other browsers])

Joe Calandrino, Will Clarkson, and Ed Felten of the Princeton CS department sent the following vulnerability report to security@:

================================================================================

We recently discovered a vulnerability allowing a limited form of 
history stealing in Firefox 3.6, and we are contacting you to provide 
advance notice of this vulnerability prior to public disclosure.  The 
vulnerability is based on auto-complete functionality.  The behavior of 
auto-complete depends on which sites a user has interacted with 
previously.  By monitoring the use of auto-complete, a malicious site 
can infer browsing history across other sites.

When a user submits data in a text field, the browser stores the data 
typically indexed by the name of the field.  For example, if you enter 
"Smith" in a field named "lastname" on example.com, the browser stores 
the pair ("lastname", "Smith").  As the user completes text fields in 
the future, the browser retrieves text that the user entered into fields 
with the same name---even on other sites---and suggests these as 
auto-complete options.  We locate a text field name that is highly 
distinguishing for a targeted site and attempt to infer the presence of 
form history corresponding to that name.

Among many other sites, Facebook, MySpace, Progressive, and WebMD 
include email address or user name entry fields with relatively unique 
names.  Based on the assumption that users are likely to reuse user 
names or email addresses across sites, we created a demo page containing 
text fields with the same names as on the target sites.  Using 
JavaScript to monitor user actions and changes in the contents of these 
fields, we infer when auto-complete is used.  The use of auto-complete 
suggests that the user previously interacted with the target site (we 
also learn what the user entered on the target site, which may be useful).

We are preparing to release our results but are willing to delay 
disclosure for a reasonable period if you intend to fix this issue 
promptly.  We are also open to discussing mitigation strategies and 
would be happy to provide additional details.
Component: Autocomplete → Form Manager
QA Contact: autocomplete → form.manager
Version: 1.9.2 Branch → unspecified
Whiteboard: [affects other browsers, so keep private]
A temporary password-protected demo site is available here:
http://www.cs.princeton.edu/~jcalandr/demo/autoCompleteStealing.html
Username:  demo
Password:  Ih3Fn.7&C
As explained on the demo site, we assume that you use the keyboard to select auto-complete data.  Additional event handling would make the demo attacks more powerful.

We've spent a bit of time thinking about mitigation.  One approach is to tag information based on its origin---as determined by the same-origin policy---and only share data appearing in some minimum number of origins.  When the user enters information into a field with the same name at the n-th origin, the browser could add the data to a common cross-origin information card (potentially asking the user first).  Data on this information card could be used on any site, regardless of origin.  This would allow auto-complete both on the same site and for common fields on other sites, which are two cases in which auto-complete is really helpful.  Safari does something similar, tagging data by domain, but data is never shared across domains and is shared in a manner inconsistent with the same-origin policy.
Given the more serious bug 381681, I think we should make form autocomplete be same-origin-only, and NOT create exceptions for data that has been entered on multiple sites.
Whiteboard: [affects other browsers, so keep private] → [sg:low][affects other browsers, so keep private]
If partitioning rather than the UI is used to protect against issues like <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=381681">bug 381681</a>, then I agree that cross-origin sharing would be an issue.  Solving that issue seems to require balancing the drawbacks of eliminating cross-origin autocomplete against the drawbacks of UI changes like <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=188285#c90">bug 188285 comment 90</a>, option 2.  The proper choice is unclear to me, though eliminating cross-origin autocomplete seems a bit drastic without obtaining usage information.  Given your work with these related issues, perhaps you have more data or intuition about this than I do?

Fortunately, fixing this new problem appears feasible without completely disabling cross-origin autocomplete.  Using the multiple-origin proposal above with user consent (which admittedly might be hard to obtain in a meaningful, non-annoying manner) or sharing only whitelisted fields across origins both may be sufficient here.
Group: core-security → toolkit-core-security
Group: toolkit-core-security → firefox-core-security

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sgalich)
Keywords: keep-hidden

There is no need to keep it hidden

Group: firefox-core-security
Flags: needinfo?(sgalich)
Keywords: keep-hidden
Whiteboard: [sg:low][affects other browsers, so keep private] → [sg:low][affects other browsers]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sgalich)
You need to log in before you can comment on or make changes to this bug.