Slashdot Mirror
Browser Autofill Profiles Can Be Abused For Phishing Attacks (bleepingcomputer.com)
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.
Surely just only auto-fill visible fields?
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 fuzzy borders...
What could possibly go wrong?
And no, not ranting at the heroes who try to get that running: they're heroes. But they're tilting at windmills.
I don't understand people who even save passwords, let alone full profiles of themselves.
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?
Then you can with css and\or using images or other things to cover up the non-hidden fields.
Best thing would make them autofillable with a browser command that javascript and such cant use.
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.
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.
Your ad here. Ask me how!
?, it is not even that, that data can be submitted to the server before you click anything as the fields gets auto-filled when you enter the page, then it just about having a js-trigger who listen on x-field-changed that will send the filled data before anything is clicked by the user.
"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!
"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.
Slashdot, fix the reply notifications... You won't get away with it...
The browser should show a dialog listing all the information that it's going to fill in. OK or Cancel. Done.
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.
Watch most comments (except a few snarky ones) fixing a touch of paint on a window sill here or on a bulging patch there: the whole house's frame is rotten and the roof is already leaning perilously.
As long as we can't answer the question properly "whose browser is it"? we are not at the meat of the matter.
Stakeholders, in rough order of involvement:
- advertising industry
- state actors, more or less shady
- "intellectual property" industry
- 499 more, not named here
- the user
Guess how much weight the user's interests have. Of course, for those stakeholders at the top, user's *trust* makes a difference (as long as there are different "brands" of browsers), but only perception really matters: a warm, fuzzy feeling that "you are being taken care of".
What really drives me crazy is the blindness of techies, insisting that "making sure the filled in elements are 100% visible to the user" or "just offer an (ignorable) popup in the corner" or "HTML should be display neutral" would fix anything. Best case it'd stuff that hole in the (totally rotten) front door threshold while the mud is rushing in through than gap left by the collapsed rear wall.
...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.
I don't autofill forms. Ever. Since I'll review the data in the fields anyway, I'll just type it myself or use the down arrow to get a historical entry all by itself. If it goes yellow and attempts to fill in a set of fields at once I skip it.
The user sees a bunch of fields that are not supposed to be filled. And of course he may click ok without further check. The solution is not perfect but is much better than the current "no warning" solution.
Slashdot, fix the reply notifications... You won't get away with it...
I am one user who uses autofill and would glance over such a thing to make sure I am sending what I think I am sending. Recently the autofill has been appending the day of my birth to my address. I even saw it append it twice! I would really welcome such a feature for reasons in addition to accidental overshare.
Well, Ideally you would have a different password for every site you log into. Some sites store the password or some way the current password can be recovered, so that if they get hacked or something the attacker will try it on other sites. You can try to remember them all, but I prefer to keep them in a password protected cache that I remember the password to and don't save.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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 create "profiles" of common field data that would allow you to choose from various sets of data (different addresses, phone numbers, etc) to fill in.
But they should make use of the browser-controlled autofill dialog mandatory and never fill web page fields unless the user interacted with the browser autofill dialog so that sites couldn't mine data through hidden fields or cause accidental autofills from taking place.
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.
FFS just don't autofill particularly not with ID & Password which it has to be storing in a way it can unencrypt to plain text because that's a bad enough attack vector on its own
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Or perhaps "don't auto-fill any field if the user doesn't interact with that field" -- don't auto-fill the whole form, for example, just go one field at a time.
Click to fill fields you want maybe?
This is exactly what Opera's Wand feature was. If I'm not wrong, it stopped existing when they moved to Chromium.
Still stupid. I have seperate passwords for all the sites/devices I own. The trick to remembering them is to have a system - so if you forget it you can work out what the system is depending on the site. Don't do something stupid like have the website name as the password though, obviously...and I can't tell you my system because then it would be compromised. Have a think though, and I'm sure you could come up with something.
?, it is not even that, that data can be submitted to the server before you click anything as the fields gets auto-filled when you enter the page, then it just about having a js-trigger who listen on x-field-changed that will send the filled data before anything is clicked by the user.
Yes, that is possible, but how exactly does the use of JavaScript qualify as a "it is not even that" to a post about not using JavaScript?
Then you can with css and\or using images or other things to cover up the non-hidden fields.
I meant hidden as in not visible, not hidden as in <input type="hidden" />.
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!
If you want news from today, you have to come back tomorrow.
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
In order to be affected you have to submit a form to a site. File this one under "you get what you deserve."
Is there some reason you can't be bothered to write down the ruleset if you think you wouldn't remember it?
File under 'M' for 'Manic ranting'
My typing isn't perfect and it would be frustrating attempting to type the password in over and over again for one.
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.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Combine this with the fact that Chrome has been wanting as of late to autofill even CC numbers .... New vector for collecting CC numbers for fraudulent charges
.hidden_field
{
margin-left: -999999;
}
"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.
missing unit
Slashdot, fix the reply notifications... You won't get away with it...
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.
Just cruising through this digital world at 33 1/3 rpm...
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.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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 a login form? (It's a minor annoyance for me when I tab from the username field and end up on some help button, tab again and end up on some lost password button, tab again and end up on some checkbox to remember me, before finally getting to the password box. The steam checkout page used to be a complete nightmare for navigation.) Would you really notice if you hit tab and the focus didn't go where you think it should? Or would you just keep tabbing until it got where you want.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Indeed, although with that number it would work with almost any unit.
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.
Just cruising through this digital world at 33 1/3 rpm...
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 the problem from happening- with some sneaky javascript form fiddling you could copy the data from the hidden fields into some dynamically-created "legit" hidden fields, and they'd get sent along with all the other (valid) fields when the form was submitted.
Using a browser these days is a lot like playing Russian Roulette.
Just cruising through this digital world at 33 1/3 rpm...
ok, still, how would the browser know if a element is not visible, check the discussion below as they talk about.
because he was talking when the submit action is called, the submit will not be called unless you press or something triggers a submit. And I was responding that you dont need to even press submit to send the form information to the server
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 interaction is needed beside visiting that page)
that why I was proposing that if the browser supports autofill, it is the browser who fills the form, but to do that, it requires some input from the user that can not be called by a js-script or anything in-bedded in the page
Dude, just get KeePass.
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 in the future) simply left the autofill information unavailable to the DOM until the user actually clicked to fill a field, this attack no longer works.
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.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
"Grab them by the pussy" -- President of the United States of America
That is exactly what Firefox does today.
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 generation ruleset isn't enough. You still need to record something about the particular site to know which workaround branch of the ruleset to use with the site.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
How does writing down the ruleset that a site requires, which is information that you get when you first create the password, allow anyone to guess your passwords? This is information that anyone who was setting up a password on that site would already know anyways, or at least be able to trivially get. You would be no more compromising your own passwords with such information than you would be compromising everybody else's.
File under 'M' for 'Manic ranting'
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.
Just cruising through this digital world at 33 1/3 rpm...
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.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Ok, now I feel even odder for suggesting something Firefox does...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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". (??)
Just cruising through this digital world at 33 1/3 rpm...
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 user interaction to actually fill the form (as in put field contents into the DOM) there is no way for information to be scraped that the user did not place there.
as for my inattentive auto correct to "far" I'm at a loss too, probably "draw"
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg