Jesse Ruderman Reporter
	Description • 17 years ago

An evil site can get form autocomplete data with some user interaction.  The interaction can be a keyboard-based game that does not appear to involve forms (see attachment).

The attacking site has to know the name of a form field that you've used, but that doesn't provide much protection.  It wouldn't be hard for an attacker to visit 20 major sites and note the field name for each credit card field that doesn't use autocomplete="off".  The site can try multiple field names without you noticing the attack.

Possible solutions include:
A) Make form autocomplete be per-(hostname, port, protocol) or per-(domain, protocol).
B) Avoid storing credit card numbers using a heuristic (bug 188285).
C) Default to autocomplete="off" for https sites (bug 190700).

I think I prefer (A).

	Justin Dolske [:Dolske]
	Comment 1 • 16 years ago

Hmm. Option A would fix the problem, but really limits the general usefulness of form history. It's an even more painful limitation if we should ever want to expand the scope of what's offered in the autocomplete, beyond keying off the field name (eg, something awesomebar-like).

I seems like when you're interacting with the autocomplete menu, you're really interacting with chrome and thus (1) key/mouse events should not be dispatched to content and (2) untrusted key/mouse events should be ignored (if they're not already). That would probably help make this kind of evilness more difficult to do in the background, but I'm not sure you could ever prevent variations of things like simply prompting the user with "on the count of three, press down-down-right as fast as you can to win a prize!".

	Jesse Ruderman Reporter
	Comment 2 • 15 years ago

Bug 188285 comment 62 reveals this bug, more or less.

	Kieran Clancy
	Comment 3 • 15 years ago

Jesse, I think it's not just keyboard games which could be used to exploit this. Consider image galleries, "web 2.0" data entry tool or other webapps, etc.

Obviously games are one way which guarantee a fairly steady stream of unaware users, but I think where this would be exploited if anywhere would be on adult image galleries. Some users will happily venture onto dodgy sites in search of free pornography, and if people have to press down down right to get to the next image, they'll do it.

	Michal Zalewski
	Comment 4 • 14 years ago

I added a note with my thoughts to that bug (actually, should probably have gone into this one instead, my bad):

https://bugzilla.mozilla.org/show_bug.cgi?id=188285#c90

	Kieran Clancy
	Comment 5 • 14 years ago

Michal, I have come to agree with you that actually any leakage of autocomplete data should be treated as serious.

I think it's good to discuss possible UI changes (as you do) that would separate the chrome and the content (as Justin put it).

However, the more I think about it, the more I think that just making autocomplete be per-(domain, protocol) is the proper solution.

It would be great if we could get some real data on how autocomplete is used in the real world.

In my experience, I have noticed the following things:

1) I am a heavy online shopper, but I probably don't put my contact details into more than 10 different websites a year (because I use the same 10 websites for 99% of my shopping). Some websites I may put my details in repeatedly (and could use (per-domain) autocomplete), other websites already save my information. Making autocomplete per-domain probably wouldn't inconvenience me that much.

2) Websites use a wide range of input names to refer to the same thing (e.g. addr, address, forminput32 etc). This already means there's a very good chance I cannot re-use autocomplete data from one domain on another domain. Users are probably already accustomed to this, and may not even notice if we change autocomplete to be per-domain.

3) Many websites use the same input name to refer to different things. For example, 'phone' might mean mobile or work phone, and websites usually want these kinds of things in different formats. That is, some websites want me to put a country or area code at the front, other websites may have a separate part of the form for that. Same goes for address fields where some websites put the whole address in one input and others separate the street/number, town name, postal code, state, country. This means that a lot of the time, cross-domain autocomplete is not even helpful.

There are other reasons to make autocomplete data per-domain. If someone goes into their History and right-clicks on an entry and says "Forget this website", then we'd want to remove any autocomplete data made on that website. Moreover, deleting just a single entry from the history ought to remove any new autocomplete data stored from that visit.

For ease of discussion, I'll quote your comment here:
> I'm late to the party (blame Jesse for cc:ing me ;-), but I think there is an
> important disconnect between the PoC in comment 62, and the current sentiment
> in the bug (blocking valid credit card numbers).
> 
> If you accept the premise of autocomplete, preventing autocomplete of credit
> card numbers specifically should not be browser's business. Given the types of
> information that autocomplete picks up, there is nothing special about credit
> cards: social security numbers, bank account numbers, DL numbers, national ID
> numbers in a variety of countries, can be equally sensitive (e.g., can be
> abused to obtain credit, forge checks, authorize wire transfers, and so forth). 
> 
> In fact, the impact of leaking many of these is far more serious, because there
> is a limited liability for unauthorized CC transactions, and the ease of
> replacing them; but if your SSN is leaked, you will be in long-lasting trouble.
> I can practically guarantee you will see a request to filter out SSNs in the
> future, on the same grounds.
> 
> Critically, though, autocompletion of these long numbers and perhaps your home
> address and e-mail address (which I also don't want to accidentally give out to
> random websites, by the way), are probably the most important reasons why
> people use autocomplete in the first place, right? If so, then blacklisting all
> of the sensitive stuff means you are essentially sort of giving up on the
> mechanism.
> 
> I have two radical thoughts that I am pretty sure will not be liked, but I feel
> obliged to mention them here anyway (and then shut up):
> 
> 1) If you are determined to follow the path of blacklisting all the sensitive
> stuff, maybe you should scale back to an explicit mechanism that scratches
> specific use cases that still remain on the table (because of an acceptable
> risk in the current "hijackable" design). Say, allow the user to enter his
> contact information in a configuration dialog, and only autocomplete using this
> data?
> 
> 2) If you do not want to scale back - then, in light of comment 62, it would
> seem necessary to alter the user-friendly but unsafe behavior of autocomplete,
> so that we do not end up leaking random bits of accidentally amassed sensitive
> information to third-party websites. The two obvious solutions is requiring a
> more explicit / unlikely gesture for autocomplete to kick in on a page; or
> having a UI solution that, for example, ensures that autocomplete drop-downs
> are always shown on top of any other DOM, and get a certain amount of
> uninterrupted screen time before a choice can be made.
> 
> /mz

	Jesse Ruderman Reporter
	Comment 6 • 13 years ago

Changed to use addEventListener.

	Jesse Ruderman Reporter
	Comment 7 • 13 years ago

This issue was discovered independently and is now public:

http://blog.mindedsecurity.com/2011/10/autocompleteagain.html

	[:Aleksej]
	Comment 8 • 11 years ago

Reproduced with 2014-02-18-03-02-02-mozilla-central-firefox-30.0a1.ru.linux-x86_64: http://www.linux.org.ru/search.jsp and https://input.mozilla.org/ share autocompletion.