Browser Autofill Profiles Can Be Abused For Phishing Attacks (bleepingcomputer.com) 112
An anonymous reader quotes Bleeping Computer: Browser autofill profiles are a reliable phishing vector that allow attackers to collect information from users via hidden form fields, which the browser automatically fills with preset personal information and which the user unknowingly sends to the attacker when he submits a form... Finnish web developer Viljami Kuosmanen has published a demo on GitHub... A user looking at this page will only see a Name and Email input field, along with a Submit button. Unless the user looks at the page's source code, he won't know that the form also contains six more fields named Phone, Organization, Address, Postal Code, City, and Country. If the user has an autofill profile set up in his browser, if he decides to autofill the two visible fields, the six hidden fields will be filled in as well, since they're part of the same form, even if invisible to the user's eye.
Browsers that support autofill profiles are Google Chrome, Safari, and Opera. Browsers like Edge, Vivaldi, and Firefox don't support this feature, but Mozilla is currently working on a similar feature.
Browsers that support autofill profiles are Google Chrome, Safari, and Opera. Browsers like Edge, Vivaldi, and Firefox don't support this feature, but Mozilla is currently working on a similar feature.
Obvious solution (Score:2)
Surely just only auto-fill visible fields?
Re: (Score:2)
Determining visibility of an element is exceptionally hard in a browser. There can be overlays, transparancy, dynamic elements, or simply making elements visible for a split second in a corner, for autofill to work, then capturing the data and removing the elements. I'm sure we can come up with more creative workarounds. Supposedly Firefox works around the issue by prompting the user which fields to autofill.
Re: (Score:3)
Re: (Score:2)
In any case where a website does silly stuff with entry fields, it's trivial to allow filling specific fields through a right-click menu, or through an easy method. Firefox already does this.
The theory behind this was to make it harder to sniff usernames and passwords, ignoring the fact that any sniffing utility already had a workaround.
Re: (Score:2)
4. Don't fill anything with a weak contrast (white on white, black on black, or light gray on white. Subtracting foreground color from background is easy)
Sometimes when styling custom form elements, the border goes on a container rather than the element itself.
Re: (Score:2)
You do realise that JavaScript can change the document at any time. A page could leave the elements visible for a tenth of a second, long enough for the checks you list to succeed, and then hide the elements before the user even notices. How hard will that be to deal with?
Re:Obvious solution (Score:4, Informative)
Surely just only auto-fill visible fields?
That sounds tricky as hell... how many different ways of hiding the fields are there? They could be tiny, they could be behind another element, they could be unlabeled with white text on a white background, they could be at the bottom of the page past the point where most people will bother scrolling, etc.
If autofill absolutely must be used, the correct way to do this would be to warn the user with a popup that the website is requesting information XYZ, not unlike how they currently have a popup saying that a website is requesting your detailed location information.
Also, I'm astonished this attack hasn't popped up before now.
Confirmation dialog with all fields? (Score:3)
The browser should place an "autofill" button on the toolbar or someplace off limits from any web site manipulation.
This button should open a dialog box listing all the fields to be filled with the data to be filled, with checkboxes to enable/disable filling certain fields and to edit the data that is submitted.
This would allow the user to be certain as to what form fields were filled and which ones weren't in a UI environment not controlled/manipulated by the web site.
Perhaps they could even extend it to c
Re: (Score:2)
It seems like the best solution in this case is to simply admit defeat -- that autofill profiles aren't a good idea -- and remove the feature. Your workaround, and others proposed, suffer from the weakness that they're more complicated and higher-risk than simply typing the information into the appropriate fields, the way God intended.
Re: (Score:2)
I think the reality is that there's too many forms which need filling out too often and auto-fill isn't going away, ever, so the answer is how to make it safer and more transparent to the user what info is being filled in.
At least with a user-initiated form-fill action supported with a confirmation dialog box with the fields & data to be filled prevents the most common mishaps of existing form-fill -- filling in the wrong data into the wrong fields or getting hidden fields filled with data they shouldn'
Re: (Score:2)
Why must everything be a popup warning? You can instead have this in a right-click menu, or simply have the content available if the user presses a down-arrow in the relevant field.
It first happened on MySpace, because that site allowed creating custom forms that tricked certain browsers into provid
Re: (Score:2)
You can instead have this in a right-click menu, or simply have the content available if the user presses a down-arrow in the relevant field.
A lot of people are suggesting solutions in this vein, which is changing the nature of autofill by making it more cumbersome to use. I don't use it myself and don't plan to, but I suspect that one of the reasons why some people do like it is the ease of use. The popup, problematic as it is, is the one way to do this with a minimum of extra fuss. If you want to argue people are going to just click though it, well, there's no saving those people anyway.
Re: (Score:2)
Popups cause unnecessary extra fuss in the event that you don't want to use autofill, no different than Clippy saying "It looks like you are writing a letter", and no different than popups from ad networks asking you to try out the poop-providing-penis-pills.
Each time I restart Firefox, I get a popup asking me to enter the master password for saved logins. Since this popup is window modal, it slows down the process by claiming that logging into a site that I've already logged into is more important than ac
Re: (Score:2)
Except for the many website which hide field for aesthetic reasons which then come into view as you fill out other ones.
But hey I'm all for killing that stupid practice.
I'm shcoked, I tell you. Shocked. (Score:1)
Come on, folks. It's obvious that browsers by now are the primary vulnerability our there (except perhaps the IOThingies, which are even worse).
A huge, complex piece of software, with several interpreters built in, ready to execute whatever they hoover up on the 'nets, with no clear business model (do they belong to the users or to the advertising industry? Most of the fat money flowing in the general browser's direction comes from... you guessed it; and these days money "means" ownership, alas) and with fu
Stupid feature anyway (Score:2)
Re: (Score:3)
I don't understand people who even save passwords, let alone full profiles of themselves.
Saving passwords works separately and differently than form autofill. I find it useful for shit sites (ie, 95% of all passwords) -- and if you can get them if you pwn my browser, oh well.
Re: (Score:2)
My 'vault' is a VM with no internet access under QubesOS installed on an encrypted HD.
Of course there are backups on USB sticks, encrypted.
Re:Saved passwords (Score:1)
Re: (Score:1)
Re: (Score:2)
The trick to remembering them is to have a system
On problem with systems is the wide variety of disallowed / allowed / required characters in passwords for various sites ("minimum of eight characters, at least one lower case, one uppper case, and one digit (but we won't accept puncuation marks and don't say that)"), in rulesets that are only displayed when you set the password, not when you enter it.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Is there some reason you can't be bothered to write down the ruleset if you think you wouldn't remember it?
You're kidding, right? Writing down the rule set would be writing down ALL of my passwords, past, present, and future. B-b
But my point was that:
- The variability of "password quality" rules means the ruelset has to be complex enough to handle different cases for sites with different rulesets.
- The lack of display of the site's password quality rules at login means a password generatio
Re: (Score:2)
Bad design (Score:1)
Should be pretty easy to program this function properly.
How about, for example, making sure the filled in elements are 100% visible to the user?
Re:Bad design (Score:4, Interesting)
This is already easily broken, though. If you're only doing UI overlays on the Z axis as close to the user as possible, just fix position of the element outside of the view frame, such as top:-10000px
A better solution would be to list all fields which will receive input data. Have the browser list out every single field. Inform the user BEFORE the action is taken.
Re: (Score:3)
The ones that care.
To the rest: Learn to read or get off the internet. No sympathy.
This is why HTML should be display neutral (Score:5, Insightful)
HTML was supposed to define a page semantically (e.g. header 1). Letting it get crufted up with instructions on how to make it look pretty was a horrible idea (albeit one that came early on). A form should look like a form. No, I don't need whatever new hotness some designer invented with some colorscheme A/B tested to hell and back to try to trick me into clicking the desired button.
Lynx (Score:2)
HTML was supposed to define a page semantically (e.g. header 1). Letting it get crufted up with instructions on how to make it look pretty was a horrible idea (albeit one that came early on). A form should look like a form. No, I don't need whatever new hotness some designer invented with some color scheme A/B tested to hell and back to try to trick me into clicking the desired button.
The solution to your problem is this great browser calld Lynx. Google it!
Re: (Score:3)
Re: (Score:2)
Letting it get crufted up with instructions on how to make it look pretty was a horrible idea
Sure if you wanted the internet to be DoA as a publishing platform it was a horrible idea. HTML was designed to present some very basic information. We've come a long way from the original design intent from HTML.
This Kills Autofill (Score:5, Interesting)
The only responsible action for the browser companies to do is to kill off autofill. There's no reliable way for the browser to be sure the user can see which fields have been autofilled. Any attempt to popup and warn the user is going to be annoying, reduce the convenience of the feature, be confusing and people will just click-through 99% of the time anyway. This is why we can't have nice things.
Re: (Score:2)
The only responsible action for the browser companies to do is to kill off autofill. There's no reliable way for the browser to be sure the user can see which fields have been autofilled. Any attempt to popup and warn the user is going to be annoying, reduce the convenience of the feature, be confusing and people will just click-through 99% of the time anyway. This is why we can't have nice things.
Perhaps the only responsible action intelligent people should take is to leave the features intact (the lazy masses will demand this anyway), and allow the idiots who favor convenience over privacy to learn their own lessons the hard way.
Wisdom is a great teacher, but ignorance often demands Experience to be their guide in life.
Re: (Score:2)
Do you REALLY think that the popup will reduce the convenience MORE than REMOVING THE FEATURE ENTIRELY?
Re: (Score:2)
No, obviously not; that's why I listed multiple reasons why autofill has to go. The big one is that people will just click-through without understanding.
Re: (Score:3)
It would be better for everyone if there was some standard way for web sites to request certain personal information that is necessary for online shopping and the like. Easier for users to have a consistent UI instead of every site using a different form, and better for security as the data can be better controlled.
Re: (Score:2)
Or how about simply modifying the browser to only autofill fields that are visible when submitted? Chrome highl
What is so bad about what it can get (Score:2)
Of all the items the hidden autofill can access, "phone" is a little annoying. But not that much. I can pretty easily now block calls and span texts.
It's not like it is auto-filling CC details for example. That is triggered separately from address data.
Are you worried someone is going to send you a catalog you did not ask for? Welcome to the party pal.
Never use autofill (Score:1)
I never use autofill and I turn it off whenever possible. It is the fear of exactly the same kind of shit that keeps me away from it.
Basically, if the browser knows about your identifying information, you should assume an attacker knows already.
I can't be the only one... (Score:2)
I can't be the only one who has disabled auto-fill from day 1 for precisely this reason, am I?
Security isn't hard if you think about it during the design stage and you're willing to scrap designs that are inherently insecure, such as automatically sending personal information to random web sites.
Re: (Score:2)
Best thing would make them autofillable with a browser command that javascript and such cant use.
Re: (Score:2)
How exactly would that even solve the issue? As soon as the user hits "submit", the data is submitted. ZERO JavaScript required for this particular phishing attack as it is already.
Re: (Score:2)
Re: (Score:2)
as I understood hes statement was that it would go:
enter page->form is filled by the browser->user presses submit->information is sent to server as I said:
enter page->form is filled by the browser->js triggers->information is sent to server (no user
Re: (Score:1)
Though this doesn't require JS to work (as once one hits submit it goes anyway), but it does give me an idea for a pretty much total fix browser side.
Fields auto fill yellow, they aren't actually "filled" until they're clicked and turn white. Hidden fields would be unclickable, and never actually sent.
Additionally, this wouldn't work for attempts to swipe via JS showing all fields, but grabbing the auto complete profile before submit.
Re: (Score:2)
Hidden fields would be unclickable, and never actually sent.
Errr....hidden fields are unclickable, but they do need to be sent.
Hidden fields are part of normal form elements and often (usually) contain information that is required when submitting the form.
Re: (Score:1)
Sorry, I meant to say fields with hidden visibility (color tricks, size tricks, etc) would never be sent if the auto complete was not put into the field (by the browser) until it was clicked.
For the sake of slurping information, I assumed these were not fields kg the type hidden, but fields hidden from being seen, like text fields that couldn't be seen.
If the browser didn't fill the DOM until a field was interacted with, then it couldn't be sneakily taken.
Re: (Score:2)
Sorry, I meant to say fields with hidden visibility (color tricks, size tricks, etc) would never be sent if the auto complete was not put into the field (by the browser) until it was clicked.
Ahh, okay, my misunderstanding.
-
For the sake of slurping information, I assumed these were not fields kg the type hidden, but fields hidden from being seen, like text fields that couldn't be seen.
If the browser didn't fill the DOM until a field was interacted with, then it couldn't be sneakily taken.
I'd bet there's still a way to fill in the fields (or extra alt-fields) by stealing the information...probably using some ajax and dom parsing and other sneaky tricks. For example, you could dynamically create some legit hidden fields on demand as soon as the submit function was triggered, fill in whatever info you want into the newly-created fields, and they'd be sent along with the rest of the form.
Re: (Score:1)
That's fine, but if the site is creating the data, it's not really slurping "private" information.
My understanding from the summary is that this attack works by having a visible name and e-mail field, and invisible address fields.
If one fills out the first two (less personal) info, they are leaking their address and phone number (by the auto fill of the other fields).
If the browser (an update I suspect will come soon after this being revealed, or at least implemented like this in browsers implementing this
Re: (Score:2)
That's fine, but if the site is creating the data, it's not really slurping "private" information.
I wasn't clear enough when I write that, and that's my fault.
The only reason for ajax is so that you could send the data out without having to even submit the form. It's not pulling data from the site, it's sending it to god knows where without anyone actually submitting the form.
You do this by instead of filling the field, have an icon in it or some such, and a click fills it, still quite convenient for the user, but protected from secret fields the user can't see.
They'll just have their malicious javascript click the icon, intercept the data, and silently copy it to a hidden field.
Re: (Score:1)
Except the browser doesn't need to put the icon in the DOM either.
The browser can far something that the user can interact with, but not JS.
The icon would be drawn by the browser, not the website, it wouldn't be any more accessible (due to implementation) to JS than a separate window.
Re: (Score:2)
Except the browser doesn't need to put the icon in the DOM either.
The browser can far something that the user can interact with, but not JS.
The icon would be drawn by the browser, not the website
These sentences seem to contradict one another, and I'm not sure what "The browser can far something that the user can interact with". (??)
Re: (Score:1)
My browser can draw something not in the DOM (for example, it makes autofilled fields yellow, but I assume JS doesn't see that).
My browser can draw things on webpages that don't exist on the page (in the simplest form, a webpage cannot interact with the elements of an iframe (at least it didn't used to be able to).
My point is the icon to click is created by the browser, not the webpage, and it can be rendered to my screen without the website having any ability to interact with it via JS.
By requiring true us
Re: (Score:2)
The point here is that hidden/offscreen/behind logo/transparent/etc AUTOFILL fields should NOT be sent.
While the idea has merit for consideration, the issue I see with it is going to be blind/tab navigation where you can tab into things you can't see and therefore confirm them. Screen readers should read the text being inserted and thus alert the user, but how many times have you ignored the fact that focus jumps all over when you're tabbing through
Re: (Score:2)
The point here is that hidden/offscreen/behind logo/transparent/etc AUTOFILL fields should NOT be sent.
Not only should they not be sent, they shouldn't even be filled in. But, deciding whether to fill them in often comes down to trying to guess the intent. Is the field just below the scroll, or is it really hidden in some illegitimate way? Maybe it's hidden in some legitimate way. It could be tough to determine why the field isn't visible, or even if it's not really visible. Hell, you could make a div act exactly like a form field, hidden or not.
But frankly, even not sending the hidden fields wouldn't stop t
Re: (Score:2)
Proof of concept demo (Score:5, Funny)
"don't autofill hidden form fields". Kudos to the researcher, but hardly a topic worthy of lengthy discussion?
Hmm.
Wow, you're right! That was easy!
Re: (Score:2)
Re:Proof of concept demo (Score:5, Informative)
If Field.IsCleverlyHiddenByAPhisher == False
Whilst your at it, could you also add a `If Site.IsTryingToInstallMalware", so we can finally get rid of that problem too?
I'd also like a "If DatingSite.WillProfileMakeOutOnFirstDate", but I think it might be too easy for you.
Re: (Score:3)
Re: (Score:1)
a patch for FreeBSD 7 is available and is kept up-to-date
Clearly, if this was implemented on every router, they could scan packets and set the evil bit and propagate it back to the originators. This could put a stop to DDOSs.
Re: (Score:2)
Field.IsCleverlyHiddenByAPhisher
Do you have any idea how hard that field is to implement? I guess not.
Re: (Score:2)
Re: (Score:2)
Fair cop. Well played.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
They made up their own code tag called <ecode> for that. It's been a while since I've tried it though, it might be broken too like half the other stuff around this joint.
Re: (Score:2)
That kind of code indicates some rather flawed logic. Why would you ever want to compare something against a boolean? Better to write simply If !Field.IsCleverlyHiddenByAPhisher ...
Re: (Score:1)
In the name of portability? I regularly do comparisons for true and false. Granted it's because I do C coding which doesn't formally define true and false as part of the language and instead relies on typedefs or #defines. And yes, people always define false to be 0, and true to be 1, but just in case some jackass at some point in the future flips those, it's best to do the explicit comparison and let the compiler do the simplification.
Re: (Score:2)
Argh, in C, comparisons against true (TRUE) or false (FALSE) are even worse style. Indeed, in C, defining TRUE == 1 is erroneous, because in C anything that is zero is false, anything that is non-zero is true. So in C, code such as
if (a == TRUE)
is a bug. Any non-zero value represents true, but this comparison only tests for a == 1.
Comparisons against FALSE are OK, but flawed logic. It is anyway a boolean, so why not just test directly?
if (a)
In C, you should *never* do a comparison against TRUE. If you
Re: (Score:2)
And if someone flips the meaning of TRUE and FALSE, then you have much bigger problems on your hands. The whole basis of comparison operations in C is based around zero versus non-zero. The value '1' has no significance whatsoever.
Re:Just solve the bug... (Score:5, Insightful)
"don't autofill hidden form fields"
How do you know it's hidden, for sure? The fields may be displayed in a non-showing mode in css (visible:hidden, display:none), or, worse, the fields might be shown in the same background color as the page (white on white). The fields could also be displayed with a 1px width... or buried somewhere within some text three pages down below...
The autofil feature needs to be smarter, and show the user the list of fields to be filled, and ask if it's ok.
Re: (Score:3, Insightful)
...The autofill feature needs to be smarter, and show the user the list of fields to be filled, and ask if it's ok.
Uh, ask the user?
The user who abuses the I'm-too-lazy-to-type autofill feature?
The user who will instantly dismiss any form of notification that requires reading and accept anyway?
You mean that user?
Seems you have forgotten about the mentality that created shit like autofill in the first place.
Re: (Score:2)
Re:One user (Score:1)
Re: (Score:3)
I feel kinda odd for suggesting something I saw in a MS product, but how about the Excel approach? When you start to type in a field, it offers you a known text that would complete what you started.
Re: (Score:2)
That is exactly what Firefox does today.
Re: (Score:2)
Ok, now I feel even odder for suggesting something Firefox does...
Re: (Score:3)
Click to fill fields you want maybe?
Re: (Score:1)
This is exactly what Opera's Wand feature was. If I'm not wrong, it stopped existing when they moved to Chromium.
Re: (Score:2)
.hidden_field
{
margin-left: -999999;
}
Re: (Score:2)
Re: (Score:2)
"don't autofill hidden form fields"
How do you know it's hidden, for sure?
How do you know if it's hidden nefariously? There are plenty of websites which show an increasing progression of forms (next buttons give me the shits) where new fields come into view after you fill out ones previously.
But hey if this kills that web design practice I'm for it.
Re: (Score:2)
Re: (Score:2)