CSRF, 全称 Cross-Site Request Forgery, 跨站请求伪造, 也称 session riding, 这个别称很形象.
是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法. – 维基百科
CSRF 是一种依赖 web 浏览器的、被混淆过的代理人攻击（deputy attack
举个例子, 假如 A 站点中有用户登录功能, 登录后有个转账的功能, 是表单 POST 跳转提交到一个 url /do_transfer. 用户 🐷 在 A 站点登录, 然后又打开了 B 站点.
B 站点中页面构建了一个表单, 是 POST 跳转提交到 A 站点中的 /do_transfer, 转账目标是攻击者. 那么如果这个表单提交了, 用户 🐷 的账户余额就会被盗取, 这就是一个 CSRF 攻击样例.
那么列举一下其中关键的几个点:
那么防范这种攻击的方法, 主要是围绕上面第三点来展开的, 也就是需要检查来源, 目前主要有两步:
前几天看到了同事写的一份后端项目重构方案, 这是一个前后端分离的项目, 并且没有用户功能, 后端只需要提供 API. 方案中大篇幅介绍了要使用一种 “向页面或客户端中注入 token” 来解决 “裸 API” 的问题, 目的是防止恶意调用. 其实一句话可以概括: CSRF token. 当然, 其中说到一些 token 生成时接口加解密等等, 这都不影响.
我认为, 一个不需要认证登录的 API 是没必要做 CSRF 防范的, 因为本身并不达到上面总结的几个点. 针对这个项目解决恶意调用, 我目前能想到的方法是:
虽说无法百分百解决被恶意调用的问题, 但应该能把影响控制到最小, 没办法, 谁让你没登录呢 🤪.