I always wondered about this. Also, wouldn't it be really easy to have a form pull autofilled CC info via ajax without even needing the user to hit submit?
If I'm remembering correctly, Chrome's autofill doesn't fire change events for the fields. Has annoyed me from a developer standpoint at times, but the reason behind it is valid.
Though to grab this info with ajax it doesn't have to fire off an event when the auto-complete changes it. It could just check every second itself if the form changed and if so send off the info.
If all web developers set autocomplete="off" on their CC forms this wouldn't be an issue. But if it were up to me, browsers would refuse to remember numbers that "look like" credit cards and match the checksum. Does autocomplete even trigger on HTTPS forms? Maybe this isn't even that big an issue in the wild.
And after I wrote the above comment, I tested it and I am as well, on Linux.
The fun thing about this type of vulnerability is if you know the user's name, you can build an invisible form component to get the browser to spill the stored password.
I have autofill enabled with Chrome 19.0.1081.0 on Windows 7 and it did not fill the hidden fields. I have an update pending for Chrome, maybe it will reintroduce the issue.
This raises another issue I have been concerned with for a while. The WWW model is broken, namely the use of Javascript. I'm not talking about the language itself, it has been getting enough love lately as it is. Just the idea of a webserver sending me code, obfuscated code at that [1], that my browser executes by default; how did this idea prevail on the web, I wonder. Am I the only one to see the horrendous security flaw? "Come to my website, I'll distract you with my pretty pictures while my code roams freely on your computer[2]".
[1] - I know obfuscation is minification meant for minimizing bandwith consumption. It's still obfuscated code, despite best intent.
[2] - I understand that the code execution is sandboxed inside the web browser, but really is it at all possible that, you know, these guys let the occasional security flaw slip?
You're correct, but the parent brings up a valid (if a bit off topic) point.
Eye candy is great, but Javascript has often been a vector for privacy issues. Hence the popularity of Noscript and most browsers having an option to disable Javascript.
> Am I the only one to see the horrendous security flaw?
No, every user of NoScript sees it. At the end of the day, your computer has executed billions upon billions of instructions, most of which you have no idea what their purpose is or if they leak your security or privacy. Even those of us running a Linux box have this problem. I trust a lot of code, I trust my CPU and my BIOS and my OS, and my NoScript whitelist has only grown, it doesn't shrink. (It does gain temporary permissions every so often when I don't quite trust the source but figure the risks are negligible.)
The vast majority of people (and website owners) don't want to harm you or your computer or society as a whole (There is a lot of low-hanging fruit for the studious domestic terrorist.) People have good reason to think they'll be safe executing unknown code. The model caught on because it's useful and because the web of trust extends far. NoScript is still used by the minority and that's unlikely to change.
Stopping autofill of hidden fields is easy and must be done.
To truly fix this bug, though, it would be nice to also stop autofill of technically "visible" fields that are tiny or under another object or otherwise obscured. But that might be orders of magnitude more difficult.
One workaround for this in chrome is to remove name/email values from address auto-fill form, so it will only populate when you actually enter address.
And it's generally good idea to separate general browsing from personal/finance/etc using user profiles.
26 comments
[ 2.5 ms ] story [ 59.1 ms ] threadIf I enter my real name somewhere, I'm probably fine with providing my phone and post address, too. When in doubt I use a fake identity.
what about chrome's credit card autofill?
Aye. But when I enter my email adress somewhere, I don't necessarily feel comfortable giving them my real name + phone number
The fun thing about this type of vulnerability is if you know the user's name, you can build an invisible form component to get the browser to spill the stored password.
[1] - I know obfuscation is minification meant for minimizing bandwith consumption. It's still obfuscated code, despite best intent.
[2] - I understand that the code execution is sandboxed inside the web browser, but really is it at all possible that, you know, these guys let the occasional security flaw slip?
Eye candy is great, but Javascript has often been a vector for privacy issues. Hence the popularity of Noscript and most browsers having an option to disable Javascript.
No, every user of NoScript sees it. At the end of the day, your computer has executed billions upon billions of instructions, most of which you have no idea what their purpose is or if they leak your security or privacy. Even those of us running a Linux box have this problem. I trust a lot of code, I trust my CPU and my BIOS and my OS, and my NoScript whitelist has only grown, it doesn't shrink. (It does gain temporary permissions every so often when I don't quite trust the source but figure the risks are negligible.)
The vast majority of people (and website owners) don't want to harm you or your computer or society as a whole (There is a lot of low-hanging fruit for the studious domestic terrorist.) People have good reason to think they'll be safe executing unknown code. The model caught on because it's useful and because the web of trust extends far. NoScript is still used by the minority and that's unlikely to change.
To truly fix this bug, though, it would be nice to also stop autofill of technically "visible" fields that are tiny or under another object or otherwise obscured. But that might be orders of magnitude more difficult.