Any site can get information about which popular services you are authorized
The developer Robin Linus on his page on GitHub Pages (a visit to the following link is not safe and it is not recommended to run it from the workplace, because in addition to the visible part of the services, the page checks if you are logged on to adult sites, and this will remain in the firewall logs as a transition attempt ) demonstrated how sites can take a "media fingerprint" from you , that is, keep track of which popular services users are logged in even without any authorization on the page visited.
For the author of the publication, "media fingerprint" looks like this and is absolutely correct:
And it's very unpleasant.
What is the essence of
To begin with, the author of the note explains how the redirection procedure proceeds to the authorization window.
If we click on the https://www.facebook.com/bookmarks/pages link in the incognito mode, we will automatically be redirected to the login screen at:
Note the second part of the link:
https% 3A% 2F% 2Fwww.facebook.com% 2Fbookmarks% 2Fpages
This is the URL to which we will be returned after we go through the authorization procedure on Facebook. But if we use this URL to redirect to the authorization page, when we are already authorized on the site, we will immediately get to bookmarks / pages .
- If we are not logged in and go to https% 3A% 2F% 2Fwww.facebook.com% 2Fbookmarks% 2Fpages, then we go to the login window.
- If we are logged in, then we will get to the same link immediately on https://www.facebook.com/bookmarks/pages.
It seems that everything is logical.
The policy of large resources, such as Facebook, does not allow receiving the data of the request itself, because The connection is via HTTPS. However, we can get any image from the domain, if you specify a link to it in login.php? Next =. Of course, photos from FB will not be able to pull this out, because almost all the images the social network stores at the address fbcdn.net, however, you can "knock" on the Facebook logo - favicon.ico:
And on the site itself, disguise it 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 you saw this icon FB ( ), congratulations, we just made sure that you are logged into Facebook (check). If you did not see anything or the image did not load, return the corresponding icon ( ), then, respectively, 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 ">
With these simple manipulations with icons, you can collect information about what services the audience uses the site without her knowledge. This mechanism works for almost all major web services, since they all 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 most companies are ignored. Here are some answers received from Robin's bug reports from some of the largest services and social platforms.
Thank you for your message. This issue was discussed with the group responsible for security in Facebook and this error can not participate in the bug bounty program. It does not apply to a specific Facebook user. The ability to find out where the user logged on to the site is authorized does not pose any security threat. In any case, we appreciated your report and look forward to hearing from you other error messages.
Thank you for your report. Of course, this looks interesting, but I do not see how this problem can pose a threat to the security of Twitter and its users. So, I'm afraid that this issue can be considered closed and can not claim to participate in the bug bounty program. Thank you for your concern about Twitter security.
Thank you for contacting us. This is a known problem, which Emery Grossman 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 represents a minimum risk and therefore no changes to the code will be made to solve it.
Thank you! 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 give access to any data category, then this is not a vulnerability.
In Opera rescues the setting of blocking cookies of third-party sites : https://imgd.ru/image/uchm , and when it is turned off, "everything becomes clear" .