CSRF

攻击原理及过程

1. 用户 C 打开浏览器，访问受信任网站 A，输入用户名和密码请求登录网站 A

2. 在用户信息通过验证后，网站 A 产生 Cookie 信息并返回给浏览器，此时用户登录网站 A 成功，可以正常发送请求到网站 A

3. 用户未退出网站 A 之前，在同一浏览器中，打开一个 TAB 页访问网站 B

4. 网站 B 接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点 A

5. 浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。

从上面的原理可以看出 CSRF 攻击，主要使用 cookie 的同源策略和 HTTP 请求携带 cookie 的问题导致的。那么我们就可以根据这个问题作出解决。

防御策略

• 验证 HTTP Referer 字段

在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。而对于 csrf 攻击其 referer 就会指向网站 B，而不是银行网站 A，所以我们可以根据 referer 去验证请求的安全。但是 referer 是由浏览器提供的，所以并不一定是安全的。所以存在第二种

• 在请求地址中添加 token 并验证

• 在 HTTP 头中自定义属性并验证

比如我们可以通过将用户的信息不是存放在 cookie 中，而是存放在用户 ajax 请求的请求头中的自定义属性中如 sid,那么每一次有关用户权限的接口就可以通过脚本手动添加 sid 的方式去防止 CSRF 攻击，但是对于其他的如静态资源的请求就不可以修改请求头中的数据，也会带来不便