漏洞概要 关注数(24) 关注此漏洞
缺陷编号：wooyun-2012-016150
漏洞标题：[腾讯实例教程] 那些年我们一起学XSS - 9. Dom Xss入门 [隐式输出]
相关厂商：腾讯
漏洞作者： 心伤的瘦子
提交时间：2012-12-17 21:08
修复时间：2013-01-31 21:09
公开时间：2013-01-31 21:09
漏洞类型：xss跨站脚本攻击
危害等级：低
自评Rank：2
漏洞状态：厂商已经确认
漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]
Tags标签： 无
漏洞详情
披露状态：
2012-12-17： 细节已通知厂商并且等待厂商处理中
2012-12-18： 厂商已经确认，细节仅向厂商公开
2012-12-28： 细节向核心白帽子及相关领域专家公开
2013-01-07： 细节向普通白帽子公开
2013-01-17： 细节向实习白帽子公开
2013-01-31： 细节向公众公开
简要描述：
周末腾讯不上班，我也不工作。
周一啦，继续。
上一篇开始说Dom Xss了，我们说的是显式输出的情况，即我们可以在右键查看源代码的时候，看到我们所输出的内容。而有一些时候，输出操作我们是看不见的。它们通常发生在javascript代码中。譬如：var x=location.href; 这句Javascript实际上进行了一个隐藏的输出操作，即将location.href的内容输出到了x变量中。一起来看看相关的例子吧～
详细说明：
前注： 1-4 是普通原理，没看明白的话，可以从5开始，结合实际例子看。
1. 本来是有另外一个例子的，不过不知道是腾讯已经给修复了，还是之前测试的时候人品好，偶尔碰上了，总之现在用不上了。
2. 这样一来，我们就只好用一个稍微复杂一点点的例子了。
3. 在说实际例子前，我们来说一个前端开发人员非常习惯使用的一段代码。下面大致写下伪代码。
它的作用呢？就是从地址栏的参数里取出内容。譬如：
我们在2.html，要显示 name 对应的值。对应的代码则非常可能下面这样写：
4. 上面是普通开发人员为了实现功能而写的代码，如果没有安全考虑，就会存在问题。
如果上面的地址变为了：
那么变量a将会等于 <img src=1 onerror=alert(1)>
document.getElementById("nick").innerHTML=a;
即变成了
document.getElementById("nick").innerHTML="<img src=1 onerror=alert(1)>";
这样就变成了 教程 8 中的情景，从而触发XSS。
5. 接着我们看一个实际的例子。
和原来的不同，我们在源代码里搜索不到东西的哦～
那可能这里有人会有一个疑问了。那我们怎么知道有没有漏洞呢？ 别担心，方法是有的。
这里以chrome为例，按F12，打开调试工具，见下图
和查看源代码没有什么不同，只是这次是在调试工具里看而已。
6. 通过上面的方式，确定【可能】有漏洞之后。我们可以有2个方式来进行下一步。
6.1 直接根据调试工具里看到的HTML代码情况，来构造利用代码。 优点：省时间，缺点：如果对方有一定过滤，就很难构造
6.2 定位到与这个缺陷参数sid相关的JS代码，再来构造利用代码。优点：能利用一些复杂的情况， 缺点：耗时间。
7. 对于新手来说，先看6.1的情况。看到步骤5里面的那个图。我们可以构造以下代码。
对应的图片解析：
进而“试探性”的测试一下利用代码，因为我们不知道对方会不会过滤掉 “双引号”，“括号”之类的，只能试试了。。
没反应，我们继续看看调试工具，发现，双引号，变成了 \\" 。
根据这个情况，我们可以进一步修改代码。<img>标签里不使用双引号。
这次OK啦。
可以看到，这种方式，写利用代码很快。
8. 再来看看 6.2 的方法。既然我们知道了，sid这个参数会被使用。 那么我们的目标是，javascript的代码里哪里使用了sid这个参数呢？
9. 我们首先，F12打开调试工具，点【Resources】，再点Frames, 然后 Ctrl+ F搜索 "sid" 或者 'sid'
我们运气很好，一下就定位到了一个sid。
10. 可以看到是 getUrlPara("sid")，从单词，我们不难猜出，getUrlPara就是前面我们提到的 “获取地址栏参数“的函数。
为了进一步确定，我们可以很方便的在console里查看getUrlParam函数是啥样的。
可以看到，实际上getUrlParam是对<, > 做了过滤， 但是由于chrome浏览器自身的XSS防御机制，导致location.href获取的location.href是已经经过编码的。从而导致未过滤。
如下图：
11. 按道理，location.href里的<, > ," 已经变成了 %3c, %3e,%22已经被过滤了，不会有XSS了，为什么还可以呢？我们进一步往后看。
看来，关键就是这里，这里有一步decodeURIComponent的操作，会将 %3c, %3e，又变回 <, >
供参考的完整的缺陷代码。
12. 接着，会调用 insertFlash("dv_video","f",sid,"100%","100%");
insertFlash里，也并没有对sid进行任何过滤。
图片解析：
13. 根据以上分析，我们的利用代码可以写为。注意，%3E,%3C的编码是关键。
非常值得说明的是：
如果采用6.1的方法，我们得到的利用代码是
!! 这个代码在IE下，是没法XSS的。
而通过6.2的方法，去分析JS代码，我们则可以构造出通用的XSS代码。
这也反应了 6.1 和 6.2 方法各自的优缺点。
漏洞证明：
见详细说明。
修复方案：
1. 修复过滤上的逻辑问题。
2. 注意不同浏览器中，location.href的不同点。
版权声明：转载请注明来源 心伤的瘦子@乌云
漏洞回应
厂商回应：
危害等级：低
漏洞Rank：5
确认时间：2012-12-18 17:02
厂商回复：
非常感谢您的报告。这个问题我们已经确认，正在与业务部门进行沟通制定解决方案。如有任何新的进展我们将会及时同步。
最新状态：
暂无
漏洞评价：
评论
-
真美好
-
@鬼魅羊羔 马上提供关注此人功能
-
@鬼魅羊羔 那样你就没洞洞看了
-
真叫一个体贴.周末怕让腾讯的程序员加班.
( 普通白帽子 | Rank:254 漏洞数:18 | 当我又回首一切,这个世界会好吗?)