在我们的应用程序中,用户可以通过按上下文菜单按钮来下载文件。目前,我们通过创建一个 iframe
并将其附加到 dom 来实现此功能,并使用指向服务器上文件位置的 src
属性。
我们最近向应用程序添加了 CSRF
保护,您可以猜到文件下载问题引起了问题。通过提供 csrf token 作为查询参数可以轻松解决此问题,但最终违背了保护方法的目的并将 token 暴露给监听器。
有没有办法使用具有可配置Http headers<的请求来触发文件下载(即按“下载文件”按钮后触发
? native 另存为...
对话框)/
请注意,即使数据本身不会暴露给攻击者的站点,我们也希望避免恶意页面向服务器发送多个如此繁重的请求,因此需要 CSRF 保护。
最后请记住,我们必须与 Internet Explorer 10 保持兼容,这可能会限制我们的选项(例如 anchor 元素中的 download
属性在该版本中不起作用)。
最佳答案
单独解决您的问题要求...
1) "Is there a way to trigger a file download using a request with configurable Http Headers?"
首先,通过实现 Origin HTTP header 添加保护以防止恶意外部源漏洞。这限制了仅访问内部请求和其他可信来源,让您掌控一切。请在此处查看 OWASP 的建议:
其次,从您的网站发出 HTTPOnly cookie。只要文件是从与托管 iframe 的页面相同的主机提供的,那么 iframe 就会自动将 cookie 传递回服务器。 cookie 中的值应与 CSRF token 相同。这是对当前正在传递的 CSRF token 的补充。此外,如果当前 token token 是通过 URL 或 HTTP header 传递,也没有什么区别。
最后,在服务器端验证 URL/ header 中的 token 是否等于 HTTPOnly cookie。这甚至可以防止网站内发生 XSS 攻击。
2) "want to avoid having multiple such heavy requests"
听起来您需要 DDOS 对策,而不是 CSRF 对策来满足此要求。上一点中的 CSRF 对策确保下载请求有效,但 CSRF 不关心重复多个有效请求。例如,如果攻击者实现了重复单击下载按钮的 AutoIt 脚本,您也会遇到同样的问题。
有多个层面来实现对策:
客户端层:首次单击后禁用下载按钮:
服务器/应用程序层:取决于所使用的应用程序容器。以 NodeJS 为例(与 IIS、WLS 和其他应用容器类似):
网络层:如果您正在寻找更强大的保护,那么建议通过网络和设备进行缓解:
3) "must remain compatible with up to Internet Explorer 10"
上述建议在某些版本的 IE 中受到限制:
CORS Origin header 与 IE 8+ 兼容:
HTTPOnly cookie 与 IE 6+ 兼容:
注意:实现细节被省略,因为它依赖于您的服务器端堆栈。
关于javascript - 文件下载的 CSRF 保护,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48582920/