我想与您分享我在使用clickjacking技术进行的匿名化过程中对当前事务状态的研究结果。 所谓去匿名，是指恶意网站泄露访问者身份的能力，包括其全名和其他信息。 我在这里没有提供以前未公开的任何新信息，但是令我惊讶的是，即使您遵循最佳做法并使用现代浏览器和操作系统，也很容易发现侵犯访问者的隐私并透露其身份是多么容易。
一切始于Google YOLO
我的旅程始于我遇到由
@filedescriptor撰写的
一篇 名为Google YOLO的精彩
博客文章 ，内容涉及Google YOLO（仅一次登录）网络小部件的点击劫持漏洞，该漏洞可在网站上提供一键式内嵌授权。 我强烈建议您前来阅读博客文章，该文章描述并以交互方式演示点击劫持技术。
简而言之，隐私问题是您可以使用Google YOLO小部件创建一个网站，并将该小部件屏蔽为无害按钮。 当您单击乍一看无害的按钮时，受害者会在不知不觉中使用其Google帐户登录，并将其身份转移到网站所有者，包括其全名和电子邮件地址。
通常，这并不重要，因为许多网站很可能已经知道您的身份。 但是，此问题可能会带来不愉快的后果。 例如，考虑填写据称匿名的调查。 由于您从未访问过此网站，因此您可能会认为它无法将您的答案与您的身份相关联，但这根本不可行。
当我第一次偶然发现Google YOLO博客文章时，Google已经通过将功能限制为仅联盟网站来
解决此问题 。 这篇博客文章还介绍了使用Facebook Like小部件的点击劫持，但是当您单击按钮时，该小部件要求确认：
确认请求使此攻击无法进行-即使受害者无意识地单击了两次“赞”按钮，她仍将不得不在弹出窗口中确认其动作。 攻击者站点无法修改该弹出窗口，因此不会受到clickjacking攻击。 该解决方案的缺点是使用起来较不方便，即使有意使用“ Like”按钮，每次都需要采取其他措施。
结果，我得出的结论是，大公司已经解决了这个问题，有一段时间我忘了它，直到我有了一个新主意...
Facebook评论小部件：“ typejacking”
有一天，我在互联网上逛逛时遇到了一个网站，该网站使用
Facebook评论小部件允许访问者在第三方页面上发表评论。 那一刻，我想起了我先前读过的内容和想法：大公司解决了点击劫持问题，但是“劫持”又如何呢？ 如果我将评论小部件粘贴到我的网站中，然后将其伪装成不相关的表格怎么办？ 然后，如果我可以说服受害者在其中输入任何文本，并将其作为Facebook评论发送到我的页面，则可以通过在Facebook上查看刚刚发布评论的帐户来找到她的身份。
考虑到这一点，我开始研究一个演示此技术的网页。 在此过程中，我无意中发现，“ Like”小部件在我的网页上无需确认就可以正常工作！ 在阅读有关Internet上的窗口小部件时，我发现Facebook与Google不同，它使用黑名单来防止点击劫持。
Facebook决定保护其用户免遭点击劫持的方式可以保护其免受大量喜欢-Facebook可能会注意到，很多喜欢来自一个网站，添加确认甚至取消喜欢。 但这不能防止匿名化的威胁。 攻击者可以轻松创建一个新网站，并使用带有“赞”小部件的clickjacking，然后将页面发送给有限的受害者，并通过跟踪Facebook的点赞来泄露他们的身份。
令我惊讶的是，
至少从2010年起就开始使用likejackjack技术，该术语描述了获得喜欢的点击劫持技术。 直到9年后的今天，它仍然有意义。 同样，当涉及“劫持”时，很少提到去匿名化的问题。 去匿名化的问题至少在
2012年就已公开
发表 ，但我仍然相信，人们对此知之甚少，尤其是在我们这个时代，越来越多的人了解互联网上隐私的重要性。
至于类型劫持技术，我仍然添加了一个
演示攻击的
网页 。 您可以尝试一下自己或观看视频：
点击劫持，打字劫持...还有什么？
考虑到点击劫持技术，我想知道使用恶意网站上的插入和操作第三方窗口小部件的功能还能做什么。 单击劫持和类型劫持技术旨在与用户与小部件进行交互。 相反，如果我们说服用户从小部件向我们提供信息怎么办？
原来有人在我之前已经考虑过它。 经过快速搜索，我找到了
“告诉我您自己：恶意CAPTCHA攻击”文章，该文章分析了该技术。 这是一篇文章中的示例，演示了攻击者如何通过将小部件屏蔽为无辜的验证码来欺骗受害者并在不知不觉中透露其姓名：
网站所有者的点击劫持预防
仍然没有可靠的方法来防止点击劫持。
2009年，引入了
X-Frame-Options HTTP标头，该标头提供了部分防止点击劫持的保护。 标头允许网站所有者指定哪些页面不应该在框架中。 支持标题的浏览器将拒绝将这些页面加载到框架中。 尽管在某些情况下这可以防止点击劫持，但对于需要在框架中加载的小部件（例如Like小部件或注释小部件）没有帮助。
看看
X-Frame-Options标题，我想知道为什么不做一个类似的选项来提供保护措施，同时仍然允许网页加载到框架中？ 例如，考虑一下“ Like”小部件：是否有充分的理由在网页上绘制按钮？ 调整大小或透明度按钮？ 是否还有其他类似CSS过滤器的操作？ 我能想象的唯一原因是点击劫持。 为什么不引入一个新的
X-Frame-Options选项，例如
X-Frame-Options：Isolate ，它允许将网页加载到框架中，但是要确保框架无法调整大小并且父网站不能覆盖他。 和以前的想法一样，
有人已经向我建议了这个 。
尽管浏览器没有实现这种保护，但网站所有者只有一个选择：例如，使用单独的弹出窗口，要求与用户进行其他交互。 我们看到Facebook使用“赞”窗口小部件来执行此操作，但仅针对托管它的可疑网站。 显然，Facebook更加重视用户的便利性而不是隐私。
更新：事实证明，Chrome使小部件所有者能够使用
Intersection Observer v2功能检测点击劫持。 从2019年4月发布的Chrome 74开始，默认情况下启用此功能。 不幸的是，目前仅Chrome实现了它，并且使用起来并不容易-至少比添加标题更难。 有关更多信息
，请参见
信任良好，观察更好 。
用户的点击劫持预防
在尝试了几种解决方案之后，我得出的结论是，阻止第三方cookie是防止通过点击劫持造成信息泄漏的最佳方法。 这并不能阻止点击劫持技术本身，但是由于嵌入式框架不会接收访客cookie，因此该框架对于攻击者而言并不是特别有用。
另外，阻止第三方cookie的选项是，在大多数浏览器中，此选项最初是内置的。 无需安装任何第三方扩展，也无需为不同的浏览器或设备寻找不同的解决方案。
不利的一面是，诸如“赞”窗口小部件或“注释”窗口小部件之类的窗口小部件将在所有站点上停止工作。 我不太想念他们，但也许这个选项并不适合所有人。
阻止第三方cookie的另一个优点是，阻止可以防止不需要用户干预的旁道攻击。 例如，
此方法演示了如何使用CSS3对Facebook用户进行匿名处理，而无需与网页进行额外的用户交互。 可以通过阻止第三方cookie阻止的一个古老却有趣的漏洞的另一个示例是
通用跨浏览器跨域盗窃 ，它利用CSS规范中的漏洞来强制浏览器将跨域页面用作CSS并进行访问具体信息（
Chromium项目的发行 ）。
结论
在本文的所有历史和技术详细信息中，我想再次强调一个建议：考虑阻止第三方cookie，以改善对Internet身份的保护。
我希望本文有助于提高人们对自2010年以来已知但尚未解决的点击劫持技术的认识。 也许浏览器供应商会考虑采取措施来防止这种情况的发生，以限制帧操作。
PS OnHabré
于 5年前
在VKontakte网站上写过
类似的问题 。 该演示似乎不再起作用（您需要在弹出窗口中确认操作），但是如您所见，该主题仍然有意义。 也许在VKontakte上，您可以使用另一个小部件，例如注释小部件。 但是，不幸的是，在那篇文章中，作者没有提到阻止第三方cookie。