浅谈CSRF的攻击与防护

随着互联网的高速发展，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安全》，吴翰清·著