大家好，我是来自长亭科技的张一峰，今天我分享的题目是“iOS APP接口安全分析”。

议题主要内容有这么五方面：第一，业务开发模式变迁，第二，混合开发模式，第三，漏洞成因和漏洞基础，第四，实例展示，因为接口设计的缺陷导致的安全问题，第五，总结以及开发建议。

一、移动开发模式变迁

在开发模式变迁的时间轴，上面是一些时间节点，下面是相对应时间段在移动开发中Android和iOS使用的主流开发语言。

2007年Android和iOS问世，最初主要以java和oc作为编程语言，随后谷歌增加了c和c++的支持。后面由于html5技术的发展，逐渐出现了纯WEB的应用，不只是移动端，其它也会有，苹果在这期间推出了它的新开发语言swift，同时，谷歌也官方支持了kotlin语言进行开发。但是由于WEB APP存在缺陷，后面人们更多使用混合开发模式，也就是当前比较多的开发模式。截止到现在，从最初的java、oc，到现在官方主流推荐使用kotlin和swift开发，所以经过10多年变迁，有很大变化。同时，因为有混合开发模式，还有着js和HTML。

二、混合开发模式

从时间线来说，从原生到WEB再到混合开发模式，但是从逻辑角度来说，混合开发模式放在中间是更合适的。原生开发模式很好理解，我们用官方提供的语言，调用Framework的接口实现我们APP的功能。在webAPP里完全依赖于webview这个组件使用纯前端技术，我们APP的功能和逻辑主要由js实现。

而混合开发模式是原生和web的混合，它相当于二者间的一个结合点。主流APP的调用还是依靠原生代码进行调用，对于一些业务应用，比如更新比较频繁的，或者可能每天都会变化的业务，我们会使用纯web进行展示和渲染。

为了引出混合开发模式，就不得不提webAPP里面的优缺点，优点是跨平台、开发成本比较低，但缺点也很多，其中比如主要的就是它对复杂算法、多编程等等支持不是很好，同时，因为js能做的最多是压缩和混淆，它对以前的代码而言，与编译之后的二进制相比，对源代码保护还是有很多不足的。同时，有个最重要的缺点是与原生API交互是非常不方便的。

基于这个原因，人们开始逐渐使用混合开发模式，混合开发模式继承了webAPP里的很多优点，通过JSBridge手段避免了很多API调用的问题。JSBridge是什么？它是js代码到原生代码的接口，大家把它形容为像一个桥一样。通过这个桥，我们的API还是由原生的代码进行调用。其实JSBridge的功能并不是在混合开发模式中从零做出来的，它类似的功能在系统API本来就已经提供了，只不过在混合开发模式中程序员对API进行了一定的封装和扩展。

下面举个能实现这样功能的API，上面是UIWebView，下面是WKWebView，可以实现JSBridge的功能，后面还有相应API的例子，这里面就不再详细说了。基于这个API有一个使用很多的框架，就是这个WebViewJavascriptBridage框架，它就是对API进行封装，跟着框架所做的主要贡献是增加了回调函数，也就是说它能获取JSBridge的返回值，正常来说，我们通过这个API只能进行传参、调用，但是如果获取的JSBridge返回值，所以在复杂业务里是有缺陷的，这个框架主要是增加callback，能通过callback获取它的返回值。

另外一个是UIWebView的JavaScriptCore和WKScriptMessageHandler，它也都分别有对应的API可以实现这样的功能。后面有例子，这里就再不继续展开。说到这样的功能的API就不得不提安卓平台下这个接口，这个接口也是为了实现同样的接口，但是在2012年被人们发现它可以实现一个远程任意代码执行，这个漏洞影响特别深远，很多做开发的哪怕不懂安全，但在写代码时都会用一个API判断是否大于17来避开这个漏洞，其实这个地方是容易发生安全问题的。

三、漏洞成因和漏洞接触

首先介绍一下iOS deeplinks里的一种，就是URLScheme，它是提供了应用间IPC的方式，也就是说通过URLScheme可以调取另外一个应用再进行返回。怎么使用URLScheme这个技术？其实非常简单，只需要在xcode中进行注册，然后实现回调就可以了。

这个URLScheme大概长这个样子，它是遵从这三个规范，通过API可以传回URLScheme里哪个字段的值，一个应用如果自定义了URLScheme，其他第三方应用就可以对它进行调用，同时网页也可以进行调用。这个也是我们后面例子中远程进行攻击的一个非常依赖的点。

其实URLScheme也不是大家随便可以调的，它是有一个权限限制的，就是需要用户交互的，类似于让用户授权一样，如果通过网页进行调取的话，需要用户点击打开，如果是应用的话，在第一次是需要用户进行授权的。但那个授权其实相对来说是一个很宽泛的，它并不像强制访问控制，它只是一个需要用户点击和确认就可以了，用户很难去分辨。

说到URLScheme，我们下相对应的代码怎么去用它，前两行代码是URLScheme里面，已知URLScheme，去调取的话很简单的两行代码就可以用这个open函数进行调用了，如果是js的话也非常简单，一个链接就可以了，我们可以通过js里面这种自动点击的方式进行自动调用也可以。被动应用会进行回调函数，也就是最下面的函数，这个函数里它会获取传输URLScheme的参数，然后根据这个参数再执行相应的逻辑。

刚刚说有几个API可以实现JSBridge的功能，这里选了两个API，选了两个例子，让大家对JSBridge实现有个了解。上面是我们的前端链接，这里面Scheme是自定义的一种，并不是常见的。当这个链接被请求的时候，系统的这个函数就会被毁掉，相当于对我们请求的链接进行拦截。如果我们这里面自定义了一个Scheme，这里就可以判断这是不是我们自定义的Scheme，也就是说前后端对应好就可以实现通信，这里可以把传输参数取到，实现类似于伪协议的这样一个通信。通过这个可以实现从前端到后端的调用。另外一个是JScafffun里的函数，它和上一个区别是你可以自定义这个函数的名字，前端你可以认为它是JS函数进行调用，但是它其实也会进入这个代码，在这个代码可以进行获取参数。

有了上面那些基础知识，就引出了接口漏洞的成因：首先，因为自定义的第三方URLScheme，实际应用中你可以去市场中看，基本都有，基本是可以满足的。定义URLScheme以后，其他的应用或者网页可以对它进行调用，调用完程序可以执行URLScheme和对应回调函数，这个回调本身可能就存在一些缺陷。如果URLScheme回调函数本身没有什么特别的，我们需要关注它是不是有可能加载任意的URL，如果能加载任意的URL，也就是说我们可以执行我们任意的JS代码，执行任意的JS代码，如果恰好实现很多JSBridge，我们就可以对JSBridge接口进行调用，这种接口可能存在缺陷。两种情况都不符合的话，有其他方式允许应用加载这一段。

为了更好理解下一部分实例里的代码，这里简单讲一下OC运行时。OC是面向对象语言，它是一个大家接触比较多的消息转发机制，它在汇编层面发生函数对话时，它并不是直接把PC指针跳转到目标函数的地址，它是有个OBJC_MSGSEND的函数，把这个函数调用封装，但这个函数调用其实还是通过这个跳转过去，但是它相当于把这个消息进行转发，其实是oc里多态的一种实现。所以oc里面的多态相当于是在这运行池进行确定的。除此以外，运行池还提供performSelector的方式，Selector可以理解为函数名字，但其实不是。如果把这个函数名传里面去也可以实现函数调用，你不需要在程序里用形式把它包起来。

四、案例分析

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课