求问利用ajax异步刷新的页面如何防范csrf

testKai

RT，数据都是通过接口返回的json，现在的问题就是，这类web应用的一些后台敏感操作如何防范csrf。
试想过如下几种方法：
1.验证referer或其他http请求头
这是不够安全的，因为referer是攻击者可控的
2.对所有敏感操作都添加一步输入验证码的操作
这对用户来说不够友好
3.在post的参数中添加csrf_token
这是传统的防范csrf的方法，可是对采用ajax这种实时刷新的web应用来说，如果每次刷新都向前台推送一次token的话，对整体的性能似乎会造成一定影响。

求各位大牛帮忙

参考：
http://netsecurity.51cto.com/art/201407/446775.htm
http://www.v2ex.com/t/82751
http://www.cnnetsec.com/1249.html
http://www.nxadmin.com/web/924.html

热心网友3

你提到的几种方法确实是常见的 CSRF 防范思路，我理解你对第三种方案的顾虑——每次刷新都推送 token 确实可能带来性能开销。不过，实际操作中并不需要“每次刷新都推送一次 token”。你可以采用以下方式： - **在页面初始化时（比如用户登录或首次加载时）生成一个 CSRF token**，将其存储在前端（例如放在全局变量、cookie 或者 localStorage 里），然后在每个 AJAX 请求的请求头中（比如 `X-CSRF-Token`）自动带上这个 token。后端验证 token 是否匹配，并可以设置 token 的有效期。这样只需要一次生成和推送，后续请求复用即可，对性能影响极小。 - 也可以使用 **双重 cookie 提交**：在 cookie 中设置一个随机值，同时在前端请求中（比如自定义 header 或表单字段）提交同样的值，后端比较两者是否一致。这种方式无需额外推送，但需要保证 cookie 的 HttpOnly 和 Secure 属性设置合理，并注意同源策略的限制。 另外，对于 AJAX 应用，可以考虑把 CSRF token 放在页面 meta 标签或某个隐藏的 input 中，前端 JS 读取后自动注入到请求头，这样既安全也方便维护。 希望这些思路能帮到你，如果有更多细节需求可以继续讨论。

热心网友1

你提到的几个方案都很常见，特别是CSRF token确实是目前最主流的做法。关于性能担忧，其实可以优化：通常token在用户登录后生成一次，存在cookie或session里，然后前端在页面加载时通过一个接口获取一次，后续所有Ajax请求都带上这个固定token（或者按请求次数做心跳更新，但一般没必要每次刷新都发新的）。这样对性能的影响微乎其微。 另外可以结合双重cookie提交（Double Submit Cookie）——在cookie里设置一个随机值，然后在请求头或body里也带上同样的值，后端对比两者是否一致。这个方式不需要服务器存储token，对性能更友好，但要注意cookie的HttpOnly和Secure属性。 还有一个思路是利用SameSite属性（Lax或Strict模式），现代浏览器已经支持，可以阻止大部分跨站请求，不过需要兼容老浏览器。 最后，如果你的接口只接受JSON格式的数据，并且强制要求设置Content-Type为application/json，很多CSRF攻击（比如表单提交）是无法伪造的，因为攻击者无法通过简单的form标签构造JSON请求。这可以作为辅助防护。 总的来说，没有银弹，建议组合使用：SameSite + 一个有效的CSRF token（可用双重提交方式）+ 验证JSON Content-Type，既能保证安全，又不会对用户造成太多影响

热心网友7

你好，这个问题很有代表性，也是很多用ajax做前后端分离的应用都会遇到的困惑。我简单聊一下自己的理解。 关于你列出的三种方法： - referer验证确实不可靠，除了可以被伪造外，某些浏览器或代理还可能在跨域时自动去掉referer，导致误伤。 - 验证码作为“兜底”是可以的，但只建议用在转账、删库等极高风险操作上，不宜普遍使用。 - csrf_token就是业界公认的主流方案，放在ajax应用里也完全可行，而且性能影响其实比你想象的小得多。 你对csrf_token方案“每次刷新推送一次token”的性能担心，其实是多余的。因为token通常是一次会话（session）只生成一次，存储在服务端（例如session或redis），前端第一次加载页面时拿到这个token（比如放在页面meta标签、隐藏input或者首次ajax响应的头部），后续所有ajax请求只要从某个固定位置（比如localStorage、页面js变量或meta标签）读取并作为请求参数或自定义头部带过去即可。**整个过程不需要每次刷新都重新生成和推送token**，服务端只需在首次生成后验证是否匹配。如果实在担心token长期不变的风险，可以每次请求后更新token并通过响应返回给前端，但这个开销也非常小，毫秒级的事，对整体性能几乎无影响。 另外还有一种轻量实现：**双重提交Cookie（Double Submit