前言
这个网站的相关漏洞是上个月在看动漫时无意间发现的，当时仅仅发现了反射型的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_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