Part1 前言
此案例源于一次对金融系统的漏洞挖掘，主要漏洞点集中在CSRF跨站请求伪造漏洞上，印象比较深。这个系统经过各个厂商N轮测试了，功能点又少，漏洞挖掘的难度很大，但是最终还是挖到了几个影响较大的CSRF漏洞，接下来把测试过程分享给大家。
Part2 技术研究过程
- CSRF漏洞测试
CSRF漏洞的测试很简单，首先使用burpsuite对重要操作抓取一个数据包（这里用虚拟机演示），这些操作可以是删除某件商品、下单某个商品等。如下图所示，整个数据包无token校验，说明可能存在CSRF漏洞。
找到无token校验的操作页面之后，就需要使用工具真实判断一下是否存在CSRF漏洞了。
- Burpsuite的CSRF测试功能
首先推荐burpsuite这款工具，它自带了一个CSRF漏洞测试模块。在burpsuite界面点击右键，选择“Generate CSRF POC”功能，burpsuite会自动生成一个CSRF的测试页面：
点击“Test in browser”按钮可以得到一个URL地址：
打开这个url，点击“Submit request”按钮即可测试CSRF是否成功。
- CSRFTester工具的使用
这是一个很老牌的工具了，是15年前的工具，由OWASP组织出品，可以自动生成各种payload进行CSRF漏洞测试，非常方便。首先浏览器设置一个代理127.0.0.1:8008，这个代理是CSRFTester自带的，浏览器的所有流量都会经过CSRFTester这个工具并记录下来。
选择一个payload类型，比如iFrame的，这款工具会自动生成一个html文件，将此文件传到自己的服务器上，发给用户进行浏览，就可以进行CSRF漏洞验证了。
- Referer校验绕过
很遗憾，经过上述两款工具的测试，CSRF均未成功，后来发现程序对Referer请求头做了判断。接下来就需要判断，程序对Referer的校验是否不完善。举个例子，假设目标网站是http://test.com.cn，攻击者的域名是http://xxxxxx.com，可以尝试对Referer值进行一系列变换，如http://xxxxxx.com/test.com.cn，http://test.com.cn.xxxxxx.com等，但是一通测试下来发现，始终没法绕过Referer的校验。
最后发现当Http请求没有设置Referer头时，CSRF校验就可以绕过去了。众所周知，当用户点开攻击者构造的CSRF页面时，用户浏览器发起的http请求的Referer值，一般都会带上攻击者的来源url的，那么如何将这个Referer置空呢？方法也有很多种，但是靠谱的方法极少。
1 在test.com.cn子域名下面找到一个XSS，在这个XSS下构造一个CSRF漏洞，这个方法有点牵强，而且本次案例test.com.cn下面没有子域名。
2 利用data:协议
如果浏览器地址栏是file://协议开头的，则此HTML页面向任何http站点提交请求的Referer值都是空的。可利用的协议有以下几种：ftp://,http://,https://,file://,javascript:,data:。可惜的是，这个方法本地测试成功，实战没成功。
<html>
<body>
<iframe src="data:text/html;base64,PGZvcm0gbWV0aG9kPXBvc3QgYWN0aW9uPWh0dHA6Ly93d3cuaGV4aWUuY29tL2Q PGlucHV0IHR5cGU9dGV4dCBuYW1lPSdpZCcgdmFsdWU9JzEyMycvPjwvZm9ybT48c2NyaXB0PmRvY3VtZW50LmZvcm1zWzBdLnN1Ym1pdCgpOzwvc2NyaXB0Pgo">
</body>
</html>
对base64进行解密，结果如下：
3 添加<meta>标签
在html页面中添加如下代码：<meta name="referer" content="never">，经过测试，此方法完美将Referer请求头置空。最终实战测试成功。
Part3 修补CSRF漏洞的方法
1 重要操作添加验证码
对重要的业务操作，可以加上验证码或者手机验证码二次认证，可以有效地阻止CSRF漏洞攻击。这样即使用户浏览器了攻击者发来的CSRF链接，也会因为验证码不正确导致攻击过程停止。
2 添加Origin、Referer头校验
服务端会对Referer、Origin头信息进行校验，判断是否从信任域跳转过来的。这两个消息头的区别就是，Origin不包含URL路径信息，Referer请求头会把URL的完整路径暴露给第三方网站。因此，服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer值。
3 CSRF的token校验
服务端会返回一个token放在前面页面上，用户点击网页，浏览器会带上前端页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从攻击者伪造的站点或者第三方站点发出的请求，那么将无法获取到 前端页面的CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。
4 在http请求属性中token校验
这里不是把CSRF token放在GET请求或者POST请求中，而是放在事先定义好的http消息头当中。这样一来，假设用户浏览了攻击者构造好的CSRF页面，由于浏览器不会带上http消息头的CSRF Token值，导致服务端校验不通过，攻击失败。
专注于网络安全技术分享，包括红队、蓝队、日常渗透测试、安全体系建设等
每周一篇，99%原创，敬请关注
