Sponsored By

Autofill Brings Automatic Vulnerability

A vulnerability in browser-based autofill may mean that your users are spilling the beans on much more than they know.

Larry Loeb

January 2, 2018

3 Min Read

The economics of the Internet, sadly, have ended up being fairly simple. If you aren't directly paying for a product, then you are the product. And part of being that product -- the information about you that marketers want -- involves tracking where you go on the net.

First there were cookies and other data structures used by marketers to track web browsers. Users eventually gained enough sophistication to eliminate or neutralize each of these mechanisms. Adblockers and privacy code became part of the browser used to immerse one in the web.

But it seems some marketers got a bit clever in order to grab data on users. Researchers at Princeton's Center for Information Technology Policy found evidence of a trick that uses the login manager found in every major browser. It ended up allowing two marketing firms to use scripts that fooled the browser into filling in hidden login forms that they had created. The basic problem with the login managers function had been known for over ten years, but until now had only been used in cross-site scripting attacks.

What the marketers ended up with was a username or email address that was formed into a hash and then correlating that hash to the user's existing advertising profile. The result is more powerful than it seems on first glance.

The researchers outlined succinctly the value of this data by saying on their blog post, "Email addresses are unique and persistent, and thus the hash of an email address is an excellent tracking identifier. A user's email address will almost never change -- clearing cookies, using private browsing mode, or switching devices won't prevent tracking. The hash of an email address can be used to connect the pieces of an online profile scattered across different browsers, devices, and mobile apps."

So, this is a tracker of real utility to someone who wants personal tracking information. It can't be easily avoided in creation since it is done in secret nor will browser action affect it. But it may lead to fines under the EU's GPDR privacy regulations that go into effect this May, even if the site owner is unaware of its existence.

Protect your website
Solving this behavior would require a change in how the login manager operates. It would have to stop filling in the hidden fields unless users interacted with them. That's a change that has not occurred to date, even though the potential vulnerability has been known.

The researchers do suggest that publishers isolate third-party scripts by putting them in a different subdomain. This would stop autofilling. A separate framework for the scripts might also provide relief.

Protect your users
Individual users might also consider an external password manager that will not fill in hidden fields. The benefits of this kind of manager may be greater than just what shows up in a browser. As an IT or IT security manager, it could be worth looking at default browser behavior and implementing a policy that disables browser-based autofill, replacing the function with a secure password manager insulated from the kind of autofill scripting attack represented in this latest vulnerability.

Login managers are useful in the abstract, but like most things, may trip you up when used practically. Do you know what user information your browsers are giving up? If you can't say "yes" with certainty, it's time to put your browsers under a serious set of data restrictions.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Read more about:

Security Now

About the Author(s)

Larry Loeb

Blogger, Informationweek

Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He has written a book on the Secure Electronic Transaction Internet protocol. His latest book has the commercially obligatory title of Hack Proofing XML. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. His first Mac had 128 KB of memory, which was a big step up from his first 1130, which had 4 KB, as did his first 1401. You can e-mail him at [email protected].

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights