如何保护小部件免受伪造请求
假设您有一个JavaScript小部件，当且仅当用户想点击它时，才需要向Web应用程序发出请求。 您不希望此请求容易受到CSRF攻击，因此您需要为页面编写iframe。 根据原点继承规则，父网站将无法读取CSRF令牌。 然而，点击劫持（或劫持）呢？ 由于CSRF，您必须位于iframe中，并且x框架选项无法提供帮助，帧同步器也适用。
攻击者将在小部件加载后将一个SVG掩码应用于iframe。 这个掩码将使iframe不可见。 此时攻击者可以将iframe的大小调整为页面的大小，或者使iframe在光标后面隐藏。 无论哪种方式，只要用户点击页面上的任何位置，iframe就会收到点击事件及其游戏结束。
所以有一个二元性，看起来你被困在CSRF和Clickjacking之间。 什么是最好的解决方案（如果有的话）这个问题？
点击小部件需要打开一个包含新页面的弹出窗口 - iframe不够好，它必须是一个新窗口 - 完全在您的web应用程序的控制之下。 确认该页面上的操作，无论它是什么。
是的，这有点不雅，但目前的Web安全架构并没有给你更好的选择。
在点击劫持攻击下无法阻止请求伪造。 没有可以抵御点击劫持攻击的CSRF防御措施，因为无法区分真正的点击和客户端的虚假点击。
OWASP在他们的CRSF预防电子表格中提到CSRF令牌防御工作的先决条件之一是没有XSS攻击正在进行。
在我看来，这应该还包括clickjacking，因为甚至隐藏在iframe中的CSRF令牌无法防止点击劫持。 该请求正在被直接用户点击伪造。
所以最终我们并没有真正卡在CSRF和Clickjacking之间 - CSRF防御意味着攻击者侧的权力较弱的不同类型的攻击。
因此，针对您提到的有关点击劫持和CSRF的问题：
这个问题最好的解决方案是什么（如果有的话）？ - 在客户端的clickjacking最好的防御措施是打开一个新的浏览器标签或一个调整大小的浏览器窗口与您的网站页面，并确认在那里的行动，@Zack提到。 这是Twitter按钮的作用，在这种情况下也不能请求伪造。
因此，存在一个二元性，看起来您被困在CSRF和Clickjacking之间 - CSRF防御不适用于XSS或clickjacking攻击等情况，它们仅对较弱的攻击（带有恶意链接的电子邮件，在论坛中发布恶意链接等）有效。）
点击劫持没有很好的可编程解决方案。 一些公司起诉垃圾邮件制造者是为了防止点击劫持。 其他人选择在用户点击iframe内部时显示弹出窗口，但会降低用户体验，尤其是在单击按钮的情况下。 这正是Twitter为“Retweet”按钮所做的。 Facebook目前对“Like”按钮采用这种方法，只要请求来自列入黑名单的域名，就会要求确认。 我听说Googlebot执行一些点击式启发式检测，同时用“+1”按钮索引页面（检查计算样式，元素重叠等）...
链接地址: http://www.djcxy.com/p/87117.html