CSRF的攻击和防御

什么是CSRF

Cross Site Request Forgery（跨站请求伪造），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

CSRF实例

用户萌新登录了银行链接www.bank.com，萌新看见了www.bank.com上有个抢红包按钮，于是点击
hacker将抢红包按钮的代码修改如下




    
    Title

可以看到，实际上当萌新点了这个按钮之后，执行的逻辑是从mengxin的账户里转10000到hacker的账上。
而此时，由于萌新刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有萌新的认证信息，所以银行认为发起这个请求的就是萌新本人，所以就转账成功，这个时候就GG了。

在这个例子中，由于浏览器的同源策略限制，实际上hacker并无法窃取到萌新的个人信息，而是直接利用了萌新未过期的个人信息直接伪造他的身份发起了转账请求。

如何防范

可以看到，CSRF对用户来说很伤。那到底有什么办法可以进行防范呢？目前常用的有两种防范方法，下面一一讲解。

一、HTTP referer字段验证

在HTTP协议中，有这么一个字段叫referer，它记录了网站请求的来源地址。比如上面的银行转账例子，当萌新登录www.bank.com后，点击任何原网页的链接和按钮，请求来源都是www.bank.com。但当萌新点了被纂改后的链接或者按钮后，他的来源地址变成了www.hacker.com。所以，银行方就可以这么验证，每次请求都去验证下HTTP的referer字段，看是否是www.bank.com，如果是认为合法则受理请求，如果不是则拒绝。

优点：只需要在请求收到后添加验证逻辑即可，对于已经有的项目来说很是方便。
缺点：
(1) 由于referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全（事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值）。
(2) 而由于referer会记录访问来源，某些用户会认为这侵犯了自己的隐私权，所以浏览器是允许设置发送请求的时候不提供referer。这样就导致了银行收不到referer从而判定请求非法而拒绝。所以此法并非万无一失。

二、服务端验证token信息

用户在提交请求的时候添加服务端返回的随机token信息，服务端判断这个token是否与自己提供的一致，若一致则视为合法请求，否则非法。添加的方式主要有两种：

往a链接上手动加上token参数，或在form表单中藏csrf值当用户提交的时候随之发送

优点：不用担心referer被禁用问题，相比于referer的可纂改和对第三方浏览器依赖性较强来说更加安全可控。
缺点：麻烦，要给每个form和a加上这个token字段比较麻烦，容易遗漏。如果是遍历页面所有的a或form还要注意那种允许用户自行填写连接的情况。比如在博客里用户自己写了个a连接也被加上了token，这样hacker也可以利用这个token为所欲为了。

通过 XMLHttpRequest 这个类，封装后可以给每次请求加上 csrf_token 。

优点：直接一次性就给所有请求添加了token值，不用每个遍历不担心弄错和遗漏。
缺点：对于不是采用此种 XMLHttpRequest 方式发起请求的网站来说不适用。

总结和注意要点

以上所讲的方式各有优缺点，可以根据自己网站的已有情况自行选择。但要注意以下几点：

token 保存在 Session 中：假如 token 保存在 cookie 中，用户浏览器开了很多页面。在一些页面 token 被使用消耗掉后新的 token 会被重新种入，但那些老的 Tab 页面对应的 HTML 里还是老 token。由于token变成新的，这就会导致用户几分钟前打开的页面（存的是老token）不能正常提交使用。
尽量少用 GET：正如上面的抢红包例子，当用户点击之后，hacker可以获得referer网址来源信息，而对于 GET 请求来说，参数是直接加到链接后的，所以来源
url 为www.bank.com?csrf_token=abcdefg123，所以hacker就可以获得用户的 token 信息做一些操作了。