记录一次“梅花三弄”的渗透之旅

前言

这个网站的相关漏洞是上个月在看动漫时无意间发现的,当时仅仅发现了反射型的Xss漏洞,在后期再渗透过程中还发现了CSRF和Iframe的钓鱼框架漏洞,现在把挖洞的过程整理一下,写成文章投稿。作为一个网安新人,内容上有不妥的地方希望大佬们能够指出。写这篇文章不仅是为了锻炼自己的表达能力,同时还为了给那些挖到Xss漏洞的新人们一些启发。作为一个90后,希望能够加入九零这个大家庭和大家一起学习进步!

文章中提到的网址均以http://www.xxxxx.com/ 为主站点。

梅开一度

疫情期间在家闲着无聊,正好有几部漫画更新了,所以打算去某动漫网站看下最新章节。当我来到网站登陆界面的时候,脑袋里下意识想起了之前学的Xss漏洞反弹cookie的知识点。抱着测试的心态,首先用御剑做了个后台扫描,结果如下图:

经过测试,所有有关的/login链接都指向同一个后台登陆点,最终我选择了http://www.xxxxx.com/login 作为登陆站点。

于是乎,我拿出了祖传的Xss测试代码:

<script Script "'Asaika>

在用户框中输入上面的测试代码,密码框随便输入,测试下输入框内是否对左右<、script、单双引号以及大小写等过滤的情况,回显结果如下图:

查看源代码发现写入得代码有高亮,并且需要构造“>来完成闭合,于是重新构造了测试代码:

"><script Script "'Asaika>

二次测试结果如下图:

输入的测试代码再次高亮了,说明有戏,于是回到正常登陆界面,查看用户名框对应的标签是txt_name,于是乎,构造了简单的Xss测试链接。

http://www.xxxxxx.com/login/?txt_name=%22%3E%3Cscript%3Ealert(/Asaika/)%3C/script%3E

成功回显弹窗,如图:

没想到就这么一发入魂了,这个网站在Xss上完全没有做任何防护,我又测试了一把弹cookie的代码

http://www.xxxxx.com/login/?txt_name=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

我用自己的账户测试,链接反弹的cookie和正常登陆下Burp Suite抓取的cookie是相同的,关于进一步构造php代码来读取ip和cookie并传给指定服务器来窃取用户cookie的方法,见参考链接。

梅开二度

在挖到这个站的当天晚上,我仔细看了Burp Suite抓的数据包,发现登陆界面并没有做Token验证,目测可能还存在CSRF漏洞,于是抱着试一试的心态,开启了“梅开二度”之旅。

基于前面在txt_name下挖掘的Xss的经验,依旧使用Burp Suite对其进行抓包。首先将浏览器中,该网站的cookie缓冲进行删除,然后抓包,如图:

利用Burp Suite的Engagement tools下的Generate CSRF PoC功能键生成一个测试的PoC代码,如图:

测试代码如下:

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="http://www.xxxxx.com/login/">
      <input type="hidden" name="txt&#95;name" value="" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

接下来通过生成的PoC代码来构造测试链接,构造的测试链接如下:

http://www.xxxxx.com/login/?txt_name=%22%3E%3CIMG+SRC%3D%22%3Chtml%3E%20%3C!--%20CSRF%20PoC%20-%20generated%20by%20Burp%20Suite%20Professional%20--%3E%20%3Cbody%3E%20%3Cscript%3Ehistory.pushState(%27%27,%20%27%27,%20%27/%27)%3C/script%3E%20%3Cform%20action=%22http://www.dm5.com/login/%22%3E%20%3Cinput%20type=%22submit%22%20value=%22Submit%20request%22%20/%3E%20%3C/form%3E%20%3C/body%3E%20%3C/html%3E%22%3E

在网站地址栏输入上面构造的PoC测试链接得到如下的测试界面,用户名框下面多了Submit request这个点击框,并且在源码中其被编译和高亮显示,如下图:

从PoC的检测可以看出,其存在CSRF漏洞,当然除了这种测试方法,还可以使用别的方法进行CSRF漏洞验证测试,详情见参考链接。

关于txt_name下,爆出Xss和CSRF两者结合的漏洞使用和测试,我在此处就不过多描述,想了解的可以见参考链接。

梅花三弄

本着测试的角度,第二天上午,开启了我的”梅花三弄“终极之旅。于是我写了一个简单的钓鱼框架测试链接,看其是否存在iframe内嵌框架钓鱼漏洞,请求的测试链接选择九零的官网地址:

http://www.xxxxx.com/login/?txt_name=%22%3E%3Ciframe+id%3D1770+src%3Dhttps://forum.90sec.com/%3E

wtf?,拒绝连接请求?我就是单单想测试一下而已……看来只能请求连接我自己的网站了,测试页面回显如图所示:

http://www.xxxxx.com/login/?txt_name=%22%3E%3Ciframe+id%3D1770+src%3Dhttps://www.asaika.com/%3E

很明显,构建的钓鱼框架测试成功,的确存在iframe嵌入框架钓鱼漏洞。

总结

在挖洞的过程中,我们基本遇见的最多就是Xss漏洞,首先因为其测试的PoC的确比较容易构造,加上其在web开发时难以避免的原因,于是乎在自动化软件的扫描下,一般的新手也能从中体会到挖洞的乐趣。而真正的网安之路并非如此容易,就拿这次挖洞之旅而言,一般在我们挖到Xss后,大部分的人在这个标签的测试基本就结束了,其实如果简单的抓个包,好好看下Request头部请求,说不定还会有新的收获,或者用一下其他的漏洞PoC代码测试下,更有可能达到到”梅花三弄“,或者挖到更多漏洞的效果。挖洞只有在不断地尝试后,才会有意想不到的进步。

由于此次挖洞仅限于测试,进一步的利用和提权也没拿到别人的测试权限,我只是用PoC做了相关漏洞存在的测试。只要一些漏洞存在,查找并运用相关的方法,网上关于此类技术文章可谓看得眼花缭乱,我就不在此班门弄斧了,各位大佬们海涵!!!

参考链接

1:XSS获取Cookie过程简单演示:https://blog.csdn.net/qq_36609913/article/details/79066320
2:burpsuite之CSRF测试:https://blog.csdn.net/andyfeng088/article/details/80195105
3:鸡肋CSRF和Self-XSS组合的变废为宝:https://www.freebuf.com/articles/web/164069.html

你觉得反射型xss可以x到管理员吗?一般网站没防护你就可以在 用户 密码处和ip处盲打xss,一般后台会有记录登录的信息的地方,这个地方记录着用户名,ip,运气好的话可以打到cookie

X管理员的概率很小,文章里说的是X用户,测试时用得也是自己得一个普通账号,不知道你为什么会问这样得问题。

看了上面的评论,其实我认为是这样的,无论是x用户或是x管理,只要你把洞利用好了那就就是可行的,所以千万别觉得反射型就怎么样了而笔者也提到了 x用户,我觉得可以多说一下有怎样的一个思路去x把这个漏洞最大化的给利用起来

大佬的回答十分中肯,以后有机会一定写一篇比较系统性的Xss利用方面的文章,这个只是基本的漏洞验证,算不算什么利用。