文/OPPO子午互联网安全实验室【Zery】
前言
Hybrid混合开发模式正在被越来越多的APP所使用,这种模式中一个绕不开的话题就是Js如何与Java进行交互,而早在Android 4.2之前的版本中,由webview提供Js与java交互的addjavascriptInterface接口就出现了严重的安全漏洞,虽然此后Android限制了只有添加@JavascriptInterface的方法才可以被js调用,但这种交互方式导致了很多兼容性问题,这也让很多开发人员脑洞大开另辟蹊径开发出了其它交互方式,其中就包括本文的主角:RainbowBridge
RainbowBridge
什么是RainbowBridge?RainbowBridge其实是JsBridge中的一种。我们将从一个demo开始,向大家展示RainbowBridge的整个流程。
首先这个APP会在webview中加载一个html,其中有如下代码:
我们看到这段Js调用了RainbowBridge.callMethod,并在回调中取得了返回的token,而这个Token是由Java层维护的,那么就说明这里实际上是Js调用Java方法并取得调用结果。
我们继续跟进RainbowBridge.js中,看一下callMethod是怎么实现的:
在callMethod中调用PrivateMethod.callNativeMethod(clazz, port, method, param),而callNativeMethod如下:
它将传入callNativeMethod的参数clazz、port、method、jsonStr拼接成一个uri,其中JS_BRIDGE_PROTOCOL_SCHEMA为"rainbow",所以按照传入的参数,这个uri应该为: "rainbow:// JsInvokeJavaScope:/getToken?"
紧接着将这个uri作为message调用win.prompt()
到这里,熟悉Android WebView的同学可能已经猜到接下来的流程了,在win.prompt()执行后,Android中会调用对应的WebChromeClient类的onJsPrompt()方法,这时流程就从Js层走到了Java层。
那么onJsPrompt()中又进行了怎样的操作呢,首先我们在onCreate()中找到当前对应的WebChromeClient类为JSBridgeWebChromeClient():
JSBridgeWebChromeClient类中重写了onJsPrompt()方法,其中调用了JsCallJava.newInstance().call()方法,并传入了message arg3:
在JsCallJava.newInstance().call()中依次调用JsCallJava类的this. parseMessage(String)和this. invokeNativeMethod(WebView)
在this.parseMessage(String)中,从Js传入的message作为uri被解析,并对this. mClassName、this. mMethodName、this. mPort、this. mParams进行赋值:
this.parseMessage(String)执行结束后继续执行this.invokeNativeMethod(WebView):
其中首先调用NativeMethodInjectHelper.findMethod()
获取了类名为this.mClassName中方法名为this.mMethodName的方法,接下来判断方法是否存在,若存在就将this.mParams和一个JsCallback对象一起构造一个Object,JsCallback对象这里暂且不表,最后使用Method.invoke调用这个方法:
至此,我们已经分析出了一次Js调用Java的流程,那么被调用的Java状态、返回值该怎么回传到Js呢?怎么触发Js回调呢?我们接着往下看,既然这个例子s是Js调用Java的JsInvokeJavaScope类的getToken()方法,那么我们找到这个方法看下:
可以看到其中将获取的token和imsi构造成一个json对象,接着调用JsCallback.invokeJsCallback(),在JsCallback.invokeJsCallback ()中又调用了call():
终于来到最后处理的call()方法里:
可以看出来这里call()方法就是将Js所调用的Java方法(本例中为getToken)的返回值、状态等信息拼接称为一个Js语句并用loadUrl执行,这个完整的Js语句为:
其中arg10为getToken()中构造的json对象,作为getToken的返回值。
ok,Java所有部分也执行完了,当loadUrl执行Js中的RainbowBridge.onComplete时,流程回到Js中:
调用了:
最终将返回结果传入一开始RainbowBridge.callMethod注册的回调中执行。
整个Js调用Java的流程到此结束。
我们画一张图来展示一下从callMethod()到callBack()的完整流程:
看完上面是不是有点晕?没关系我们用一句话总结一下:
RainbowBridge重写了WebChromeClient类中的回调函数onJsPrompt(),当Js调用Java方法时,把目标Java类名,方法名,参数传入window.prompt(),Java层的回调函数onJsPrompt()被触发,它将调用invoke去执行接收到的目标方法,执行完成后使用loadUrl()将结果返回给Js层。
简化一下就是这样的:
安全性
从上面可以看出,Js层向Java层传入类名、方法名和参数,就可以调用这个方法。那么Js是不是可以调用Java层的任意方法呢?要回答这个问题,首先要搞清楚Java是在哪里拿到需要调用的方法的,也就分析是上述findMethod()的实现。
我们找到findMethod()的代码,看起来是在this.mArrayMap这个Map中查找类名和方法名:
而this.mArrayMap在putMethod()方法中被赋值:
我们看下这个putMethod()方法,它其实是将之前parseMessage()解析的类名和类中的方法名保存入this.mArrayMap,当然,我们看到在对this.mArrayMap进行写入之前,会先对该Method进行两个判断:
这两个判断就是:
a.该方法必须被Public Static修饰
b.该方法的参数必须依次为WebView, JSONObject, JsCallBack这三个类型。
只有通过这两个判断的方法,才能被放入Map中供Js调用调用。
找到方法的来源后,我们还得继续往回看putMethod()的交叉引用,找到这个类的来源。我们可以看到putMethod()在inject()方法中被调用,传入putMethod()的类来自于this.mInjectClasses:
而这个this.mInjectClasses在clazz()中被赋值:
找到clazz()的交叉引用,就在onCreate()初始化webview的地方:
那么这个问题就清楚了,总结一下,Js只能调用传入JsBridge.clazz的类中的方法,而不能调用任意类的任意方法。而且被调用的方法必须是Public Static,同时有且仅有WebView, JSONObject, JsCallBack这三个类型的参数。
虽然RainbowBridge对Js可调用的Java类和方法进行了限制,Js无法调用任意类和方法,但在一些情况下由于业务需要,Java还是会给Js开放功能很强大的方法,这种情况下,一旦webview加载恶意Js就可以调用到这些很危险的方法,因此为了限制能调用Java方法的Js,RainbowBridge可以在Js调用Java方法时对调用的Js进行白名单检查:
这里的demo在onJsPrompt()中添加了一个checkWhiteList()方法,对调用的url进行检查,检查通过之后才能调用Java方法。
漏洞
由上一节可知,RainbowBridge对Js调用的Java方法做了限制,同时也可以增加对调用的Js进行白名单检查。但是,由于RainbowBridge框架未提供统一的白名单检查,留给程序员自由发挥的空间很大,这里面就有出现安全漏洞的可能。我们仍以上面这个demo为例对这类漏洞进行完整的展示。
首先要能让webview加载一个恶意的html,这样我们才能用这个html中的恶意Js去调用应用Java层的重要方法。在本例中,MainActivity存在一个scheme入口:
同时在MainActivity中会获取这个scheme的参数”url”作为url在webview中打开:
因此我们只需要在一个html里构造foo://main.zery.com/?url=这样的scheme,当受害者在浏览器中打开这个html触发scheme,就可以跳转到demo应用并在webview中打开指定的url。
接下来需要让指定url中的恶意Js去调用Java方法,由之前对RainbowBridge的分析,我们可以很容易地写出调用Java方法的Js语句,但onJsPrompt()中还有checkWhiteList()对调用者进行检查:
注意到这里的白名单校验使用了endsWith("zery.com")这样的方式,只需要注册evlizery.com这样的域名,就可以很容易地绕过该白名单校验。
同时,这里使用了java.net.URL.getHost()来获取域名,这个getHost方法低版本是存在被绕过的漏洞的,即https://www.evil.com\\zery.com 这个url的getHost获取的结果是www.evil.com\zery.com ,可以通过endsWith的校验,而打开的结果是跳转到www.evil.com
通过这个白名单校验的漏洞,我们就可以让恶意Js去调用Java方法,最终的poc为
在evil.html中的恶意Js:
最终效果:
结语
从本质上来说,这个例子中的漏洞还是属于白名单校验不严的问题,RainbowBridge只是提供了一个攻击的途径。就像攻击addjavascriptInterface接口要寄希望于开发人员忘了删掉@JavascriptInterface注解一样。但与RainbowBridge类似还有多种JsBridge的方法可以实现Js调用Java,对于这个攻击面来说,本文也旨在抛砖引玉,希望上文对RainbowBridge做的一些粗浅的分析,能引出更多JsBridge的漏洞利用姿势。