CSRF攻击的BurpSuite实战
Posted 赛博先生
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CSRF攻击的BurpSuite实战相关的知识，希望对你有一定的参考价值。
今天做的是CSRF越权攻击，原理是通过在自己网站或者目标网站，通过模拟发包，替客户端发送请求。
环境配置
考虑其危害性，虽然不是很大，但是考虑到安全问题，所以本次演示需自己搭建实验环境，主要内容是用phpstudy在本地搭建一个本地网站。
下载并安装PHPstudy
寻找CSRF漏洞
测试网站域名www.incake.net
还是老步骤，注册，点击个人中心。
然后进入“发票管理”页面：
此时，发票信息页面内容为空：
点击添加发票信息并打开BurpSuite抓包
按CTRL+R或者单击右键点击sendto repeater
在Repeater中我们发现这个数据包是存在CSRF漏洞的，不论我们点击GO重放这个数据包几次，都会在发票页中添加新的发票。
制作POC
因此我们可以在这个数据包页面上单击右键-Engagementtools-Generate CSRF POC
在新弹出的页面中，BurpSuite自动生成了CSRF代码
将此段代码复制并另存为CSRF.html文件，存放在之前用phpstudy搭建好的本地网站中
然后打开本地浏览器
访问http://127.0.0.1/CSRF.html
测试漏洞
点击Submitrequest后，发现失败，失败原因是由于BurpSuite对POC的参数进行了二次编码，解决方法是根据原始数据包的参数方案对POC下的参数进行重新配置，并最终摸索出每个参数的作用：
最终更改方案如下：
点击按钮后，发现代码运行成功：
总结
在此次的CSRF实验中，虽然成功运行了，但是暴露出很多问题。
我们必须自己搭建一个网站发送问题链接后才能触发；
我们必须让用户点击那个按钮才能触发那个CSRF漏洞。
然而，实际情况是——只有傻子才能蠢到那种地步，按照你的指示一通点。
所以，针对以上两种情况，我们对此次CSRF攻击进行优化。
问题一的解决方案（拼点子）
问题一的症结所在在于，我们的请求是post类型
POST /webnew/SettingHandler.ashx HTTP/1.1
这不得不说到POST与GET请求类型的区别
具体详情可以参考：
http://naotu.baidu.com/file/162583aa24d2d445e23347f6c764a211?token=39eb7f9dfd0129e1
get和post是HTTP与服务器交互的方式，
说到方式，其实总共有四种：put，delete，post，get。
他们的作用分别是对服务器资源的增，删，改，查。
所以，get是获取数据，post是修改数据。
那POST请求与GET请求的区别和此次CSRF攻击有什么联系吗？
答案是：有。
因为GET是需要客户去向服务器去请求数据，别人不能代替客户请求数据。
而POST就不一样了，谁都可以POST，只要在同一个浏览器下，Cookie没有过期的情况下，谁都可以POST一个请求。
要完成一次CSRF攻击，受害者必须依次完成两个步骤：
1、登录受信任网站A，并在本地生成Cookie。
2、在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
1、你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2、你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
3、所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
几种常见的攻击类型
GET类型的CSRF
这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单，只需要一个HTTP请求，所以，一般会这样利用：
<img src=http://wooyun.org/csrf?xx=11 />
（在浏览器下，img标签后面的链接会被浏览器无条件加载，从而达到自动发包的作用。）
POST类型的CSRF
这种类型的CSRF危害没有GET型的大，利用起来通常使用的是一个自动提交的表单，如：
<form action=http://wooyun.org/csrf.php method=POST>
<input type="text" name="xx" value="11"/>
</form>
<script> document.forms[0].submit(); </script>
访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。
理论说完了，直接说操作了，对于问题一这种情况，我们可以将我们的请求转化为POST，将请求提交之后看服务器能否依旧响应请求。
通过尝试，在将POST请求转换为POST请求之后，我们发现此网站中的SettingHandler.ashx文件依旧相应了我们的请求，并且成功添加了发票。
那么我们只需要将转化后的GET请求发送给目标，那么他的个人信息就会别成功修改
http://www.incake.net/webnew/SettingHandler.ashx?type=_setinvoice&doing=_add&hType=%E4%B8%AA%E4%BA%BA&hName=&paycode=&content=%E8%9B%8B%E7%B3%95
这样用户如果不仔细看url的话，他是辨别不出来这个链接有问题的。
问题二的解决方案（百发百中）
BurpSuite生成的POC是做成一个按钮，点击按钮之后才会触发POST请求，那我们用脚本直接触发不就可以了吗？
具体怎么做呢？
<html>
<body>
<input type="text" name="username"value="666666666">
</form>
<script>
document.px.submit();
</script>
</body>
</html>
更改完成之后刷新，测试成功：
看不清楚点原文链接
以上是关于CSRF攻击的BurpSuite实战的主要内容，如果未能解决你的问题，请参考以下文章