Any site can get information about which popular services you are authorized to
Developer Robin Linus on his page on GitHub Pages (a visit to the following link is unsafe and is not recommended from the workplace, since in addition to the visible part of the services, the page checks if you are logged in to adult sites, and this will remain in the firewall logs as an attempt to go ) demonstrated how sites can take a “media fingerprint” from you , that is, keep records of which popular services the visitors are logged into even without any authorization on the page visited.
For the author of the publication, the “media fingerprint” is as follows and is absolutely true:
And this is very unpleasant.
What is the essence
To begin with, the author of the note explains how the procedure of redirecting to the authorization window occurs.
If we follow the link https://www.facebook.com/bookmarks/pages in incognito mode, we will automatically be redirected to the authorization screen at:
Pay attention to the second part of the link of the form:
https% 3A% 2F% 2Fwww.facebook.com% 2Fbookmarks% 2Fpages
This is the URL that will return us after we go through the Facebook login process. But if we use this URL to redirect to the authorization page when we are already authorized on the site, then we will immediately go to bookmarks / pages .
- If we are not logged in and go to https% 3A% 2F% 2Fwww.facebook.com% 2Fbookmarks% 2Fpages, then we get to the authorization window.
- If we are logged in, then we will go to the same link immediately at https://www.facebook.com/bookmarks/pages.
It seems that everything is logical.
The policy of large resources, such as Facebook, does not allow to receive the data of the request itself, because The connection is via HTTPS. However, we can get any image from the domain if we provide a link to it in login.php? Next =. Of course, you won’t be able to pull out photos from FB, because the social network stores almost all images at fbcdn.net, however, you can “knock” on the Facebook logo - favicon.ico:
And on the site itself, mask this through the img tag as:
<img src = "https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Ffavicon.ico">
It looks like this:
If above you saw here such an FB icon ( ), congratulations, we just made sure that you are logged in to Facebook (check). If you did not see anything or the image did not load, returning the corresponding icon ( ), then, accordingly, on Facebook you are not logged in .
The final exploitation of this vulnerability is as follows:
<img onload = "alert ('logged in to fb')" onerror = "alert ('not logged in to fb')" src = "https://www.facebook.com/login.php?next=https% 3A% 2F% 2Fwww.facebook.com% 2Ffavicon.ico ">
Using these simple manipulations with icons, you can collect information about what services the site’s audience uses without its knowledge. This mechanism works for almost all major web services, since all of them store their icons on the main domain.
The problem of gaining access to information about what other services a person uses is known for a long time, but is ignored by most companies. Here are the answers Robin received on his bug reports from a number of major services and social platforms.
Thanks for your contact. This issue was discussed with the Facebook security team and this error cannot participate in the bug bounty program. It does not apply to a specific Facebook user. The ability to find out where the user who logged into the site is authorized does not pose any security risk. In any case, we appreciated your report and look forward to receiving other error messages from you.
Thank you for your report. Of course, this looks interesting, but I don’t see how this problem can pose a threat to the safety of Twitter and its users. So, I’m afraid that this issue can be considered closed and it cannot claim to participate in the bug bounty program. Thank you for your Twitter security concern.
Thank you for contacting us. This is a known issue that Emeria Grossman has already mentioned . We will think about how to solve it in the future.
Thank you for contacting us. We came to the conclusion that this issue poses minimal risk and therefore no changes will be made to the code to solve it.
Thank! We will take this threat into account.
Actually, the position of most services is clear - if the vulnerability does not lead to the theft of personal data / account data / does not allow access to any category of data, then this is not a vulnerability.
In Opera, the cookie blocking setting of third-party sites saves : https://imgd.ru/image/uchm , and when it is turned off, "everything becomes clear . "