I wrote about this a while ago: https://medium.com/@stabbles/why-you-should-disable-autofill...
haha, I guess I also reinvented the wheel a few months later :)
http://www.phpied.com/oversharing-with-the-browsers-autofill...
Browser auto-fill phishing
81–90 of 150 posts
Re: Browser auto-fill phishing
#82Wow, great demonstration. I'd never thought about this being exploited. I wonder if the fix could be something as simple as the browser only allowing non-hidden [Edit: "not visible to the user", I should have said, as this does not appear to auto-fill ] fields to be auto-filled. Otherwise, a warning about what auto-fill information (IE "Your name and credit card information are going to be submitted, continue?") has…
The elements are not hidden, they are just drawn off the screen. So the browser would have to determine if the item is visible to the user, which is not trivial. Should autofill skip regular form elements that are just a little below the viewport? Maybe some feedback from the browser detailing which datapoints were autofilled. I don't know...
>> which is not trivial
but is something the browser already does, so it's no extra effort.
Re: Browser auto-fill phishing
#83Wow, this seems like such an obvious attack vector that I just assumed it was somehow mitigated (somewhere, magically, I suppose). Does it even require the user to press the Submit button, i.e. could the site's JS trigger the POST request after the event of the autofill?
No need for a submit click. Presumably auto-fill triggers a change event on each affected input, but even if it didn't, an attacker could just repeatedly check for new content in the inputs. This means an optimistic solution (autofilling and then unobtrusively notifying the user what was autofilled) is not viable.
I don't think it does trigger a change for exactly this reason. I tried to build a Material login page a couple years back, where the placeholder became the label when you typed. I couldn't get it to work with autofill, because I couldn't find a vector to detect when autofill had happened. Here's a related issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=352527
Re: Browser auto-fill phishing
#84Wow, great demonstration. I'd never thought about this being exploited. I wonder if the fix could be something as simple as the browser only allowing non-hidden [Edit: "not visible to the user", I should have said, as this does not appear to auto-fill ] fields to be auto-filled. Otherwise, a warning about what auto-fill information (IE "Your name and credit card information are going to be submitted, continue?") has…
I liked the old Opera approach to this. By default it did not fill the fields, unless you clicked on a Wand button, or used Ctrl+Enter shortcut. 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-…
Chrome doesn't fill in the fields by default either. The issue is what the autocomplete tool does after it has been activated, not how it's activated.
Also, while Opera's wand button filled in both login credentials and common form elements, Chrome's autocomplete is limited to common form elements.
Re: Browser auto-fill phishing
#85This could be solved by improving the autofill UI to tell you all the data it is filling into the form, even if it isn't visible to you.
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.
Re: Browser auto-fill phishing
#86Earlier quoted context omitted.
Last time I autofilled a CC with chrome it asked me to input the cvv number on the card before it filled in.
Interesting use of CVV, since vendors aren't permitted to store it. But Chrome does, for you... is that synced across browsers? That would require Google to store the CVV on its servers...
My understanding was that Google doesn't store your CVV anywhere, which is why you need to enter it every time. When you do so, it attempts to charge you zero units of your preferred currency (or perhaps it gives you zero, not sure) and if the transaction succeeds it accepts the CVV as valid.
Re: Browser auto-fill phishing
#87Earlier quoted context omitted.
> 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.
To me (as a non autofill user), the published bug sounds way more harmful than a little inconvenience.
It's not just an inconvenience – it's broken and unexpected UI behaviour.
Re: Browser auto-fill phishing
#88This is the reason I never use the autofill beyond more than at typechecker. I still explicitly write out what I want to place in the form, and the autofill helps me avoid typos.
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...
Re: Browser auto-fill phishing
#89It even works in incognito mode (Chrome 55.0.2883.87 on Windows 8.1; tested against my bank's website).
Re: Browser auto-fill phishing
#90In case anyone is worried, most (all?) browsers do not autofill credit card information without the user explicitly clicking into the credit card field so there's no chance of a hidden field stealing your CC information.
This requires the browser to recognize it as a credit card field. 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.
But then the browser won't autofill it, so what's the problem?