📜 ⬆️ ⬇️

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 in to adult sites, and this will remain in the firewall logs as an attempt approx.) 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 page they visit.

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 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:

https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Fbookmarks%2Fpages

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 .

Again:


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 we 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 of the images at fbcdn.net, however, you can “knock” on the Facebook logo - favicon.ico:

https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Ffavicon.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 have not seen anything or the image has not loaded, 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.

This vulnerability can be used as one of the stages of other types of attacks, such as ClickJacking or ProfileJacking .

Service Reaction


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 to Robin’s bug reports from a number of major services and social platforms.

Facebook:
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 a 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.

Twitter:
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.

Yahoo:
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.

Square:
Thanks for contacting us. We concluded that this question presents minimal risk and therefore no changes will be made to the code for its solution.

Dropbox:
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.

Source: https://habr.com/ru/post/312636/


All Articles