1. 引言
UIWebView是iOS平台上很重要的组件，它能够使移动应用内置一个浏览器，能够解析和展示服务器端的网页[1] ，是移动应用进行Hybrid模式架构的一个基础组件，如著名的PhoneGap框架就是native和网页之间的中间件，它的实现原理就是基于UIWebView组件。现在有很多主流应用都采用这种Hybrid模式，如国外的Facebook，国内的百度搜索等。但目前来说，在使用UIWebView组件的过程中也出现了一些安全性问题，如CVE-2013-6893报出的猛犸浏览器iOS版UXSS漏洞[2] ，如乌云平台上报出的WooYun-2015-146717 Webview拒绝服务漏洞[3] ，可见UIWebView安全性问题还是很严重的。
本文首先简单介绍了UIWebView的使用方法，包括Javascript代码和Objective-C代码相互调用的过程，然后总结了目前在使用UIWebView时存在的安全问题，并对每个漏洞进行详细的分析，最后分别对每种不同的漏洞提出了相应的解决方案，为开发者提供一份很详尽的安全开发指南。
2. UIWebView简介
UIWebView是iOS开发中最常用的控件，相当于在iOS App中内置了一个浏览器，它能使App应用浏览网页，打开文件等操作，使iOS应用和网络应用直接交互，使得两者紧密的结合在一起，这是一个跨平台的部署方案，开发一次既可以部署在iOS平台又可以部署在Android平台，而且更新升级会更加的容易，只要在服务端更新升级，客户端就可以实时的更新展示，不需要通过AppStore的审核，大大缩短更新周期。下面来简单介绍一下UIWebView的使用方法。
UIWebView有关键的API：
loadRequest：可以用来加载一个url地址，它需要一个NSURLRequest参数。
loadHTMLString:baseURL：这个方法用于直接加载html代码，也可以用这个方法从本地html读取代码，然后加载。
loadData：MIMEType:textEncodingName:baseURL：加载带有MIME类型的数据,包含视频、图像、文本、音频、应用程序等数据。这个方法不常用，一般使用前两个方法。
goBack/goForward/stopLoading/reload。导航的几个方法，向前，向后，停止加载，重新加载等。
下述代码描述了在WebView里加载google网页的过程，如下图所示：
UIWebView的委托UIWebViewDelegate主要有下面几个关键的委托API [4] ：
-(BOOL)webView:(UIWebView*)webViewshouldStartLoadWithRequest:(NSURLRequest*)request
navigationType:(UIWebViewNavigationType)navigationType
加载前执行该方法。
-(void)webViewDidStartLoad:(UIWebView *)webView;
开始加载的时候执行该方法。
-(void)webViewDidFinishLoad:(UIWebView *)webView;
加载完成的时候执行该方法。
-(void)webView:(UIWebView*)webViewdidFailLoadWithError:(NSError *)error;
加载出错的时候执行该方法。
UIWebView更常见的用法是Objective-C与JavaScript之间的相互调用，使得页面展示，程序交互更加的灵活，其中Objective-C调用Javascript的API：通过该API：stringByEvaluatingJavaScriptFromString:可以在当前域里插入Javascript代码，具体使用方法如下图：
上述代码，首先通过js创建一个script的标签，type为'text/javascript'。然后在这个标签中插入一段字符串，这段字符串就是一个函数：myFunction，这个函数实现google自动搜索关键字的功能。然后stringByEvaluatingJavaScriptFromString执行myFunction函数。
相反使用Javascript调用Objective-C的方法就有很多种实现方法，下面介绍一种最常见的调用方法，该方法是利用UIWebViewDelegate委托的方法重定向请求实现的，具体实现过程如下图所示：
首先实现一个JavaScript函数，来传递所请求的Objective-C的函数名和参数，自己定义请求的协议的类型：testapp://+cmd+:+param。
testapp是自己定义的一个协议，cmd是要调用的oc的方法，param是调用的参数，然后利用document.location来达到目的，上面的testapp://+cmd+:+param是自定义的一种请求格式，其请求格式符合如下范式都可以：
document.location=MyCustomProtocolName:functionName?param1=value1¶m2=value2.
请求传递后，可以通过上述函数shouldStartLoadWithRequest里捕获这次请求，然后对请求做对应的解析，就可以调用的对应的函数，函数名和参数分别是请求里解析出来的值，具体的实现方法如下图所示：
上述方法通过对请求的URL解析，先判断传入所请求的函数是什么，如果匹配上”alert”则继续执行该逻辑下代码，即调用了本地的Objective-C代码。
3. UIWebView存在的安全漏洞
虽然UIWebView的使用给程序开发带来很多便利，但是同时也带来一些安全性问题，目前UIWebView存在如下几点安全问题：
(1) UIWebView XSS漏洞
漏洞详情：
UIWebVIew跨站漏洞分两种情况，第一种是普通的跨站，第二种是浏览器通用性XSS。UIWebView普通XSS漏洞，该漏洞是由于网站的漏洞造成的，如下两种情况有可能触发[5] ：
第一种情况是：未知的来源的进入了web页面，如对用户输入框输入的数据没有进行过滤，比如反射性的XSS，恶意数据通过用户组件，URL scheme handlers或者notifications传递给了web页面；又或者如存储性的XSS，恶意数据通过数据库或者其他数据源传递给了web页面。第二种情况是：恶意的数据动态的发送到UIWebView组件，并且UIWebView组件没有验证该数据的合法性。
第二种种类型是：浏览器通用性XSS [6] ，浏览器的同源策略在iOS端和桌面端是有些许不同的，比如说file域applewevdata域的URL是完全可以跨域访问浏览器里的任何资源的，除了访问本地其他文件。这就意味着如果你将一个不受信任的未知源的HTML的文件保存到了本地，并通过UIWebView的上述三个函数加载了该路径的文件，这就是全局的XSS漏洞，这个恶意的本地HTML可以读取所有的保存在该应用里的cookie，绕过同源策略做一些非法的操作，该跨域漏洞是利用的本地浏览器的漏洞，而不是网站的漏洞。
漏洞危害：
基于XSS漏洞的攻击种类有很多形式，一般是通过将用户的像cookie，session等敏感数据传递给攻击者，或者重定向用户页面到攻击者控制的服务器上，或者诱导用户输入一些敏感数据，然后传递到攻击者的服务器上，实现钓鱼攻击。
(2) UIWebView接口使用不当风险。
漏洞详情：
UIWebView使用了敏感API的接口，如发短信，发邮件等，导致恶意网页可以调用这些接口完成一些恶意的行为，通过过前面介绍的Objectivr-C和Javascript之间的bridge来实现Javascript去调用native的代码，如果在调用native代码之前没有验证调用者的合法性的话，就有可能导致恶意网页调用本地native方法去完成一些恶意的行为。
漏洞危害：有可能对用户财产造成一定的影响。
(3) UIWebView https中间人攻击漏洞
漏洞详情：
UIWebView一般会使用SSL安全链接来连接服务器端，来保证客户端与服务器之间传输数据的安全性默认iOSUIWebView https请求无效证书的话，如果用户不点击信任此站点时，此会话会被拒绝的，但这个设置可以被更改的，比如允许用户接受自签名的证书等，国外有一个测试表明14%的测试 浏览器会静默接受自签名的SSL证书[7] 。所以UIWebView中间人漏洞有如下两种情况，第一种情况是直接没有没有校验证书合法性，如校验根证书是否为自签名，是否可信，证书是否过期。第二种情况是校验了证书的合法性但没有校验访问的主机域名与证书上的域名是否匹配。如之前AFNetWorking爆出的https校验漏洞，该漏洞原因就是因为默认情况下不去校验证书的域名和所请求的域名是否一致，导致任何一个只要是可信任CA机构签发的证书，都可以校验成功[8] 。
到目前为止，iOS系统已经更新到iOS9，在这个版本的iOS系统下新增加了一个安全机制-App Transport Security，简称ATS。这个安全机制将app内的非https连接都阻塞掉了，强制服务器端与客户端用户https来连接通信，并且TLS的版本不得低于v1.2，而且规定了加密套件和证书签名的哈希算法，该机制仅仅是要求在Xcode7和iOS9 SDK的，现有的应用是不会受影响，但是还是建议服务器端升级网络配置使用https链接，并且做好检验证书的工作，保证使用https的安全性[9] 。
漏洞危害：
通过中间人攻击可以查看客户端与服务器端传输的数据，有可能导致用户隐私数据的泄露，通过中间人可以修改客户端与服务器之间传递的数据，有可能导致用户财产的损失。
当用户输入了帐号密码等信息后，钓鱼应用就可以通过网络数据或发送短信等形式将获取的数据发送至指定服务器或号码。一些钓鱼应用的伪造界面做的比较逼真，很多用户在账号密码等信息被窃取了都未能察觉，从而给用户的个人隐私和财产安全带来了极大的危害。
4. UIWebView安全漏洞的解决方案
(1) UIWebView XSS漏洞的解决方案[10] ：
要很好解决UIWebView XSS漏洞需要做到如下几点：
a) 如果没有特殊需要，可以使用Safari来打开一个链接，而没有必要通过UIWebView去实现。
b) 加载远程内容时，应确保使用了安全的机密的链路，比如说使用https连接。
c) 在使用SSL/TLS连接时确保使用了安全性强的加密算法
d) 在使用SSL/TLS连接时确保正确的校验了证书，保证客户端不能接受自签名的证书或者非法证书。
e) 通过NSData类的dataWithContentsOfURL方法去检测加载到UIWebVIew的内容，确保UIWebView没有加载一些非法脚本。比如如下代码段：
这段代码在加载网页的内容之前，会用dataWithContentsOfURL方法将加载的网页的内容提取出来放入NSData中，在使用loadHTMLString之前可以对NSData的内容过滤，编码等等，上述代码中是将script字符串都替换掉，保证了UIWebView不去加载脚本，从而也避免了加载恶意脚本的可能。
f) 最好不要使用UIWebView加载第三方的内容，如果非加载不可时，确保使用UIWebViewDelegate协议来实现一个白名单策略，来确保内容来源都是可信的。比如如下代码段：
上述代码通过通过上述函数shouldStartLoadWithRequest里捕获这次请求，将URL拿出来存入NSURL中，这样就这样通过这个NSURL来实现白名单黑名单策略，NSURL为提供如下六个可以截断URL的字段：
absoluteString：返回完整URL
standardizedURL：返回一个完整标准的NSURL对象
host：主域名
scheme：返回统一资源定位符的类型如http，https，ftp.file等等
pathExtension：返回文件URL的扩展名
lastPathComponent：返回URL路径的最后一部分内容
可以通过这些截断的URL来做一些白名单、黑名单策略，如禁用file域，不让它加载本地文件，这样就避免了浏览器的UXSS问题。
(2) UIWebView接口使用不当风险解决方案：
a) 尽量不要在UIWebView上开发一些敏感接口，如发短信，发邮件等，发微博等，
b) 如果非要开放一些敏感接口，需要对调用该接口来源的合法性进行校验，通过UIWebViewDelegate协议来实现一个白名单，确保来源的合法性或者自定义NSURLProtocol handler来处理由UIWebView发送的每个请求，这样也可以对每个请求用白名单和黑名单策略来过滤，确保不加载攻击者的恶意脚本。这个防御的具体的方法跟上条f)中讲述的方法基本一致，这里不再赘述。
(3) UIWebView https中间人攻击漏洞解决方案：
a) 完整正确的检验证书，检验签名的CA机构是否合法，证书是否是自签名的，证书是否过期，校验整个证书链等。
b) 校验证书的主机域名是否一致。如使用AFNetworking来支持https的话，它的整个安全验证证书的流程应该如下代码：
上述代码配置了securityPolicy，其中有三个比较重要的配置点，即allowInvalidCertificates代表是否允许无效证书，该选项一定是NO，确保不接受自签名的证书。
validatesDomainName代表是否需要验证域名，默认为YES，一定要验证主机域名和证书上的域名是否是一致的，假如证书的域名与你请求的域名不一致，需把该项设置为NO；如设成NO的话，即服务器使用其他可信任机构颁发的证书，也可以建立连接，这个非常危险。置为NO，主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是www.google.com，那么mail.google.com是无法验证通过的，如置为NO，建议自己添加对应域名的校验逻辑。
validatesCertificateChain代表是否验证整个证书链，默认为YES，如是自建证书的时候，可以设置为YES，增强安全性；假如是信任的CA所签发的证书，则建议关闭该验证，因为整个证书链一一比对是完全没有必要。
5. 总结
本文总结了在iOS平台上使用UIWebView过程中所带来的一些安全问题，并对每个安全隐患做了详细的分析，如漏洞触发的条件，漏洞产生的位置，漏洞产生的危害等方面进行了很详尽的阐述，最后对针对每个安全隐患，也给出了相应的解决方案，为开发者提供一份很详尽的安全开发指导书。
致谢
本文的研究得到国家自然科学基金的资助，为研究的顺利进行提供了资金保证，在此对国家自然科学基金表示衷心的感谢。
基金项目
国家自然科学基金项目(61070207, 61370195)。