口水文，如果技术男看着不爽的话 直接忽视啊 ：）

android webview 漏洞背后的节操

by superhei 2013/09/06

[注：本文提到的都是我个人的观点，该行为也是私人行为，与任何组织、公司无关。另：水军请自重！]

一、前言
        这两天，一个2＋年前的android webview的nday就像一面“照妖镜”一样，直接暴露了很多个人和公司的节操...

二、流程

有白帽子在8月29日开始提交各种android平台上的“远程命令执行”漏洞，隐隐感觉到这是一种通用漏洞类型，通过联系并请教得到这类漏洞的技术细节。该漏洞
是android中webview组件里的addJavascriptInterface引起的。主要目的是为了实现java与js的交互操作。不过一个通过getClass()的方法直接调用java. lang. Runtime接口执行系统命令，让android的这个设计节操碎一地！

这个问题最早是可以追溯到2011年的一篇paper《Attacks on WebView in the Android System》http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf 这篇文章指出了addJavascriptInterface的方式在功能上带来的一些风险，比如你的app里实现了一个读写文件的类，然后使用addJavascriptInterface借口允许js调用，那么就可能导致攻击者直接调用这个class实现读写文件的操作。这种方式是最原始的风险，并没有直接指出getClass()方法的利用。

直到2012年12月21日老外一篇blog出现 《Abusing WebView JavaScript Bridges》http://50.56.33.56/blog/?p=314 可能由于这么个性话的ip访问blog形式（域名都没有）所以关注的可能不多，比如我这样的经常到处翻东西的人也没注意到这个。也有可能很多人看到了这个页面，知道技术细节后考虑到危害或者利益自己偷偷雪藏了！不知道有没有集团偷偷使用这个漏洞。 ：）

对于这个漏洞android官方其实给出个“修补方案”的：http://blog.chengyunfeng.com/?p=483 这个是一个奇葩的修补方案，直接忽视了android碎片化的问题，很多app开发厂商或者个人为了兼容低版本的android是不可能直接使用这个方案的。另外一方面很多的产品过渡考虑的是用户体验问题，很多没必要使用的webview的非要使用，有的地方根本不需要java与js交互的，非要交互。美其名曰：一切为了用户体验！

wooyun平台有个积极的效应，让一类一类的问题得到充分的暴露，于是就有了《WebView中接口隐患与手机挂马利用》http://drops.wooyun.org/papers/548
由于本文里详细的演示，“一石激起千层浪” 各种官方加班修补，各种android开发叫苦连篇，还有就是各种“妖气”开始横生...

而靠谱的修补方案却很少有人给出！

三、“妖气”来了

“妖气”一来真是乌云密布...

"万能妖"：

首先某数字旗下CDN产品微信发布消息称：“xx能拦截此类恶意代码，保护用户不受侵害”，然后就是xx工厂旗下CDN厂商，发布多条微博、微信开始热炒该漏洞：“红色预警：安卓webview远程执行漏洞 移动应用速速接入xx保护，从云端保护您的用户不受此漏洞影响”  ... 当时我看这些的消息就非常纳闷，难道tmd你们都是整的万能药？CDN你说你防入侵还说得过去，杂这个andriod的漏洞也能防，真tn的高科技～～～ 后来有人说这个是产品营销。营销也要靠谱点，过渡忽悠、多多泡沫是会害死人的～～～

奇怪的是各个移动安全厂商都没有啥动静，可能都去修补自己产品漏洞去了吧！：） 顺便提一下这个漏洞在线检测的问题，通过遍历dom的方法是可以找到这些交互接口class的，这个也是通用exp的方法。腾讯TSRC也是通过这个来实现在线检测的，他们推出的时候可能并没有考虑到这个“双刃剑”问题，当然也没有过多的不妥，因为有很多人已经意识到这个方法了。 这个代码后来直接被xx工厂旗下CDN厂商copy后并自以为的推出了一个2维码的检测！ 看上去这个方式是很拉风的，是TSRC之前没有意识到的，是我们对产品的微创新... 而这个是个实足的“泡沫“、”博眼球”的玩意。 你扫瞄这个2维码打开这个URL提示的只是这个app本身有没有被这个漏洞影响，而不能说明其他app是不是受这个漏洞的影响，不是所有支持URL访问的都有2维码扫瞄，另外还有一个坑的地方就是来自中间人的攻击... 如果你扫一次2维码就说明你手机安全了，那恭喜你，你已经被“妖气”迷惑了！

“狐妖”：

一直以科普、质疑而闻名的xx调查员，每次出现都给人以“专业”、“有理有据”的感觉，这个是“狐妖”最擅长的魅术。在这个“照妖镜”下直接照出了原型：

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝引用＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如果JS引擎允许调用Java类（基于JSInvokeClass），应限于可信浏览，否则存在安全隐患。这不是秘密，不是安卓平台漏洞，而是已知的应用策略问题，其被恶意利用的场景要求高，等级应为[低]。媒体鼓吹安全软件牛B时在场，夸大安全问题影响时也从不缺席，吃了原告吃被告。乌云吆喝“紧急！”实乃哗众取宠。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

这个是不是“哗众取宠”，懂点安全常识的人就知道。虽然我认为这个漏洞要实现完美的利用，还需要一些其他东西配合下.

“猪妖”

“猪妖”是很强大的，很容易攻击他人，星爷的《西游降魔》就充分说明了这点。再强大的妖怪也敌不过“照妖镜”，化身为某数字公司的“猪妖”直接现行了...

再一次说明了“猪妖”的强大，此漏洞大体在1月份在该公司的产品里进行一些修补策略。于是基于他的“易攻击”性，怎么可能放弃这个机会呢？于是大势攻击竞争对手产品存在漏洞。“成也'猪妖'、败也'猪妖'”，他们忽视了另外一句名言“猪一样的队友”！ 一个“str2.contains”就把自己给坑了～～～

还有一群跟着起哄的“小妖”化身为“**粉”～～～

四、漏洞修补方案

其实在老外的blog文里提到了几个修补方案：

＊ Use addJavascriptInterface only if the application loads trusted content into the WebView component (Internet || IPC == sketch).
＊ Develop a custom JavaScript bridge using the shouldOverrideUrlLoading function.  An application could check the newly loaded URL for a custom URI scheme and respond accordingly, but be careful about what functionality you expose via this custom URI scheme, and use input validation and output encoding to prevent the standard injection attacks.
＊ Reconsider why a bridge between JavaScript and Java is a necessity for this Android application and remove the bridge if feasible.

第1个方案是设置信任域，这个问题其实是不太靠谱的，在我之前在kcon里演讲《去年跨过的浏览器》里有很多信任域带来的安全问题
第2个方案是使用 shouldOverrideUrlLoading 的方式，据说这个方案还是比较靠谱的，只是可能代价比较大。
第3个方案就是教育那些开发商，没有必要用webview的时候就不要用，不要java与js交互就不要用。

其实我个人认为是android官方可以出个金融所有版本的靠谱的解决方案，不过就android风格及安全意识来说基本是不可能的。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)