小白必学篇：CSRF漏洞总结

1. 什么是CSRF漏洞？

跨站请求伪造，也称XSRF，本质是攻击者盗用了我的身份去发送恶意请求。这里区分一下XSS，以免概念混淆。CSRF是借助用户的权限完成攻击，攻击者从头到尾没有拿到用户的权限，然后就可以在受害者不知情的情况下执行了恶意操作；而XSS是直接盗取了用户的Cookie，从而登录到用户的后台修改相关信息。（CSRF和XSS的区别）

2. 造成CSRF漏洞的主要原因？

l 请求所有的参数均可确定

l 请求的审核不严格，比如只验证了Cookie

3. 如何挖掘CSRF漏洞

特征点：A.增删改查的交互点；B.无验证码，无token等；C.判断服务器是否对referer头判断，是的话尝试能不能绕过正则。

常出现在修改用户个人信息，重置密码等等这些功能模块。

4. 利用CSRF漏洞的前提条件

(1) 受害者登录受信任网站A，并在本地生成Cookie

(2) 受害者在不登出网站A的情况下访问恶意网站B

(3) 猜到所有表单或者URL参数中的值

5. 如何利用CSRF漏洞

在利用之前，要知道CSRF漏洞有什么类型，分别有GET型和POST型。这里用Pikachu靶场做例子，可能大家在网上看到用这个例子讲解的有很多，但是不要急，继续往下看。

登录用户，lucy-123456，跳过，可以看到有修改个人信息，点进去，直接Submit，抓取数据包。

看到数据包，属于GET型，又无Token验证，那么就可以尝试伪造URL了，实战过程中也一样。但是实战过程中，我遇到POST的比较多，而且通常有Token验证。这里伪造URL，根据上图：

http://192.168.0.101/guixianren/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=gay&phonenum=13500000000&add=test&email=hacker%40pikachu.com&submit=submit

需要修改的信息这里我已做了更改，这就是恶意的URL，现在只需要诱惑受害者点击此链接就行。但是问题是现在都2020年了，这种链接，换个稍微长眼睛的人都能看出来是恶意的，不会随随便便点，那我们可以做成短链接嘛！

访问这个短链接试试。（建议用火狐浏览器）

修改成功了，接着下一个案例！别打瞌睡，到POST型，同样操作，修改个人信息，抓包。

GET型可以伪造URL，但是POST型不一样，它不能伪造URL，那该怎么办呢？我们可以伪造一个自动提交表单的页面。（补充：这里依然没有Token验证）

这个post.html就是我们伪造的自动表单提交页面，如果在实战中，你真的想让别的用户能访问你这个文件，你必须要放在自己搭建的服务器下。因为现在是用phpstudy搭建的本地环境测试，那么攻击者是我，受害者也是我。所以大家要屡清楚我的操作。接下来访问一下自己的文件。（http://192.168.0.101/post.html）

接着会自动跳转到这个页面。

可以看到，这里的个人信息已经被修改，可是却不是受害者本人修改的，到这里已经达到我的目的了。以上案例，可以看得出靶场就是靶场，情况太过理想，大部分实战情况下，基本都会有token验证，token是随机的，每次请求都会随机生成，然后后台就会对这个随机token进行验证。（对于绕过token，望师傅们指点。）

6. CSRF漏洞造成的危害

l 篡改目标网站上的用户数据信息；

l 盗取用户隐私数据；

l 配合XSS漏洞造成更大危害；

l 传播CSRF蠕虫。

7. 当发现CSRF漏洞该如何修复？

加入token机制，通过token或者session来判断当前用户身份。

8. 如何防范CSRF漏洞

(1) 尽可能使用POST方式；

(2) 设置验证码，能够很好遏制CSRF攻击，但是增加验证码降低了用户的体验，所以网站不可能给所有的操作都加上验证码，所以只能将验证码作为一种辅助的手段，在关键业务点设置验证码；

(3) 检查HTTP请求的Referer字段，但是这种办法的有效性不高，第一，可以抓包修改该字段；第二，在https跳转到http的情况下，浏览器出于安全考虑，不会发送referer，服务器就无法进行检查了，而且如果该网站同域的其他网站有XSS漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。所以说有效性不高。（不靠谱的原因是服务器并不是随时都能获得Referer，只能监控是否发生，并且不能防范统一域上的CSRF攻击）

(4) 加入Anti-CSRF-Token，也就是发送请求时在HTTP请求中以参数的形式加入一个随机产生的token（一次性随机值），并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域Cookie中这个token值，会进行校验该请求当中的token和Cookie当中的token值是否都存在且相等，当判断出存在且相等才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。（个人觉得此方法能杜绝大部分CSRF攻击，那还有小部分通常是因为网站存在XSS漏洞，从而获取到用户Cookie，这就是CSRF+XSS组合拳）。

参考资料：https://www.cnblogs.com/yzycoder/p/5741507.html