0x01 CSRF的攻击原理
现在绝大多数的网站采用token验证，在审计的过程中我们可以直接在功能的核心文件内搜索token，如果没有token验证，那么这个功能大概率会出现CSRF。
黑盒测试的思路与代码审计基本一致，在关键功能处抓包查看有没有token验证，如果没有再次请求这个页面，删去referer，如果返回数据一致，那么大概率会出现CSRF
CSRF 百度上的意思是跨站请求伪造，其实最简单的理解我们可以这么讲，假如一个微博关注用户的一个功能，存在CSRF漏洞，那么此时黑客只需要伪造一个页面让受害者间接或者直接触发，然后这个恶意页面就可以使用受害者的微博权限去关注其他的人微博账户。CSRF只要被批量化利用起来其危害还是比较大的。
举个例子，比如笔者在新浪首页执行了一次搜索请求。
可以看到这里有个Referer的信息，Referer也就是请求来源地址，也就是说这个请求是从http://www.sina.com.cn这里发起的。然后去掉Referer，去执行这个请求，发现这个请求仍然可以进行正常的搜索，那么就说明这个请求没有判断请求来源也就是Referer，在请求头部也没有发现存在token的迹象，那么笔者可以判断此处存在CSRF，这个CSRF是没有任何危害的，但是换成其他请求呢？比如加关注，修改资料或者其他敏感操作呢？
0x02 CSRF漏洞成因及分类
1)第一种
请求直接是个GET请求，然后请求中没有token验证参数，然后还有一个固定的变量可以被控制。这种是比较常见的一种CSRF漏洞。这种漏洞的检测方法很简单：网页操作某功能，抓包后，如果发现满足上面条件，然后再去页面测试下，基本就可以确定存在不存在CSRF漏洞了。
实例
某微博站曾存在的一个漏洞，关注用户微博的请求如下（其中key的值是每一个用户独有唯一的)：
http://***.****.com/reflow/follow?resType=json&isAjax=1&key=226216966
笔者根据上面的测试方法进行测试发现无token，但是对referer做了校验，但是csrf的情况还是存在的，因为被攻击者的referer往往是和CSRF漏洞的GET请求是同域的，所以除非验证的相当的严格，一般情况下的验证是无效的，此类的站点输入微博类的站点，用户可以随随便便在上面发送微博，微博中可以带上该链接，只要受害者点击即可关注黑客的微博了。
2)第二种
请求是个POST请求，post请求中没有token参数，然后请求也没有验证referer信息。这种是存在CSRF情况最多的一种。这种漏洞的检测方法也很简单：网页操作某功能，抓包后，如果发现没有token等参数，然后就将referer信息设置为空，再次发包请求，如果请求成功了，就说明这里有CSRF漏洞。
如果有token等参数，可以尝试将token去掉，然后再将referer也去掉，进行验证。这种CSRF漏洞的利用，是需要在自己服务器构造一个form表单的，然后将服务器form表单的URL作为CSRF攻击进行利用的，或者用js代码生成form表单，或者用ajax实现。
实例
某微博主页刷粉丝，利用poc如下：
http://widget.******.com/plugin/followbutton/addfans">
3)第三种
请求是POST，post请求中没有token参数，但是验证了referer信息。然而可以将post请求改写为get请求，然后通过第一种情况下的那个方法利用。这种的检测方法，就是先执行了第二种的验证后，发现有对CSRF进行防御。然后将post请求改写为GET请求，发现仍然可以成功执行。漏洞成因是因为服务器端接收请求参数的时候，没有严格的用$_POST 而是用的类似于 $_REQUEST这种post，get请求的参数都可以接收的写法。
0x03 防御方法
增加随机、一次性、不可猜测的token做验证（token原理参考：https://www.jianshu.com/writer#/notebooks/50111482/notes/89392499）
beescms例子：
参考https://www.exploit-db.com/exploits/44952
实际操作：
(1)请求的数据包带有referer，没有带有token
（2）将其referer删除后重发数据包，依然能够执行添加管理员的动作
（3）使用burpsuite生成csrf 的攻击poc
（4）诱惑已登录系统的管理点击该按钮，然后自动添加一个管理员账号