假设您有一个JavaScript小部件，当且仅当用户想要点击它时，才需要向您的Web应用程序发出请求。您不希望此请求容易受到CSRF的攻击，因此您需要向页面编写iframe。基于origin inheritance rules，父站点将无法读取CSRF令牌。然而，点击劫持（或likejacking）呢？由于CSRF，您必须位于iframe内，x-frame-options无法帮助，frame-busters也是如此。
攻击者将在加载小部件后应用SVG mask iframe。此掩码将使iframe不可见。此时，攻击者可以将iframe的大小调整为页面大小，也可以使iframe跟随游标不可见。无论何时用户点击页面上的任何位置，iframe都会收到点击事件及其游戏结束。
所以存在二元性，似乎你陷入了CSRF和Clickjacking之间。这个问题的最佳解决方案（如果有的话）是什么？
答案 0 :(得分：5)
单击窗口小部件需要打开一个包含新页面的弹出窗口 - 一个iframe不够好，它必须是一个新窗口 - 完全在您的Web应用程序的控制之下。确认该页面上的操作，无论它是什么。
是的，这有些不太优雅，但目前的Web安全架构并没有为您提供更好的选择。
答案 1 :(得分：5)
在点击劫持攻击下无法阻止请求伪造。没有可以抵御点击劫持攻击的CSRF防御，因为无法区分客户端的真实点击和虚假点击。
OWASP mentions in their CRSF prevention spreadsheet CSRF令牌防御工作的前提条件之一就是没有XSS攻击正在进行中。
在我看来，这还应该包括点击劫持，因为甚至隐藏在iframe中的CSRF令牌也无法抵御点击劫持。该请求是由用户直接点击形成的。
所以最终我们并没有真正陷入CSRF和Clickjacking之间 - CSRF防御意味着针对不同类型的攻击，其中攻击者的攻击力更低。
所以关于你提到的有关点击劫持和CSRF的问题：
这个问题的最佳解决方案（如果有的话）是什么？ - 客户端点击劫持的最佳防御方法是打开一个新的浏览器选项卡或一个调整大小的浏览器窗口来自您网站的页面并确认其中的操作，如@Zack所述。这就是twitter按钮的作用，并且在这种情况下也不能请求伪造。
所以存在二元性，似乎你陷入了CSRF和Clickjacking之间 - CSRF防御不适用于像XSS或点击劫持攻击这样的情况，它们仅对强大的功能有效攻击（带有恶意链接的电子邮件，在论坛中发布恶意链接等）。
答案 2 :(得分：4)
没有好的可编程solution on clickjacking。一些公司起诉垃圾邮件发送者作为点击劫持的辩护理由。其他人选择在用户点击iframe后显示弹出窗口，但这会降低用户体验，特别是在单击按钮的情况下。这正是Twitter为“转推”按钮所做的事情。 Facebook目前为“赞”按钮部署了这种方法，要求在黑名单域发出请求时进行确认。我听说Googlebot在使用“+1”按钮索引网页（检查计算样式，元素重叠等）时执行了一些点击劫持启发式算法......
答案 3 :(得分：-1)
<强> - UPDATE - 当你说“小部件”时，如果你的意思是你的应用程序之外的东西，未经认证的人与之交互，那么忽略这个答案。我重读了你的问题，你从来没有真正说过“小工具”的意思。我们在应用程序中有各种各样的“小部件”。我认为这就是你所说的，应用程序内部的所有内容，只有经过身份验证的用户才能与之交互。如果是这种情况，那么这个答案就是OWASP所推荐的。
- 原始答案 - “你不希望这个请求容易受到CSRF的影响，所以你要在页面上写一个iframe。”不，不要制作iframe，这样你就可以做正常的OWASP建议来防止跨站点框架。
为了防止CSRF哈希某些值，将其包含在您的表单（或ajax POST数据）中，然后检查后端的哈希值。如果它与您的网站匹配。您可以在哈希中添加的具体数据越多越好。
示例：当用户登录时，您可以创建一个长随机字符串并将其与其会话相关联。在您的网站上或查看来源时，绝不能看到此字符串。然后让我们说用户提取他们想要编辑的一些特定记录。然后，您可以将该用户设置为您创建的长随机字符串，将其记录主键，然后对其进行哈希处理。该哈希的结果可以包含在您的表单中作为隐藏。然后在你做任何事情之前在你的后端检查隐藏的存在，如果它不存在，则中止。如果确实存在，请将该用户随机会话字符串和他们提交的明文主键进行哈希处理，如果匹配，则表示它们来自您的站点。
即使您的网站已经编写，也很容易在任何地方添加此内容（假设您的网站在所有网页上都包含一些代码，例如页脚）。制作散列值并将其放在页脚中隐藏的div中。然后，您可以使用jQuery动态地将隐藏的哈希值添加到页面上的所有表单中。并且您可以使用jQuery.ajaxPrefilter将其自动添加到所有ajax POST，以防您执行ajax帖子而不是正常的表单帖子。我们已经保护了一些已经以这种方式编码的非常大的网站。
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
如果这听起来像你想要的路径，我可以展示一些jQuery代码。至于你的哈希，你想如何在后端检查它等等......这一切都取决于你是否使用ColdFusion，PHP，PL / SQL（psp）等...我可以指出你在正确的方向，如果是其中之一。
答案 4 :(得分：-1)
我想我明白你在做什么。您希望允许任何站点iframe您的小部件，因此攻击者可以完全控制父级的源代码，并可以创建点击劫持例程以强制用户单击小部件。
因此，iframe将能够使用CSRF令牌，只要父帧无法读取令牌，就可以防止此类攻击。
我确信你知道，点击劫持是一种完全不同于CSRF的攻击，需要不同的防御。
真的，如果窗口小部件比实现2阶段身份验证更重要。使用http://twilio.com呼叫用户并让他输入一个引脚。或者通过验证链接向用户发送电子邮件。或者让用户在下次用户登录窗口小部件网站时验证操作。
如果您控制了父框架，那么您将拥有更多选项。那将是一个XSS保护问题。
所以我防止点击劫持的方法有点过分了。看起来可以使用带有确认操作的弹出窗口来保护它。
答案 5 :(得分：-1)
由于CSRF，您必须在iframe中......
没有。您无法使用表单cookie和其他nonce技巧来修复CSRF。你放在哪里都没关系。
所以存在二元性，似乎你陷入了CSRF之间 和点击劫持。这个问题的最佳解决方案（如果有的话）是什么？
要修复CSRF，您必须通过修复具有注入或恶意代码的服务器，停止网络钓鱼电子邮件等来删除威胁。在没有良性环境的情况下，您需要重新验证用户（或提供另一个挑战/响应以确保交互式用户）。参见：
Te remdiate Clickjacking，在Javascript中使用X-Frame-Options或破帧代码。但我不认为要么是万无一失的。参见：