Any site can get information about which popular services you are authorized in.
Developer Robin Linus on his page on GitHub Pages (the visit via the following link is not secure and is not recommended from the workplace, because besides the visible part of the services, the page checks whether 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 print” from you , that is, keep a record of what popular services users are logged in to even without any authorization on the visited page.
For the author of the publication, “media imprint” is as follows and is absolutely true:
And this is very unpleasant.
What is the essence
For a start, the author of the note explains how the redirection procedure to the login window takes place.
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 to which we will return 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 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 login window.
- If we are logged in, we will immediately get to https://www.facebook.com/bookmarks/pages via the same link.
It seems everything is logical.
The policy of large resources, such as Facebook, does not allow receiving the data of the request itself, since connection occurs over https. However, we can get any image from the domain, if you specify a link to it in login.php? Next =. Of course, it’s impossible to draw pictures from FB, because the social network stores almost all the images at fbcdn.net, however, you can “knock” on the Facebook logo - favicon.ico:
And on the site itself disguise it via 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 this FB badge ( ), 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, return the corresponding icon ( ), then, accordingly, you are not logged in to Facebook .
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 the help of these simple manipulations with icons, you can collect information about what services the site audience uses without its knowledge. This mechanism works for almost all mainstream 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 is ignored by most companies. Here are the answers I received to my Robin bug reports from a number of major services and social platforms.
Thank you for your message. This issue was discussed with the group responsible for security on Facebook 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 logged into the site is authorized does not pose any security threat. In any case, we appreciated your report and look forward to receiving other error messages from you.
Thank you for your report. Of course, it looks interesting, but I don’t see how this problem could pose a threat to the security of Twitter and its users. So, I am afraid that this issue can be considered closed and he cannot 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 that Emeria Grossman already mentioned . We will think about how to solve it in the future.
Thanks for contacting us. We concluded that this issue presents minimal risk and therefore no changes will be made to the code for its solution.
Thank! We will take into account this threat.
Actually, the position of most services is clear - if the vulnerability does not lead to theft of personal data / account data / does not give access to any category of data, then this is not a vulnerability.
In the Opera, setting up blocking of third-party cookies saves : https://imgd.ru/image/uchm , and when it is turned off, “everything becomes obvious” .