如何保护小部件免受伪造请求

roo*_*ook 16 javascript browser security widget clickjacking

假设您有一个JavaScript小部件,当且仅当用户想要点击它时,才需要向您的Web应用程序发出请求.您不希望此请求容易受到CSRF的攻击,因此您可以向页面编写iframe.根据原始继承规则,父站点将无法读取CSRF令牌.然而,点击劫持(或劫持)呢?由于CSRF,你必须在iframe中,而x-frame-options无法帮助,对于帧破坏者也是如此.

在加载小部件后,攻击者将在iframe中应用SVG掩码.此掩码将使iframe不可见.此时,攻击者可以将iframe的大小调整为页面大小,也可以使iframe跟随游标不可见.无论何时用户点击页面上的任何位置,iframe都会收到点击事件及其游戏结束.

所以有一个二元性,似乎你陷入了CSRF和Clickjacking之间.什么是这个问题的最佳解决方案(如果有的话)?

zwo*_*wol 5

单击小部件需要打开一个包含新页面的弹出窗口 - 一个iframe不够好,它必须是一个新窗口 - 完全在您的Web应用程序的控制之下.在该页面上确认操作,无论它是什么.

是的,这有点不优雅,但目前的Web安全架构并没有为您提供更好的选择.


Ang*_*ity 5

在点击劫持攻击下无法阻止请求伪造.没有可以抵御点击劫持攻击的CSRF防御,因为没有办法区分真正的点击和客户端的虚假点击.

OWASP 在其CRSF预防电子表格提到, CSRF令牌防御工作的前提条件之一是没有XSS攻击正在进行中.

在我看来,这还应该包括点击劫持,因为甚至隐藏在iframe中的CSRF令牌也无法抵御点击劫持.该请求是通过直接用户点击伪造的.

因此,最终我们并没有真正陷入CSRF和Clickjacking之间 - CSRF防御意味着针对不同类型的攻击,其中攻击者的攻击力较低.

那么对于你提到的有关点击劫持和CSRF的问题:

  • 这个问题的最佳解决方案(如果有的话)是什么? - 在客户端进行点击劫持的最佳防御方法是打开一个新的浏览器选项卡或一个调整大小的浏览器窗口,其中包含来自您网站的页面并确认其中的操作,如@Zack所述.这就是twitter按钮的作用,并且在这种情况下也不能请求伪造.

  • 因此存在二元性,似乎你陷入了CSRF和Clickjacking之间 - CSRF防御并不适用于XSS或点击劫持攻击等情况,它们只对抗不太强大的攻击(带有恶意链接的电子邮件,在论坛中发布恶意链接等) .)