It all started with Google YOLO
My journey began when I came across a great blog post called Google YOLO , authored by @filedescriptor , about the clickjacking vulnerability of Google YOLO (You Only Login Once) web widget that provides one-click inline authorization on websites . I highly recommend that you drop by and read a blog post that describes and interactively demonstrates clickjacking techniques.
In short, the privacy issue is that you can create a website with a Google YOLO widget and mask the widget as a harmless button. When you click on a button that is harmless at first glance, the victim unknowingly logs in with his Google account, transferring his identity to the website owner, including his full name and email address.
Often, this does not really matter, since many websites most likely already know your identity. Nevertheless, this problem can have unpleasant consequences. Consider, for example, filling out an allegedly anonymous survey. Since you have never visited this website, you might think that it does not have the ability to link your answers with your identity, but this is not at all.
When I first stumbled upon the Google YOLO blog post, Google had already fixed the problem by restricting the function to only affiliate websites. This blog post also describes clickjacking using the Facebook Like widget, but when you clicked on the button, the widget asked for confirmation:
The confirmation request makes this attack impossible - even if the victim unconsciously clicks the “Like” button twice, she will still have to confirm her action in the pop-up window. The popup cannot be modified by the attacker site and therefore is not susceptible to clickjacking attacks. The disadvantage of this solution is that it makes use less convenient, requiring additional actions every time, even for the intentional use of the “Like” button.
As a result, I came to the conclusion that large companies solved this problem, and for a while I forgot about it, until I had a new idea ...
Facebook comment widget: “typejacking”
One day, while walking around the Internet, I came across a website that used the Facebook comment widget to allow visitors to comment on a third-party page. At that moment, I remembered what I read earlier and thought: the clickjacking problem was solved by large companies, but what about “typejacking”? What if I take a comment widget and paste it into my website, disguising it as an unrelated form? Then, if I can convince the victim to enter text in it, any text, and send it as a Facebook comment to my page, I can find out her identity by checking on Facebook which account just posted the comment.
With this in mind, I started working on a web page that demonstrates this technique. In the process, I accidentally discovered that the “Like” widget, which seemed to me to require confirmation, works without confirmation on my web page! When reading about a widget on the Internet, I found that Facebook, unlike Google, uses a blacklist to protect against clickjacking.
The way Facebook decided to protect its users from clickjacking can protect against massive collection of likes - Facebook may notice that a large number of likes come from one site, add confirmation, and even cancel likes. But this does not protect against the threat of deanonymization. An attacker can easily create a new website and use clickjacking with the “Like” widget, then send the page to a limited number of victims and reveal their identities by tracking Facebook likes.
To my surprise, the likejacking technique, a term that describes the clickjacking technique for getting likes, has been known since at least 2010 . And today, 9 years later, it still remains relevant. Also, when it comes to “likejacking,” the issue of deanonymization is rarely mentioned. The issue of deanonymization was publicly written, at least as far back as 2012 , but nevertheless, I believe that not enough people know about it, especially for our time, when more and more people understand the importance of privacy on the Internet.
As for the typejacking technique, I still added a web page that demonstrates the attack . You can experiment yourself or watch the video:
Clickjacking, typejacking ... what else?
Reflecting on the clickjacking technique, I wondered what else could be done using the ability to insert and manipulate third-party widgets on a malicious website. Clickjacking and typejacking techniques are designed for user interaction with the widget. What if instead we convince the user to provide us information from the widget?
It turned out that someone had already thought about it before me. A quick search led me to the Tell Me About Yourself: The Malicious CAPTCHA Attack article, which analyzes this technique. Here is an example from an article that demonstrates how an attacker can trick a victim and unknowingly reveal his name by masking the widget as an innocent captcha:
Clickjacking prevention for site owners
There is still no reliable way to prevent clickjacking.
In 2009, the X-Frame-Options HTTP header was introduced, which offers partial protection against clickjacking. The header allows the website owner to specify which pages should not be in the frame. The browser supporting the header will refuse to load these pages in a frame. Although this prevents clickjacking in some cases, it does not help with widgets that need to load in a frame, such as a Like widget or a comment widget.
Looking at the X-Frame-Options headline, I thought, why not make a similar option that would provide a measure of protection while still allowing the web page to load in a frame? Consider, for example, the “Like” widget: is there a good reason a web page should draw over a button? Resize or transparency buttons? Do any other manipulations like CSS filters? The only reason I can imagine is clickjacking. Why not introduce a new X-Frame-Options option, such as X-Frame-Options: Isolate , which allows the web page to load in the frame, but ensures that the frame cannot be resized and the parent website cannot draw over him. As with previous ideas, and this is someone suggested before me .
While browsers do not implement such protection, website owners have only one option: require additional interaction with the user, for example, using a separate pop-up window. We saw that Facebook does this with the “Like” widget, but only for the suspicious websites on which it is hosted. Obviously, Facebook values the convenience of users more than their privacy.
Update: It turns out that Chrome gives widget owners the ability to detect clickjacking using Intersection Observer v2 . This feature is enabled by default starting with Chrome 74, released in April 2019. Unfortunately, currently only Chrome implements it, and it is not so easy to use - at least more difficult than adding a header. See article Trust is Good, Observation is Better for more information.
Clickjacking Prevention for Users
After trying several solutions, I came to the conclusion that blocking third-party cookies is the best way to prevent information leakage through clickjacking. This does not prevent the clickjacking technique itself, but since the embedded frame does not receive visitor cookies, this frame will not be particularly useful to an attacker.
Plus, the option to block third-party cookies is that in most browsers this option is built in initially. No need to install any third-party extensions or look for different solutions for different browsers or devices.
The disadvantage is that widgets such as the Like widget or the comment widget will stop working on all sites. I don’t really miss them, but maybe this option is not suitable for everyone.
Another advantage of blocking third-party cookies is that blocking can protect against side-channel attacks that do not require user intervention. For example, this method demonstrates the use of the CSS3 function to deanonymize Facebook users without additional user interaction with the web page. Another example of an old but interesting vulnerability that can be prevented by blocking third-party cookies is the Generic cross-browser cross-domain theft , which uses a loophole in the CSS specification to force the browser to use the cross-origin page as CSS and access to specific information ( issue of the Chromium project ).
Conclusion
Among all the historical and technical details in this article, there is a recommendation that I would like to emphasize again: consider blocking third-party cookies in order to improve the protection of your identity on the Internet.
I hope this article will help raise awareness about the clickjacking technique, which has been known since 2010 and has not yet been resolved. Perhaps browser vendors will consider introducing measures to prevent it, to limit frame manipulation.
PS On Habré wrote about a similar problem on the website VKontakte 5 years ago. It seems that the demo is no longer working (you need to confirm the action in a pop-up window), but, as you can see, the theme is still relevant. Perhaps there is another widget on the VKontakte site that you can use, for example, a comment widget. But, unfortunately, in that article, the author did not mention the blocking of third-party cookies.