文件下载的 CSRF 保护答案

【问题标题】：CSRF protection for file downloads文件下载的 CSRF 保护
【发布时间】：2018-07-12 23:15:00
【问题描述】：

在我们的应用程序中，用户可以通过按下上下文菜单按钮来下载文件。目前，我们通过创建 iframe 并将其附加到具有指向服务器上文件位置的 src 属性的 dom 来实现此功能。

我们最近向应用程序添加了CSRF 保护，您可以猜到文件下载问题出现了问题。这很容易通过提供 csrf 令牌作为查询参数来解决，但最终会破坏保护方法的目的并将令牌暴露给侦听器。

有没有办法使用可配置的Http Headers 请求来触发文件下载（即按下“下载文件”按钮后触发native Save as... 对话框）？

请注意，即使数据本身不会暴露给攻击者的站点，我们也希望避免恶意页面向服务器发送多个如此繁重的请求，从而需要 CSRF 保护。

最后请记住，我们必须保持与 Internet Explorer 10 的兼容性，这可能会限制我们的选项（例如，锚元素中的 download 属性在此处不起作用）。

【问题讨论】：

【解决方案1】：

单独解决您的问题要求...

1) “有没有办法使用带有可配置 Http Headers 的请求来触发文件下载？”

首先，通过实施 Origin HTTP 标头添加保护以防止恶意外部源漏洞。这限制了仅访问内部请求和其他受信任的来源，让您掌控一切。在此处查看 OWASP 的建议：
- Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
其次，从您的网站发出 HTTPOnly cookie。只要文件是从与托管 iframe 的页面相同的主机提供的，那么 iframe 就会自动将 cookie 传递回服务器。 cookie 内的值应与 CSRF 令牌相同。这是对当前正在传递的 CSRF 令牌的补充。如果当前令牌令牌是通过 URL 或 HTTP 标头传递的，也没有区别。
- Python example: How to set a cookie for iframe on the same domain
最后，在服务器端验证来自 URL/Header 的令牌是否等于 HTTPOnly cookie。这甚至可以防止网站内发生 XSS 攻击。
- CSRF protection - is a JWT and CORS whitelist combination sufficient?

2)“想避免多次如此繁重的请求”

听起来您需要 DDOS 对策而不是 CSRF 对策来满足此要求。上一点中的 CSRF 对策确保下载请求是有效的，但 CSRF 不关心重复多个有效请求。例如，如果攻击者实施了反复单击下载按钮的 AutoIt 脚本，您将遇到同样的问题。

有多层实施对策：

客户端层：首次点击后禁用下载按钮：
- Disable form button after click
服务器/应用层：取决于使用的应用程序容器。例如 NodeJS（IIS、WLS 和其他应用容器类似）：
- How to protect against distributed denial-of-service attacks in Node.js with Socket.io?
网络层：如果您正在寻找更强大的保护，那么建议通过网络和设备进行缓解：
- How do major sites prevent DDoS?

3) “必须与 Internet Explorer 10 保持兼容”

上述建议在某些版本的 IE 中受到限制：

注意：实现细节被省略了，因为它依赖于你的服务器端堆栈。

【讨论】：