今天做的是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标签后面的链接会被浏览器无条件加载，从而达到自动发包的作用。)

POST类型的CSRF

这种类型的CSRF危害没有GET型的大，利用起来通常使用的是一个自动提交的表单，如：

访问该页面后，表单会自动提交，相当于模拟用户完成了一次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请求，那我们用脚本直接触发不就可以了吗？

具体怎么做呢？

document.px.submit();

更改完成之后刷新，测试成功：