7 ms·

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

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?

alexwebb2 10y ago
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 10y ago
  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 10y ago
    Then you'll love this concept: https://www.youtube.com/watch?v=3mk0RySeNsU 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 10y ago
  Something like "Chrome has autofilled 12 fields" or something more userworldy would be good. Or massive highlighting around each field
athenot 10y ago
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...
- jonknee 10y ago
  > 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.
  - pc86 10y ago
    > Should autofill skip regular form elements that are just a little below the viewport?
  - gregable 10y ago
    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 10y ago
    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.)
  - Raphmedia 10y ago
    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.
Ajedi32 10y ago
> 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 10y ago
  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 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/ https://jsfiddle.net/hvs4ox2q/4/
takeda 10y ago
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/ https://addons.mozilla.org/en-US/firefox/addon/secure-login/
- jamesgeck0 10y ago
  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.
- MiddleEndian 10y ago
  I miss the magic wand so much. It also ignored autocomplete=false. Truly a tool that belonged to the user above all else.
greenhatman 10y ago
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.

alexwebb2 10y ago

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 10y ago
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 10y ago
  Then you'll love this concept: https://www.youtube.com/watch?v=3mk0RySeNsU 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 10y ago
Something like "Chrome has autofilled 12 fields" or something more userworldy would be good. Or massive highlighting around each field

athenot 10y ago

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

jonknee 10y ago
> 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.
- pc86 10y ago
  > Should autofill skip regular form elements that are just a little below the viewport?
- gregable 10y ago
  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 10y ago
  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.)
- Raphmedia 10y ago
  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.

Ajedi32 10y ago

> 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 10y ago
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 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/ https://jsfiddle.net/hvs4ox2q/4/

takeda 10y ago

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/ https://addons.mozilla.org/en-US/firefox/addon/secure-login/

jamesgeck0 10y ago
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.
MiddleEndian 10y ago
I miss the magic wand so much. It also ignored autocomplete=false. Truly a tool that belonged to the user above all else.

greenhatman 10y ago

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.