为什么跨域Ajax是一个安全问题？

JPunyon:为什么要将漏洞留在新功能中

你不会再造成任何不安全感.您只是想要以良好的方式使用它的开发人员感到不安.任何想要将此功能用于邪恶(也称为真棒)的人都可以使用其他方法来实现它.

结论

我将bobince的答案标记为正确,因为他指出了关键问题.因为XMLHTTPRequest允许您使用凭据(cookie)发布到目标站点,并读取从站点发回的数据,以及发送人员凭据,您可以编排一些提交一系列表单的JavaScript,包括确认表单,完成生成的任何随机密钥,以防止XSRF.通过这种方式,您可以浏览目标网站,如银行,银行的网络服务器将无法确定是否只是提交所有这些表单的普通用户.

为什么不允许Ajax HTTP请求跨越域边界.

因为AJAX请求是(a)使用用户凭据提交的,并且(b)允许调用者读取返回的数据.

这些因素的组合可能会导致漏洞.有建议添加一种省略用户凭据的跨域AJAX.

您只需在文档中添加img,script或iframe元素即可

这些方法都不允许调用者读取返回的数据.

(除了脚本之外,它是故意设置允许的,允许的跨域脚本编写 - 或者某人做出可怕的蠢事.)

你可以在不使用它的情况下进行XSS攻击.发布到第三方网站

这不是XSS攻击.这是一个跨站点请求伪造攻击(XSRF).有一些已知的解决XSRF攻击的方法,例如包括一次性或加密令牌,以验证提交是故意来自用户的,而不是从攻击者代码启动的.

如果您允许跨域AJAX,您将失去这种安全措施.攻击代码可以从银行站点请求页面,读取其上的任何授权令牌,并在第二个AJAX请求中提交它们以执行传输.这将是一个跨站点脚本攻击.

POST之间的一个重要区别:

和Ajax是在做任何POST后,浏览器将替换页面并在执行Ajax调用之后 - 而不是.POST的结果将是:


用户清楚可见.
攻击将在此时停留,因为来自响应页面my-bank.com将采取控制.没有银行会实施一键转移.


如果允许跨域Ajax,XSRF的场景将如下所示:


用户以某种方式访问www.bad-guy.com.
如果my-bank.com在浏览器的其他实例中没有打开页面,则攻击不成功.
但是如果打开了这样的页面并且用户已经输入了他的用户名/密码,这意味着在浏览器的缓存中存在该会话的cookie.
页面上的JavaScript代码www.bad-guy.com进行Ajax调用my-bank.com.
对于浏览器,这是一个常规的HTTP调用,它必须将my-bank cookie my-bank.com发送给它并发送它们.
银行处理此请求是因为它无法将此呼叫与用户的常规活动区分开来.
JavaScript代码可以读取响应这一事实并不重要.在攻击案例中,这可能没有必要.真正重要的是计算机前面的用户不知道这种交互发生了.他会在www.bad-guy.com页面上看到漂亮的图片.
my-bank.com如果需要,JavaScript代码会进行其他几次调用.


要点是不需要注入或任何页面篡改.

更好的解决方案可能是允许呼叫本身但不发送任何cookie.这是一个非常简单的解决方案,不需要任何广泛的开发.在许多情况下,Ajax呼叫进入不受保护的位置,不发送cookie不会受到限制.

现在正在讨论的CORS(跨源资源共享),其中包括发送/不发送cookie.