Maybe some feedback from the browser detailing which datapoints were autofilled. I don't know...
I'm always concerned about using autofill because browsers eagerly fill any field they have data for.
What is needed is integration with permission granting mechanisms, which already exist in browsers.
There's often sites that are poorly coded, and autofills ends up putting my phone number in some random field and I have to manually delete it.
You first select an identity to use to auto-fill. When doing that, it will tell you the data it will insert in the subtitle.
You can also click customize and choose what data to place into each field.
 - http://imgur.com/a/HL59q
Initially only the input field for e-mail is displayed. There's also a, hidden to the user's eyes, _next step_ with the password field that gets populated if the browser auto-fills it.
This is not terribly difficult, browsers need to know what is visible because they have to actually display it. If an element isn't drawn it shouldn't be autofilled.
So if a form is too long and you need to scroll, all those fields you can't see won't be auto-filled? Sounds pretty terrible IMO.
The solution to this problem is to inform the user which fields will be completed by autofill, with a "not currently shown" highlight on any fields that are currently off the screen so the user understands what's happening.
<div style="font-family: Custom non-printing font 101">
<input type="text" name="address"/>
<input type="text" name="ssn"/>
but is something the browser already does, so it's no extra effort.
This also worked really well with encrypted password storage (if you configured that key was forgotten after e.g. 10 minutes), it did not nag you to enter the password if you visited site where you stored password but did not intended to log in at given time.
There's an add-on for Firefox, but doesn't work as well as it did in Opera, and also it doesn't solve the password nagging issue, but I suppose it could help address the vulnerability mentioned here.
I really don't understand why all browsers insist to handle password this way.
Also, while Opera's wand button filled in both login credentials and common form elements, Chrome's autocomplete is limited to common form elements.
Your second idea about an auto-fill warning would be better. Maybe a simple footer warning or something.
Or massive highlighting around each field
FYI this doesn't work for credit card info, at least not in Chrome. That information has to be auto-filled separately.
But, if the end user doesn't notice or care about the visual cue, you can exploit it. Start typing in a name that has a credit card associated with it in Chrome's autofill: https://jsfiddle.net/hvs4ox2q/4/
If it was you could write a script to automatically post all auto fill data on page load.
Edit: That is, for the purposes of this exploit. I understand it's ugly.
So then you'd need to prompt the users to confirm that they want to auto fill, not just notify that auto fill happened. Otherwise it may already be too late.
Currently, when I trigger autofill in Chrome, it tells me the full suite of information it can input for a certain profile (name, address, company, etc), but it doesn't tell me which bits of information are actually being used. Something as simple as placing checkmarks in this popup next to the information that is actually being used could communicate this better.
Safari does this already
Suppose a form uses a non-standard name for the field (say a localized name), and a user enters it at a legitimate site. Any attacker simply has to find these non-standard names for auto-complete to fill this in.
I feel like I've seen a credit card autofill before outside of normal controls.
Your mileage my vary, but I'd be very surprised if it does.
1) Google Chrome doesn't always explicitly ask for a CCV. If it does, the browser dialog opens.
2) It actually charges $1 per CCV check to verify the credit card.
3) If the CCV check is successful, it does the autofill on the form. However, you still have to enter the CCV in the form manually most of the time.
4) The $1 charge is immediately canceled and thus doesn't affect your account balance.
For reference, here's a screenshot of how my bank receives such a charge: http://imgur.com/qwdM9Jx.png
To be clear, this is not from any Google purchase. That's what happens if I use my CC in Chrome on any site.
It also has to be noted that this implementation is pretty bad. On pre-paid CC (i.e. your CC payments are directly tied to your bank account - there is no CC bill), this will negatively impact your spending balance:
Account balance: All your money.
Spending balance: (account balance) - (pending charges)
Some banks refuse to apply the charge cancellation sent by Google and keep the pending charge active for some fixed amount of time (e.g. 90 days).
Assuming that's correct, it really wouldn't take up much memory or computing power to create a lookup table for every credit card number with hash x.
You might catch some careless people with it though: https://jsfiddle.net/hvs4ox2q/4/
This is one of the many examples where a privacy-first approach pays off not just in terms of privacy but also in terms of security. In Germany we use the term "Datensparsamkeit" for this principle. Not sure if there is a well-established english term in the international community.
So why do other browers fill in these fields automatically? Why don't they wait until asked by the user? Because it is more "convenient" for the user? Moreover who benefits from that? Not the users, not the browser vendors, but all those websites with overly long registration forms. These confront their visitors with lots of irrelevant fields (birthday, gender, etc.) just for the sake of collecting data. Nobody would fill all that in voluntarily, but I guess more people will do so (perhaps accidentally) if their browser fills that in by default.
But Safari does it in the most elegant way. They show a popup with all the information that will be autofilled and ask you to confirm before filling out the fields which also protects against AJAXified submissions.
I saw this example doing the rounds on twitter. Hopefully the chrome devs notice the noise and move up the priority on fixing / addressing it.
Browsers auto-guessing private data into arbitrary fields on never-before-used webpages?
IMO that's "Just because you can doesn't mean you should" territory.
Sensitive info belongs to a password manager which limits it to the domains the data belong.
Credit card numbers are a pain, though. I could put them to a password manager, and manually select to fill only that particular field when I need to. In reality I rarely buy things where PayPal or Amazon payment options are not available; I suppose Stripe offers a similar service.
So all that stands between you and being in this exact situation (or worse, since passwords) is your password manager's url comparison?
I refuse to use LastPass - the interface is horrible (probably because you're expected to use the browser extension). But I don't want my password manager anywhere near my browser. I'd really rather have to take an affirmative action in order to release each individual piece of information so I know what I'm disclosing and to who.
your password manager's url comparison?
A password manager running outside my browser and only communicating the bare minimum required by a page, after checking its certificate, sound like a good idea. LastPass is almost there; the only reservation is that it's not run on a machine controlled by you. Other similar solutions overcome this limitation.
A browser extension is actually a great approach, too: it can and should be open-source and signed, thus reasonably tamper-proof. It should, again, do the bare minimum regarding the communication with the actual password store. Its usefulness is mostly in discovering the mapping between form controls and info to be stored.
Chrome (and I assume others) has a secure credit card and password auto-fill, separate from regular form auto-fill.
I think this means browsers will never fix this issue. I won't be using auto-fill on untrusted webaites.
As other comments have noted, it isn't trivial to fix completely, so I believe most browsers just haven't bothered at all, but have implemented some extra protection for credit cards (and of course, CVV numbers are never stored in the first place).
I do believe it would still fail exposing your basic info, such as in this example, however.
However, a lot of users might not have that conscience and might be giving out information which they didn't want to. It would be great to shame websites that were employing these shady techniques, but the solution must come from Chrome. Chrome devs: by default only auto fill one field and on the drop down have as the last option to do what you do now, so that you're sure that the user has consciously chosen to auto fill all fields * have a little disclaimer saying this possibility *. That way you get the best of both worlds with an extra key down
They should probably have private: true in there though, to stop it getting published by mistake, since it isn't a component anyone could usefully import.
Chrome was shown to be vulnerable like 7 years ago but nothing changed.
Closed source stuff like MSIE or Safari? No idea, ask a Windows os OS X user.
I think I remembered of that because the direction of though that autocomplete should always be enabled appears as wrong to me. And this situation reminded me of this direction of though in the past case.
However, I always found it odd how something so prone to this kind of attack could be deployed for all non-tech savvy browser users...
I was trying to create a honeypot for a front-facing web form, but because of the name I gave the honeypot field, some people's autofill information was filling out that field without them knowing.
Besides, someone using this for a phishing method wouldn't use that attribute anyway.
This is a nice example of a feature that is trivially accessible and yet unobtrusive.
(Alternatively, you can press the down-arrow on the empty field, which will open the auto-completion as well.)
IMO, much better way, since it works well in situation where your passwords are encrypted and browser is configured to forget master key after a while.
Firefox in that scenario will bug you about master password each time you go to page where such password is stored.