从 RainbowBridge 看 Js 与 Java 交互中的安全漏洞



文/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:<port>/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=<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的漏洞利用姿势。