[aesthetics1]

Wow, 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 <input type="hidden"> ] 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 been filled in would be a nice touch. Maybe a browser extension could accomplish this?

[athenot]

The <input> 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...

[theGimp]

My thinking is the user should explicitly autofill each field. Yes, it involves more work, but it's really not much work to click on a field and pick the right autofill value.

I'm always concerned about using autofill because browsers eagerly fill any field they have data for.

[Rumudiez]

This is how Firefox's autofill worked for me just now. Glad to see some more justification for getting off the Google train!

[hashhar]

Firefox works that way and is in my view a much saner default. The best solution used to be in Opera long ago where they showed a little dropdown with the information that was going to be autofilled. You could accept it or deny it.

[circular_logic]

That sounds like a fantastic idea for an extention.

[sytelus]

That would be super bad user experience. Simple and better alternative would be to show everything being auto filled in page in a browser dialog and confirm from user before actually auto filling it.

[jaxomlotus]

Another method would be to show a user a list of all fields that are about to be filled in as part of the autocomplete prompt. This isn't very scalable for massive forms, but should be enough of an alert to a user that something is amiss on screen to make up for those cases.

[ycmbntrthrwaway]

You can scale it by classifying fields into groups. Then user can decide gradually if he wants to share his name. Later, application may ask for location (browsers can already do this), employer info, contact data etc.

What is needed is integration with permission granting mechanisms, which already exist in browsers.

[itissid]

Actually this problem looks is a lot like how Android App permissions are managed. Not long ago some apps used to ask you at install time that they want access to your google email, contacts, wifi and so on. A better app permission model (which I think is now in android) is to ask these "lazily" as the app needs them and let the user decide at that point.

[ehsankia]

I like this best too. All it does is add one more click (when you select the auto fill info, it pops up with all the data and you just approve) and it also solves a lot of wrong fills that can happen.

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.

[kalleboo]

Safari does this already

[eridius]

In Safari, the autofill dropdown explicitly said it would fill "email, work, address" (and I guess it implies that name is included).

[lojack]

How obvious is this to the user? This seems like a detail that'd be easily overlooked.

[IMcD23]

It's quite obvious. Just tried it myself [1].

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.

[1] - http://imgur.com/a/HL59q

[aioprisan]

It's obvious in Safari but not so in Chrome

[alexdoma]

This is exactly how signing in to gmail works if the browser has the credentials of the account saved.

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.

[jonknee]

> So the browser would have to determine if the item is visible to the user, which is not trivial

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.

[choward]

> 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.

[chinathrow]

To me (as a non autofill user), the published bug sounds way more harmful than a little inconvenience.

[elsurudo]

It's not just an inconvenience – it's broken and unexpected UI behaviour.

[Jarwain]

Well why not have it autofill on-draw?

[onion2k]

It'd be easy to move the hidden elements on to the screen when the user clicks the submit button, so they'd be filled in and the form would then be submitted, and the information 'phished'.

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.

[Raphmedia]

Well, then simply make them height:0px or put a <div> with a white background over it. Change the input and make it text-color: white; background-color: white; Change it's z-index to be lower than your other elements, etc.

[robin_reala]

opacity: 0.01;

[vxNsr]

This makes the case that auto fill just ain't that secure, I guess if we use it we just need to accept that.

[thecrazyone]

There's no need to "just accept" that it's not secure. We need to make it secure. This is a tedious/hard problem, yes. IMHO we've (people) solved tougher problems :)

[ris]

  <div style="font-family: Custom non-printing font 101">
    <input type="text" name="address"/>
    <input type="text" name="ssn"/>
  </div>

[matthberg]

Adobe made a font like this, adobe blank: https://github.com/adobe-fonts/adobe-blank

[teddyh]

http://www.catb.org/jargon/html/F/Flyspeck-3.html

[gregable]

Sure, but then the attacker can draw the fields within the 'visible' document, but below the 'fold'. If the browser chooses not to fill fields like that, it breaks a lot of autofill on long pages. Those two cases aren't significantly different.

[alexbecker]

Not necessarily. The browser often paints a much larger area than fits in the viewport, then hands it off to the GPU. (This can be cause performance issues for very tall scrollable pages, which is why I've run into it.)

[ajkjk]

What if another element is drawn in front of it, and though? I feel like there are a huge number of possible tricks to hide elements on page and trick the browser into thinking they're visible.

[PDoyle]

How many pixels does an input need to occupy before it's considered "visible"?

[EJTH]

Problem is that a form might be longer or wider than the viewport, which would result in "hidden" elements in genuine browsers too.

[pc86]

> Should autofill skip regular form elements that are just a little below the viewport?

[fagnerbrack]

It's not trivial but if they do that, then we will be able to finally prevent the browser from autocompleting the fields incorrectly and end this bullsh1t: https://bugs.chromium.org/p/chromium/issues/detail?id=468153

[moron4hire]

>> which is not trivial

but is something the browser already does, so it's no extra effort.

[takeda]

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-on for Firefox[1], 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.

[1] https://addons.mozilla.org/en-US/firefox/addon/secure-login/

[MiddleEndian]

I miss the magic wand so much. It also ignored autocomplete=false. Truly a tool that belonged to the user above all else.

[jamesgeck0]

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.

[alexwebb2]

Only allowing non-(display:none) fields wouldn't be enough. You could still position them off screen, or behind an image, or very small or nearly transparent, or any other sneaky tactic.

Your second idea about an auto-fill warning would be better. Maybe a simple footer warning or something.

[aesthetics1]

I guess I did not think about offscreen or otherwise sneakily positioned form elements. I think the warning is the best way to handle this. I imagine it being something similar to an android permissions popup, where you can check off what should be "shared" (auto-filled) with the site before actually populating the form.

[jerf]

Then you'll love this concept: https://www.youtube.com/watch?v=3mk0RySeNsU A 1:18 "clickjacking" demo. (Link to video because I think this is legitimately one of those cases where a video can describe and demonstrate the problem faster than text.) You can google around for more info, or at least my YouTube is definitely popping up some other relevant videos.

[bobbles]

Something like "Chrome has autofilled 12 fields" or something more userworldy would be good.

Or massive highlighting around each field

[Ajedi32]

> Otherwise, a warning about what auto-fill information (IE "Your name and credit card information are going to be submitted, continue?")

FYI this doesn't work for credit card info, at least not in Chrome. That information has to be auto-filled separately.

[tyingq]

It does "sort of" work on Chrome. It does give the end user a visual cue when typing in a name...the last 4 and the cc logo: http://i.imgur.com/2bY2Pes.png

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/

[greenhatman]

Is it possible for JavaScript to trigger key presses on input boxes? Probably not.

If it was you could write a script to automatically post all auto fill data on page load.