Security breach on Chromiums!
-
-
A Former User last edited by
@zalex108, thanks for notifying us. We'll investigate the issue and reply to you soon.
-
zalex108 last edited by@antukh
Didn't know you still using O12x.
Actually, I prefer that Presto (Ctrl+Enter) behavior.
"You cannot know the meaning of your life until you are connected to the power that created you". · Shri Mataji Nirmala Devi
-
leocg Moderator Volunteer last edited by
Isn't it just credentials management being used and doing what it is supposed to do?
It would be interesting to see if it happens in a non-secure page and/or if a site can see the login info for other ones.
-
blackbird71 last edited by@leocg From https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/ (the website that first discussed the issue):
... First, a user fills out a login form on the page and asks the browser to save the login. The tracking script is not present on the login page [1]. Then, the user visits another page on the same website which includes the third-party tracking script. The tracking script inserts an invisible login form, which is automatically filled in by the browser’s login manager. The third-party script retrieves the user’s email address by reading the populated form and sends the email hashes to third-party servers.
...
We found two scripts using this technique to extract email addresses from login managers on the websites which embed them. These addresses are then hashed and sent to one or more third-party servers. These scripts were present on 1110 of the Alexa top 1 million sites.
...
Login form autofilling in general doesn’t require user interaction; all of the major browsers will autofill the username (often an email address) immediately, regardless of the visibility of the form. Chrome doesn’t autofill the password field until the user clicks or touches anywhere on the page. Other browsers we tested [2] don’t require user interaction to autofill password fields. Thus, third-party javascript can retrieve the saved credentials by creating a form with the username and password fields, which will then be autofilled by the login manager.Consequently, what currently occurs with this is that the auto-fill mechanism is being invoked by 3rd-party scripting on the visited domain to read the username from the autofilled data for that same domain, hash it, and send the hash as a highly-accurate tracking ID to the 3rd-party server. The 3rd-party script has been allowed by the site in the first place, but many sites poorly vet the quality of parties they contract with - particularly data marketing services.
-
leocg Moderator Volunteer last edited by
@blackbird71 I see, thanks. It would be nice if the demo page could show that.
-
blackbird71 last edited by blackbird71
@leocg As it's currently employed, the tracker script uploads a hash of the username for that site, as well as tracking and uploading the user's behavior within the site. If the username happens to be an eMail address (as some sites require), that same hash will then exist across multiple different sites; and a detailed pattern of user behavior can be unambiguously assigned to the username hash. Most of the sites currently involved in hosting the scriptings are in French and Polish locales, but the scheme has worldwide potential and privacy risks should it become more widely deployed. Personally, I am especially uncomfortable with the idea of any 3rd-parties accessing my login data in any way, even if they're site-hosted, in view of the sorry record so many sites have of vetting and policing their 3rd-party providers (hence, the reason drive-by infections occur from 3rd-party ad servers).
-
leocg Moderator Volunteer last edited by
@blackbird71 For sure site B being able to see such info for site A don't seem nice.
What I didn't get well is if the third part scripts are getting the info directly from the password managers or if they are getting it from the main sites.
-
blackbird71 last edited by
@leocg said in Security breach on Chromiums!:
@blackbird71 For sure site B being able to see such info for site A don't seem nice.
What I didn't get well is if the third part scripts are getting the info directly from the password managers or if they are getting it from the main sites.
Apparently, from the way the web standards work with site logins, a login box can be created/accessed from within the associated web domain at any time by site scripting running on the same domain. On the original login page, the normal site login box is called up by site scripting and displayed for the user to enter their data. On other site pages within that domain, however, site scripting can also call up a login box, so the 3rd-party tracking script inserts an invisible login box instead on such pages. Ordinarily, the appearance of the login box causes web browsers to autofill a login box with the correct username and an obfuscated password for that same domain. On the original, normal login page, the user sees that data appear in the boxes. On the invisible login box, the user is unaware of the data that is autofilled to the now-invisible login box, so the resulting username is read, hashed, and uploaded by the tracker script whenever the page is then clicked - hence the user is completely unaware of the tracking operation.
I'm unclear on just how much of the login data is readable by the scripting (the password is visually obfuscated on the browser's display, but it's unclear to me whether the tracker scripting can access it). Apparently, the username data at least is hashed and sent up to the tracking-script server for use as a reliable user-tracking ID in the case where the same username commonly appears across multiple websites, as it often does when required to be an eMail address. In that case, a comprehensive record of such site activity across sites and within sites can be linked using the created user ID.
-
A Former User last edited by
This is indeed a problem with no easy solution. W3C is working on standardizing a secure way to address this problem, see https://w3c.github.io/webappsec-credential-management/#user-mediated-selection. We will watch it closely and cooperate in the Chromium project to evaluate and eventually implement it.
Good news is that EasyPrivacy ad-blocking list which is available (and marked as "recommended") in Opera blocks these scripts since 4 years ago.
-
