假设您有一个 JavaScript 小部件，当且仅当用户想要单击它时，它才需要向您的 Web 应用程序发出请求。您不希望此请求易受 CSRF 攻击，因此您将 iframe 写入页面。根据源继承规则，父站点将无法读取 CSRF 令牌。但是点击劫持（或类似劫持）呢？由于 CSRF，您必须在 iframe 内，并且x-frame-options无济于事，对于frame-busters也是如此。
攻击者将在小部件加载后对 iframe应用SVG 掩码。此蒙版将使 iframe 不可见。此时，攻击者可以将 iframe 的大小调整为页面大小，或者让这个现在不可见的 iframe 跟随光标。无论何时用户点击页面上的任何位置，iframe 都会收到点击事件并结束游戏。
所以有一个二元性，你似乎被困在 CSRF 和 Clickjacking 之间。这个问题的最佳解决方案（如果有的话）是什么？
单击小部件需要打开一个包含新页面的弹出窗口——iframe 不够好，它必须是一个新窗口——这完全在您的 Web 应用程序的控制之下。在该页面上确认操作，无论它是什么。
是的，这有点不雅，但是目前的 Web 安全架构并没有给您任何更好的选择。
在点击劫持攻击下，无法防止请求伪造。不存在可以抵御点击劫持攻击的 CSRF 防御，因为在客户端无法区分真实点击和虚假点击。
OWASP在他们的 CRSF 预防电子表格中提到，CSRF 令牌防御工作的先决条件之一是没有 XSS 攻击正在进行。
在我看来，这也应该包括点击劫持，因为即使隐藏在 iframe 中的 CSRF 令牌也无法防御点击劫持。该请求是由用户直接点击伪造的。
所以最终我们并没有真正卡在 CSRF 和 Clickjacking 之间——CSRF 防御是针对不同类型的攻击，攻击者一方的权力要小得多。
因此，对于您提到的有关点击劫持和 CSRF 的问题：
这个问题的最佳解决方案（如果有的话）是什么？- 客户端点击劫持的最佳防御方法是打开一个新的浏览器选项卡或调整大小的浏览器窗口，其中包含您网站中的页面并在那里确认操作，正如@Zack 提到的那样。这就是 twitter 按钮的作用，在这种情况下也不能存在伪造请求。
所以有一个双重性，你似乎被困在 CSRF 和 Clickjacking 之间- CSRF 防御不适用于 XSS 或点击劫持攻击等情况，它们仅对不太强大的攻击有效（带有恶意链接的电子邮件，在论坛中发布恶意链接等.)
关于点击劫持没有好的可编程解决方案。一些公司起诉垃圾邮件发送者作为点击劫持的防御。其他人选择在用户单击 iframe 后显示弹出窗口，尽管这会降低用户体验，尤其是在单击按钮的情况下。这正是 Twitter 为“转推”按钮所做的。Facebook 目前为“Like”按钮部署了这种方法，只要请求来自黑名单域，就会要求确认。我听说 Googlebot 在使用其“+1”按钮（检查计算样式、元素重叠等）索引页面时执行了一些点击劫持启发式算法……</p>
--更新-- 当您说“小部件”时，如果您的意思是未经身份验证的人与之交互的应用程序之外的东西，那么请忽略此答案。我重读了您的问题，但您从未真正说明“小部件”的含义。我们的应用程序中有各种“小部件”。我以为这就是您所说的，只有经过身份验证的用户才能与之交互的应用程序中的所有内容。如果是这种情况，那么这个答案就是 OWASP 推荐的。
--原始答案-- “您不希望此请求易受 CSRF 攻击，因此您将 iframe 写入页面。” 不，不要制作 iframe，这样您就可以执行正常的 OWASP 建议来防止跨站点框架。
为了防止 CSRF 散列某些值，请将其包含在您的表单（或 ajax POST 数据）中，然后检查后端的散列值。如果匹配，则来自您的站点。您可以将越具体的数据放入散列中越好。
示例：当用户登录时，您可以创建一个长的随机字符串并将其绑定到他们的会话。此字符串绝不能在您的网站上或查看源代码时可见。然后假设用户提取了一些他们想要编辑的特定记录。然后，您可以使用您创建的用户长随机字符串，将记录主键附加到它，然后对它们进行哈希处理。该哈希的结果可以作为隐藏的形式包含在表单中。然后在你的后端，在你做任何事情之前检查隐藏的存在，如果它不存在，中止。如果确实存在，请获取用户随机会话字符串和他们提交的明文主键，对它们进行哈希处理，如果匹配，您就知道它来自您的站点。
即使您的网站已经编写好，也很容易在任何地方添加它（假设您的网站在所有页面上都包含一些单段代码，例如页脚）。制作散列值并将其放置在页脚某处的隐藏 div 中。然后你可以使用jQuery动态添加这个hash值隐藏到页面上的所有表单中。并且您可以使用 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) 等......我可以指出你正确的方向，如果它是其中之一。
我想我明白你在做什么。您希望允许任何站点对您的小部件进行 iframe，因此攻击者可以完全控制父级的源代码，并且可以创建点击劫持例程来强制用户单击小部件。
因此，iframe 将能够使用 CSRF 令牌，只要父框架无法读取令牌，它就会保护免受此类攻击。
我相信你知道点击劫持是一种与 CSRF 完全不同的攻击类型，需要不同的防御。
真的，如果小部件比实现两阶段身份验证更重要。使用http://twilio.com呼叫用户并让他输入密码。或向用户发送带有验证链接的电子邮件。或者要求用户在下次用户登录您的小部件网站时验证该操作。
如果您可以控制父框架，那么您将有更多选择。那么这将是一个 XSS 保护问题。
所以我防止点击劫持的方法有点过分了。看起来可以使用带有确认操作的弹出窗口来保护它。
由于 CSRF，您必须在 iframe 内...
不可以。您不能使用表单 cookie 和其他随机数技巧来修复 CSRF。你把它们放在哪里都没有关系。
所以有一个二元性，你似乎被困在 CSRF 和 Clickjacking 之间。这个问题的最佳解决方案（如果有的话）是什么？
要修复 CSRF，您必须通过修复具有注入或恶意代码的服务器、停止网络钓鱼电子邮件等来消除威胁。在没有良性环境的情况下，您需要重新验证用户身份（或提供另一个挑战/response 以确保交互式用户）。看：
解决 Clickjacking，利用 X-Frame-Options 或 Javascript 中的帧中断代码。但我认为两者都不是万无一失的。看：