转载

陌陌分享｜Android WebView 相关漏洞分析

沃·兹基硕德小贴士

分享一点点，学习一些些

作者述：见解有限，文章内容如有不当之处，请多多指正。

一、webview 远程命令执行

Android API level 16 以及之前的版本存在远程代码执行的漏洞，该漏洞源于程序没有正确限制使用 WebView.addJavascriptInterface 方法，远程攻击者可通过使用 Java Reflection API 利用该漏洞执行任意 Java 对象的方法，简单的说就是通过 addJavascriptInterface 给 WebView 加入一个 JavaScript 桥接接口， app 使用 webview 加载网页时， JavaScript 通过调用这个接口可以直接操作本地 app 的 JAVA 接口。

二、WebView RCE 相关的几个CVE

WebView 远程代码执行相关的漏洞主要有 CVE-2012-6336, CVE-2014-1939, CVE-2014-7224。

2.1 CVE-2012-6636

Android API 16.0 及之前的版本中存在安全漏洞，该漏洞源于程序没有正确限制使用WebView.addJavascriptInterface 方法。远程攻击者可通过使用 Java Reflection API 利用该漏洞执行任意 Java 对象的方法。

Google Android <= 4.1.2 (API level 16) 受到此漏洞的影响。

2.2 CVE-2014-1939

java/android/webkit/BrowserFrame.java 使用 addJavascriptInterface API 并创建了 SearchBoxImpl 类的对象。攻击者可通过访问 searchBoxJavaBridge_ 接口利用该漏洞执行任意 Java 代码。

Google Android <= 4.3.1 受到此漏洞的影响。

2.3 CVE-2014-7224

香港理工大学的研究人员发现当系统辅助功能中的任意一项服务被开启后，所有由系统提供的 WebView 都会被加入两个 JS objects，分别为是 accessibility 和 accessibilityTraversal。恶意攻击者就可以使用accessibility 和 accessibilityTraversal 这两个 Java Bridge 来执行远程攻击代码。

Google Android < 4.4 受到此漏洞的影响。

三、API Level <17 WebView RCE POC

Android 在 4.4.4 版本上彻底从 native 层禁止了 webview 对 getClass 的调用，从而阻断了一条反射执行命令的道路。但是 Context 的 getClassLoader().loadClass(“java.lang.Runtime”) 却是没有被禁止的。其限制条件为 addJavascriptInterface 绑定的对象必须为 context 的子类（一般都是 activity），因为这样才能调用 getClassLoader。targetSDKversion <17，只有在 targetsdk 小于 17 的时候才能调用 js 对象的任意方法，targetsdk>=17 的情况下只能调用加了 @JavaScriptInterface 注解的方法。

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8"/>
<title>WebView漏洞检测</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
</head>
<body>
<p>
提示：如何检测出“accessibility”和 “accessibilityTraversal”接口----设置-辅助功能-开启系统或第三方辅助服务<br><br>
<b><font color=red>如果当前app存在漏洞，将会在页面中输出存在漏洞的接口方便程序员做出修改：</font></b>
</p>
<script type="text/javascript">
function check()
{
    for (var obj in window) 
    {
        try {
            if ("getClass" in window[obj] or "getClassLoader" in  window[obj]) {
                try{
                    window[obj].getClass();
                    document.write('<span style="color:red">'+obj+'getClass</span>');
                    document.write('<br />');
                }catch(e){
                }   
                try{
                    window[obj].getClassLoader();
                    document.write('<span style="color:red">'+obj+'getClassLoader</span>');
                    document.write('<br />');
                }catch(e){
                }
            }
        } catch(e) {
        }
    }
}
check();
</script>
</body>
</html>

四、API Level >= 17 以上的 WebView

出于安全考虑，为了防止 Java 层的函数被随便调用，Google 在 4.2 版本之后，规定允许被调用的函数必须以 @JavascriptInterface 进行注解，所以如果某应用依赖的 API Level 为 17 或者以上，就不会受该问题的影响（注：Android 4.2 中 API Level 小于 17 的应用也会受影响）所谓 @JavascriptInterface 注解，就是给前端 javascript 可调用的函数限制了一个白名单，但是由于为了更好的网页与 app 交互，总是会暴露一些敏感的接口供前端 js 调用。为了保护这些敏感接口的安全，一般通过校验当前页面的 host 的方式来限制在某些域内的 js 调用。

五、webview 域控制不严格与app克隆

思路：

当 app 未禁用 file 协议时，js 可通过 file 协议获取到本地文件（存储用户 token 的文件），然后发送给攻击服务器，攻击者可通过恢复 token 克隆目标 app。攻击者可以用恶意链接实现生成本地恶意攻击 html，并传递恶意 html 的 file 路径给可导出的组件，该组件加载访问 html 文件执行其中的恶意 js，会导致私有目录中的文件被攻击者获取。

原理：

使用 file 域加载的 js 代码能够进行同源策略跨域访问。

防御方法：

设置 activity 不可被导出，则无法传递恶意 html 的 file 路径给可导出的组件。
webview 不开启 webSettings.setJavaScriptEnabled(true); ，则 webview 无法执行 js。
webview 不开启 setAllowUniversalAccessFromFileURLs(true); ，则 webview 无法将 token 发送到远程服务器。
禁止 WebView 使用 File 协议 webView.getSettings().setAllowFileAccess(false); webView.getSettings().setAllowFileAccessFromFileURLs(false); ，则 webview 无法获取到本地文件。
具体的 activity 要根据实际情况进行限制。