随着互联网的高速发展，web安全问题显得愈发重要。

什么是CSRF

CSRF全名是Cross Site Request Forgery，翻译过来，即跨站请求伪造。那它是如何伪造的呢？请看下面的案例：

假如用户登录了a网站http://www.a.com，网站有一个get请求 xxx/delete?id=1 用于删除用户个人信息。这时候弹出一个引人入胜的广告被用户点击，或者用户突然有更重要的访问其他网站的需求而直接开了一个tab，暂停了a网站的访问。

以上等原因用户来到了b网站（也可能是钓鱼网站） http://www.b.com。 b网站内已经藏好了一张不可见的图片 <img src="xxx/delete?id=1" />；等用户返回a网站时，发现自己的个人信息不见了！

没错，就是这个看不见的图片，发送了删除个人信息的请求到a服务器，而a服务器又缺少相应的防御措施，引起了灾难。类似的场景也可能是用户的财产损失、账号注销……等等，倘若该链接通过消息或发帖接口发送给好友或公共平台，好友或平台用户查看到后，攻击就会像病毒一样散播开来（参照百度曾经的CSRF Worm）。

怎么发起CSRF攻击

这里并不是教大家怎么搞坏事，我们知道，知己知彼，方能百战不殆。要知道怎么防御，总得知道攻击的特点才好下手不是？

我们知道http是无状态的，即不会区分哪个用户、哪个请求，不会记录请求状态。所以才会有session、cookie用以区分用户和校验身份。这一步通过了，请求就认为是合法的了。所以说我们只要拿到了这个身份凭证（session、cookie），岂不是就可以冒充用户为所欲为了？

那么在用户登录了a网站 http://www.a.com后，又跳到（或打开）了b网站http://www.b.com。我们在b网站里有这样的一个标签

<img hidden src="http://www.a.com/xxx/delete?id=1" />

这个标签一经加载，a网站的服务器就收到了这个删除请求。只能用img标签攻击吗？ Too young, too simple. 具有src属性的标签都可以的。那有人说把请求 /xxx/delete?id=1 方式改为post就行了吧？ Too young, too simple, too！ post请求我们可以这样攻击：

<form hidden action="http://www.a.com/xxx/delete" method="post">
    <input value="1" name="id" />
    // 假如还需要其他参数，这里再搞几个表单出来
</form>
<script>
window.onload = function(){
    document.forms[0].submit();
}
</script>

怎么防御CSRF攻击

根据上面的攻击过程，我们发现只要伪造了session或cookie，后面每一步都挺顺利的。防御的话，就是要它不那么顺利。

验证码
这是最简洁有效的方式，登录、注册、防止机器刷票我们见多了。只可惜我们不能每一步每个请求都这么干。
Referer Check(至于为啥Referer 不是写作Referrer，那是历史原因，将错就错吧)
如果一个请求来自域www.a.com，那么服务器验证客户端的请求来源时，HTTP请求头的Referer字段值就是www.a.com。这一步需要服务端来实现。问题在于，服务器不是什么时候都能取到Referer，甚至一些情况下是不发送Referer的（原因可自行查阅）。
Anti CSRF Token
CSRF 的本质是所有被伪造攻击的请求的参数都是可被猜测到的。那我们在请求参数里加上随机生成的token，攻击成本将瞬间扩大。token必须满足不可预测，假如我们随机产生的token是一个8位数字，那攻击者暴力破解是分分钟的事。token必须同时满足保密性和随机性。

参考资料《白帽子讲Web安全》，吴翰清·著