漏洞小总结：浏览器里那些奇怪的逻辑

◆0 引言



最早在几年前看到一本书《挖0day》，里面介绍了一个搜狗浏览器的漏洞--伪造网站，虽然时隔四年搜狗还是犯了同样的错误，不过那会儿俺是只知道有这个理儿，但是苦于对这个理解并不深，现在接触的时间多了，渐渐的就快要走到入门的门口了。

发生在浏览器上的两种问题经常革了程序员下班时间的命（真是抱歉……），一种是代码缺陷，一种是逻辑问题。 前面的倒还好说，写错了当然就是写错了，要敢于承认嘛。 至于后面的则是一个经常让开发人员头疼不已的问题--谁知道俺的用户脑洞会如此之大，这个事都做得出来？

受到大牛们的邀请，斗胆分享一下这些常见的逻辑问题，靠这些刷了那么多WB，也该分享分享了。我一直认为浏览器逻辑方面的漏洞挖掘，很多都是靠的脑洞；至于内核漏洞嘛，俺的修为尚浅，这方面只好靠行善积德堆起人品，要不然Fuzzer都不来帮忙，简直是令人灰心丧气。

当然不得不说我只是个捡漏子的小菜鸟，希望大牛们如果发现我哪儿写的不对的或者是在口胡的话直接糊我脸上就好。

◆1 成因



事出有因，大致分一下类：

第一类是网页欺骗，这个大多数都是由于开发改地址栏的时机不对：比如IE里面在OnBeforeNavigate2、Navigate之后，chrome里面刚Load一个地址就开始换地址等等。 由于此时网页尚未加载，很多浏览器干脆就把内容页置为about:blank，而about:blank根据规则是和父窗口同源的，那父窗口当然是可以在里面为所欲为了。地址栏和内容都可以控制，那么这就是一个完美的Spoof了。

第二类是拒绝服务，这个发生原因多种多样，大多数都是浏览器自己实现的部分，由于浏览器显示的内容多种多样，页面乱七八糟的啥都有，经常一个指针没判空就崩了（百度）；或者是标题过长，或者是内存占用过多，导致程序分配不了内存然后崩溃（单进程的FireFox, WooYun: Firefox 23.0.1处理标签内存溢出拒绝服务漏洞 ）；

第三类是规则匹配不完善，这个不常见，但是俺骗来乌云的邀请码确实就是用了Mozilla官方的这个插件的正则问题导致的拒绝服务（Firefox的IETab, WooYun: 火狐浏览器的网银支付助手规则问题可能导致拒绝服务 ）。

第四类是未预期的用户行为，用户是一个群体，百万千万级别的用户的脑洞简直可以把宇宙都吸进去，用户会在浏览器上干出任何开发无法想象的到的事情，这种漏洞一般在百度搜索：浏览器 打开 崩溃，然后勾选最近1个月即可发现；

第五类是自有协议下的问题，有些浏览器为了安全构造了自有协议，因为这个就能很方便的和http/https这类不同源，脱离低级趣味了，然后浏览器会开心的放一些重要、敏感的内容进去，如果此类协议下后院起火，带来的威胁是相当之大的。

等等，因为实在是整理不完，甚至可以想象曾经浏览器的搜索栏出过问题（傲游），开一个长于MAX_PATH的本地地址浏览器溢出了（Midori），表格调整一下位置也崩溃了（IE9），replace一下浏览器地址然后全进程崩了（傲游， WooYun: 傲游浏览器4.1.0.300远程拒绝服务漏洞 ），fuzzer里面跑的页面元素刷新的太快结果浏览器HANG了整个桌面，让你鼠标有如点在空气上（360， http://www.wooyun.org/bugs/wooyun-2013-018856/trace/fd2dfb345ecc38042e4c6dbaba76fdd9）甚至浏览器的广告条都会被人爆菊花，让人觉得这个世界的恶意简直全部集中在浏览器上了，只要你脑洞够大，绝对是可以发现里面的惊奇的。

◆3 案例



从简单到稍稍复杂看一些例子。

◆3a chrome相对路径dos（协议处理不当）


理论上说，代码和逻辑嵌套的越深，越容易出问题，不过这个问题倒不是这个引起的。前些天在测试一个嵌套代码的时候，就发现了测试机器上的浏览器出现了一个很奇怪的症状：打开某某chrome内核的浏览器之后，在嵌套的窗口中通过脚本执行location.href="me:blablablast"之后，居然出现了cpu占用100%的情况。 继而我又惊奇的发现包括v31以下版本的chrome都有这个问题（BUG 346132），为了方便查看，我把location.href换成了window.open（），这一下看到了一个好玩的现象：

我的代码是：

#!html

理应最不济也是按照这个方式弹出窗口，最多只有4个：

window1: data:text/html,
window2: javascript:window.open('window.open("about:blank")')
window3: javascript:window.open("about:blank")
window4: about:blank

可是没想到从第二个窗口开始，它就无情的弹出了：

