DWVA手把手教程（三）——CSRF漏洞

DWVA手把手教程(三)——CSRF漏洞

好久不见。

嘤，，别打，，别打脸，，

最近出差没周末，

还要加班到九点，

哭唧唧。

也是在工作过程中发现，

好多开发对CSRF漏洞很不理解，

更谈不上修复它了，

没关系，今天我们来复现一下。

要不要给他们开发安利下我们的公众号 /手动滑稽/

我想多少一句，

安全和开发不应该是敌人！

We are family！！！！

为什么这么说呢，

最近总感觉会被那一屋子开发群殴，

尤其是项目结项这几天，

嘤，如果见不到我。。。

--------哗啦啦丽丽的分界线----------

欢迎来到CSRF漏洞章节，在此，请允许作为#灵魂画师！！#的我图文并茂的为大家简单介绍一下CSRF漏洞：

CSRF跨站点请求伪造(Cross—Site Request Forgery)

你可以这样来理解：

攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，

但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

如下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。

RabbitMask是谁？是情书吖0.0.。。欢迎百度RabbitMask，空降博客园，教程看心情同步~

CSRF攻击攻击原理及过程如下：

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

在此处DWVA的CSRF漏洞中，我们可以看到重置密码操作就是一个网站认为完全合理同时也是攻击者意图的一个操作。

敲黑板，划重点：CSRF漏洞的判定：修改referer头或直接删除referer头，看网站是否正常响应。

此处的结论很显然：存在CSRF漏洞！

下面我们简单探讨下CSRF漏洞的利用，

(我才没有教坏大家的意思，如果你想，请先学好社工)

通过上述抓包我们构造一个url。生成一个网页并放到网上用来调用，这里我放到了个人服务器上（才不会暴露的说）

我们采用标签来提高我们的隐蔽性。

这里我放到了个人网站的根目录下，直接IP/文件名执行。

通过FTP上传至服务器，要学server-U构造FTP服务器的，请网络自寻资源，需要破解工具和教程的可以私信我（mark，非广告，大不了后面出教程）

给你们偷看一样，手动滑稽~

登陆DWVA，当前用户密码password，开new Tab，进入我们构造好的url~

然后回到我们的登陆界面，使用旧密码password登陆

使用新密码admin登陆

欢迎回了，CSRF漏洞利用，密码修改成功。

DWVA中此处的漏洞为get方法提交

在此我简单讲一下post方法提交时csrf漏洞的利用

步骤与get方法基本一致，只是构造html的操作全权丢给burpsuite

（什么？为什么是灰的？因为我偷懒没抓包）

使用Generate CSRF PoC功能

burpsuite会为你生成html文件源码

复制粘贴保存，即为我们所需html文件

像上述get方法一样上传第三方网站就可以啦

在此给大家留一个我也不知道答案（对呀，我！不！会！）的讨论：

burpsuite 自动生成post方法的csrf漏洞利用代码，其中的中文编码问题，导致的漏洞利用失败，

失败情况：被服务器认为编码（乱码）处存在威胁，返回报错信息

解决方法：删除乱码，或者替换乱码为纯数字

总结：好在我的工作只是渗透测试，上述操作已经证实了CSRF的可利用性，

但是！！我就是想写中文！！怎么破！！

——————————————————————————————

第二次尝试：

关于上一次的原因我已经找到了：

大家可以看到burpsuite构造的html在粘贴时被无情修改

这个的解决方法我问了许多大佬也没能解决。

于是在此祭出另一款CSRF利用工具：CSRFTester

（关于它的使用方法暂不做展开讲解）

当看到这一幕就已经凉凉了

是的，两处中文转码处，凉了。。。。

—————————————————————————————————————————————————————

第三次尝试：

手动大法好，是不是早就该往这里想了？

好吧，我蠢。。。

哈?难道服务器收到数据不解码的？

再来！直接提交解码后的数据

我去！闹哪样！你到底解不解码！

html转码，顺带说一句，这里确实是html转码，

因为汉字“灯泡”和上面这个奇奇怪怪的html码服务器判断结果是一样的

综上：思路很清晰，结果很不友好，

从大佬们的工作经历中我也知道了

并不是所有的中文情况都会这样

但确实碰到过，然而都没成功利用

当然渗透测试工作做到这里足够了，我前面讲过了，删除编码即可成功验证

然而强迫症的我依然对这里留有遗憾

无奈自己对服务器配置和源码开发领域的空白

在此我只能为此二领域大佬留白

欢迎提供解决方法，欢迎大家讨论