【csrf 】攻击和防御

常规安全验证 

http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 // 通过安全验证
http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory //不能通过安全验证

csrf骚操作

黑客伪站链接 src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”
广告连接诱导-》当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行
而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求Bob的认证信息但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息 这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，这个操作对服务器来说时合法的！！！

csrf 原因

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。

关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie/localStorage 之中

方案

1.验证 HTTP Referer 字段  这个方案依赖浏览器对http的实现，并且，低版本ie浏览器可以修改这个字段，并且，存在客户隐私问题
2.在请求地址中添加 token 并验证（非ajax请求）
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token
token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对  http://url?csrftoken=tokenvalue  在前端调用请求的时候，需要做相关参数处理，容易漏掉

3.在 HTTP 头中自定义属性并验证 通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中，局限于 Ajax 方法中对于页面局部的异步刷新（ajax请求）

4.token 其实可以存储在sessionStorage中(会话级别的存储)，不过请求参数中的token和sessionStorage中的token不能完全相同，依赖一个中间的secretkey来进行比较。黑客要么知道secret key，要么必须同时知道参数中的token和sessionStorage中的token，才能成功发动攻击。

---

https://blog.csdn.net/stpeace/article/details/53512283   csrf 攻击和防御