window1: data:text/html,
window2: data:text/html,

◆3d 新窗口的那些事儿 （逻辑安全不全面）


很多厂商都意识到了一个问题，那就是OnBeforeNavigate2的时候，刚chrome.Load()千万不能改地址栏啊，一定不能改地址栏啊，必须等页面全部加载完才可以，结果主窗口做的天衣无缝，完美无瑕，之后就忘了小窗口的事情。 小窗口怎么产生呢？

window.open

这个简单无比，到处可见此类弹窗小广告，被广告拦截的几率非常大，可以忽视

 WooYun: 傲游浏览器4.1.2.2000伪造任意网站漏洞

target 但是这个基本就没人拦了，但是蛋疼的是带有url变化的东西都能接上这个，比如anchor，比如form，这个可以参考：

 WooYun: 傲游浏览器4.3.0.100 表单请求伪造网站漏洞（可钓鱼）

 WooYun: 搜狗浏览器4.2.2.9903任意网站伪造＋自有协议下XSS*2

厂商也意识到了，是啊，不加载完不能换地址，一定要到OnDocumentComplete，要到documentComplete()才行，可是唯独忘了程序创建新窗口的时候也不能把地址栏给设置上，这样就导致了很多问题。

因为攻击者弹出来的东西可能并不会去瞎加载一些乱七八糟的网站，他们转而可能在小窗口上运行脚本，脚本执行完之后确实产生了页面完成事件，“但是在这上面执行的javascript:开头的地址肯定是不能替换当前地址的呀，那么还是保持之前的地址好了”，这个逻辑仿佛就是“现在我做的事不对，那么前面做的事一定是正确的”，结果正中攻击者下怀，脏数据写到了页面上，脏地址倒也被当作正确地址留下来了。

◆3e xss导致的更严重的问题 （插件安全不全面）


越来越多的浏览器做了插件，可以让用户自行选择，这是个好事情，因为这样不必让本来只想找个小菜刀做饭的用户一下背了一个核弹发射场回家。大厂商转而大度的把装备扔自己网站上，大家是要杀人越货还是要干什么，尽管自取。

那么浏览器怎么知道用户啥时候要对自己来一发火箭炮？External接口倒是可以满足浏览器这个需求，通过设置可信域，通常就是浏览器自己的插件页地址或者官网，浏览器只在可信域上开放external接口，这样用户就能在厂商那找到并让浏览器安装各个插件了。

但是至少不要来XSS，XSS的奇技淫巧大家掌握的比我多，本来自有协议就跟个核弹发射按钮似的，这XSS一来，直接就把老家送人了，最可怕的是有些浏览器甚至自行关掉了XSS过滤器，导致攻击者只需要做一个payload放到url里就可以让这些权限高的external调用随意的在浏览器里面跑起来。

例如：

 WooYun: 搜狗浏览器远程命令执行漏洞

 WooYun: 360极速安全浏览器存在设计缺陷可导致一序列安全问题

 WooYun: 傲游4.3.0.300提示安装任意插件暴露external接口

◆3f 拖拽跨域 （用户行为猜测不全）


一直要用最坏的打算来推测用户能干出来什么出格事儿，这是个事实，之前白帽子爱梅小礼发的拖拽跨域就是个非常一针见血的证明。

 WooYun: 所有国产浏览器拖曳跨特权域漏洞

本来浏览器的超级拖拽行为只有仨考虑：如果是网址，那么我们就把它打开；如果是文字我们就把它转到搜索里面；如果是图片，我们就开个新窗口让用户自己放大缩小看图片。 万万没想到，还有javascript:和vbscript:这种东西。用户的鼠标可不听使唤，iframe里面一个javascript拖到外面的页面里面，脚本可就在外面执行起来了。

当然，我想着这还不是最猥琐的，这种出其不意的事情，必然有其他地方也能让我们举一反三：标签栏。

试想标签栏在开发的眼里意味着什么？无非两种可能，来的是文字，咱搜索；来的是URL，咱打开。

来的是脚本，那就执行了吧。

◆4 预防&总结



大部分还是从开发的角度来说吧，一定要在页面加载完之后再改变地址，新窗口将地址栏置为about:blank，并在页面有实际的加载之后再改地址；

在刚启动就自动执行的任务一定要保证更严格的可用性，以及要养成良好的编码习惯，释放，引用指针之前一定要确保指针有效，这样可以确保程序不会一启动或者每次做的动作大一点就完全崩溃了；

至于逻辑问题，我觉得这也只好听天由命，自求多福了，只好恳请用户大老爷手下留情，点鼠标慢一点，没事干不要乱拖乱点好了……

参考资料
[1] http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html
[2] http://tools.ietf.org/html/rfc2616#section-14.13
[3] 《挖0day》，爱无言； 应该就是他：http://www.wooyun.org/whitehats/%E7%88%B1%E6%97%A0%E8%A8%80
[4] http://illmatics.com/Understanding_the_LFH.pdf