浅谈CSRF漏洞

最近学习owasp top10漏洞，想把自己的学习心得写下来，也算对自己的一种鞭策。

CSRF漏洞简述

CSRF（跨站请求伪造）漏洞，一般来说，是攻击者利用一个伪造的请求诱骗用户点击，用户点击之后攻击者就可以冒充用户身份去做一些不合法的操作（最常见的就是修改密码）。

攻击原理及条件

首先，假设我们登录了某个合法的网站，但是呢这个网站存在csrf漏洞。通常呢，一个网站会利用cookie记录客户端的身份，这样做主要就是为了用户再次登录该网站时能够减少一些繁琐的输入账号密码操作。为了更好的理解这个cookie，下面就以CSDN为例，

这个类似的页面相信大家在许多网站登录时都会看到，当我们点击保存时cookie就会自动的保存在浏览器的缓存中。当再次访问该页面时就会直接进入我们已登录的状态。但是俗话说的好，功能越方便的网站往往伴随着更高的安全风险。既然都可以不用输入账号密码了，那不法分子是不是也可以利用这点干点坏事呢，于是，他们就构造了恶意链接，想尽各种办法诱骗用户点击。比如一些🎣短信，像这种相信大家都不陌生：

哈哈哈，这时就有人说了，像这种短信上的链接作为正人君子的我才不会点呢。

当然了，骗子也是知道这种情况，普通的短信、邮件已经不好起作用了，但是呢，他们的想法也变得更加精明了，竟然明的不行，那就来暗的，他们通常将这些恶意链接插入到某些正常网页的代码中，当你打开一些看似很正经的网站时，他们很有可能直接在后台就完成操作了。所以说劝诫各位小伙伴，遇到不熟悉的链接千万不要无视风险，继续访问了。否则就要去警察局和警察谈谈心了。

说到这里，还得郑重申明一点，CSRF与XSS的区别，虽然罪魁祸首都是点击造成的。但是XSS攻击的条件更加简单，也更加危险，并且XSS可谓是防不胜防，毕竟它是直接针对客户端进行攻击的，具体的我之后会出另一篇文章来专门解释XSS。而CSRF它属于服务端攻击，他并没有去盗取你的信息，而是利用你的信息去骗取服务端的信任。并且通常情况下，要想成功利用CSRF，还必须让你保持与服务端的会话状态，因为当你关闭某个页面的时候session也就会失效，具体想了解session的话还请各位自己上网查找。

csrf实战应用

1. get型：直接构造链接欺骗

 以pikachu靶场为例：
首先先进入csrf的登录页面，我们要先输入用户名和密码

这里可以看到有哪些账号、密码

进入登陆页面后，可以看到我们的有关信息，然后点击修改个人信息

选择具体的信息进行修改并提交，然后进行抓包

发现数据包并没有做token值检验且直接通过url中的参数进行修改数据，于是我们可以通过这个url构造一个恶意链接来诱骗当前登录的用户点击来修改数据。

虽然是模拟环境，但最好还是把这个恶意链接搞得看起来别太假哈哈，这里推荐一个在线网站https://www.c1n.cn/（做实验免费用一下就行了，千万别去干坏事，有需要可自由充值），这里我把手机号改成8888888。

当我们在登录状态下访问这个短网址时就会自动的把手机号给修改掉。

 

2. post型：通过构造表单并插入链接里进行欺骗

这里利用burpsuite自带的poc生成工具


将这段代码保存在我们构造的链接里，在真实环境下应该放在服务器上，这里为了方便我就直接点击了，不过个人感觉burpsuite的这个代码不太好用因为他还需要再次点击，且这个一眼假😓

最后也是成功修改，如果遇到真实环境，还请大家自己构造payload。

csrf漏洞挖掘

抓包看有没有referer字段和token值检验，如果有referer字段可以去掉然后再提交看是否响应，如果响应基本上可以确定有CSRF漏洞。也可以利用自动化工具CSRFTester。

csrf防御方法
 

验证码

最安全的一种方法，因为可以和用户直接进行交互，但是由于操作繁琐不能在所有页面都添加验证码，可适当在最重要的页面添加此功能

token值检验

在用户登录后，服务端会生成一个一次性的Token，一般这个Token会保存在服务端返回给用户的页面中的一个隐藏域里。每次用户向服务端发送操作请求时会附带上这个Token，服务端也会验证这个Token是否和分发给用户的Token一致，如果请求中不存在Token或Token不正确，即判定这个请求为非法请求。

referer头检验

一般来说，用户提交的站内请求的来源（也就是Referer字段）应该是站内地址，当检测到来自是不同域名时，就会怀疑用户受到了CSRF攻击。

参考链接：CSRF漏洞原理攻击与防御（非常细）-CSDN博客