1. 前言
IOS平台APP安全风险相关的一般性Checklist，保障IOS客户端安全评估的质量与效率。
2. 数据安全
2.1 传输安全
该类漏洞的审查场景：APP通过网络发送或接收敏感信息，比如用户口令、用户隐私信息等，或者通过网络下发的数据执行某些敏感操作
漏洞类型说明：由于移动设备通常是通过wifi上网，因而面临网络窃听、网络劫持等中间人攻击行为，因此对于敏感信息需要加密传输，并且对接收到的重要数据也需要进行完整性校验。如果APP自身实现了加密及完整性校验的机制，需要确认机制是否存在安全缺陷，比如算法是否足够强壮、实现是否存在逻辑缺陷、密钥管理是否安全等。通常的做法是通过HTTPS来保障网络传输安全，同时APP客户端需要严格校验服务器端证书的合法性；而HTTPS通信要求服务端有CA签发的证书，有些产品线做不到这一点，就会采用自签名证书的方式进行HTTPS请求，这里需要确保校验逻辑正确无法被绕过。下面提供一种使用自签名证书进行HTTPS请求，并正确校验服务端域名和证书合法性的方法：
static NSString *url = @"https://abc.google.com/";
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:url]];
NSURLConnection conn =
[[[NSURLConnection alloc] initWithRequest:request delegate:self] autorelease];
其中，delegate:self指定了self对象实现NSURLConnectionDelegate协议，该协议中包含鉴定证书及hostname的回调，开发者可以选择实现
(void)connectionNSURLConnection *)connection willSendRequestForAuthenticationChallenge
NSURLAuthenticationChallenge *)challenge
{
NSURLProtectionSpace *protectionSpace = [challenge protectionSpace]; SecTrustRef trust = [protectionSpace serverTrust];
SecCertificateRef *pServerCert = SecTrustGetLeafCertificate(trust);
NSURLCredential *credential = [NSURLCredential credentialForTrust:trust];
NSString *path = [[NSBundle mainBundle] pathForResource:@"rootcert" ofType:@"der"];
NSData *data = [NSData dataWithContentsOfFile:path];
SecCertificateRef clientCert = SecCertificateCreateWithData(NULL, CFBridgingRetain(data));
CFDataRef clientCertData;
CFDataRef serverCertData;
clientCertData = SecCertificateCopyData(clientCert);
serverCertData = SecCertificateCopyData(pServerCert);
success = CFEqual(clientCertData, serverCertData);
CFRelease(clientCertData);
CFRelease(serverCertData);
if (success) {
if ([challenge.protectionSpace.host
isEqualToString:@"abc.google.com"])
{
[[challenge sender] useCredential:credential
forAuthenticationChallenge:challenge];
return;
}
}
[[challenge sender]
cancelAuthenticationChallenge:challenge];
}
在上面的代码中，我们分别从challenge和本地取到了Server和Client持有的证书，并对证书进行了比较确定相同，接着又验证了使用该证书签名的host，确定与我们想要的Host相同这才通过了验证。
审核点及方法：黑盒审核方法通过网络分析工具Fiddler等分析APP发送接收的数据包，观察其中是否存在明文传输敏感信息；同时如果有加密传输敏感信息的情况，需要进一步分析加密算法的强壮性及密钥管理机制，比如简单通过base64加密传输。如果是通过HTTPS传输，观察是否可被Fiddler解密，如果可以则代表可进行中间人攻击。白盒审核方法为检查HTTP传输部分的代码，主要关注是否校验服务端证书及校验逻辑正确性是否可被绕过等。使用HTTPS协议未校验服务端证书合法性示范1：[ NSURLRequest setAllowsAnyHTTPSCertificate: YES forHost:[WebserverURL host ]];使用HTTPS协议未校验服务端证书合法性示范2：[self.httpsRequest setValidatesSecureCertificate:NO]
2.2 存储安全
漏洞类型说明：数据存储安全指APP本地数据存储的安全，这里主要指APP应用主目录文件的安全存储，高度敏感的数据禁止明文存储在APP客户端，比如用户密码、BDUSS、ptoken、stoken等，或者经过简单加密也是不允许的，比如base64加密。APP应用主目录文件路径为/private/var/mobile/Application[GUID]/，这里主要关注以下文件夹内容：
- Documents文件夹：主要是用户存档文件，可以使用iToolsGUI工具查看；
- Library/Preferences文件夹：主要是偏好设置文件，一般为plist格式，可以使用plist editor pro for windowsGUI工具打开；
- Library/Caches文件夹：主要保存应用的持久化数据，用户应用升级或应用关闭后的数据保存，一般为sqlite3格式，可以使用SQLite Database BrowserGUI工具或sqlite3命令行工具查看；
- Library/Cookies文件夹：主要保存Safari浏览器和APP应用的持久化cookie，一般文件名为Cookies.binarycookies，可以使用SecurityLearn提供的python脚本工具BinaryCookieReader读取其内容，参照链接：
http://www.securitylearn.net/2012/10/27/cookies-binarycookies-reader/ - Library/Webkit文件夹：主要保存webkit本地存储文件，不是所有APP都存在该文件夹。
审核点及方法：黑盒审核方法通过上面介绍的工具检查上述文件夹中文件是否明文存储或base64编码存储APP敏感信息或个人隐私内容，比如用户密码等。
2.3 密钥管理
该类漏洞的审查场景：APP对数据进行了加密存储、传输，但未采用安全的密钥管理方法导致密钥泄露，数据被解密
漏洞类型说明：APP在本地数据存储或网络数据传输时，针对敏感的数据都需要进行加密，加密算法分为对称加密和非对称加密，对称加密算法常用的有AES、3DES等，非对称加密算法一般采用RSA等。此时如果未采用安全的密钥管理方案，就容易导致密钥泄露。常见的不安全密钥管理方法包括：将对称密钥或私钥写死在配置文件或代码中，整个APP应用都使用唯一相同的一个对称密钥对数据进行加密解密，如果攻击者逆向分析出密钥，就可以对整个应用的数据进行解密，导致敏感信息泄露；通过网络明文传输对称密钥或私钥，攻击者通过网络窃听获取密钥，同时可以对后续传输的加密数据进行解密，从而导致敏感信息泄露。 审核点及方法：黑盒审核方法通过Introspy等动态分析工具观察运行时加解密或创建key等信息，观察APP所使用的加解密算法及密钥，如果对称密钥一直固定，就很有可能写死在配置文件或代码中，此时可进一步搜索代码或配置文件，分析密钥生成机制。同时结合Fiddler等网络分析工具分析传输的数据，观察是否存在明文传输密钥等情况。
3 信息泄露
3.1 NSLog信息泄露
该类漏洞的审查场景：日志记录中泄露了敏感信息
漏洞类型说明：在IOS开发中，RD经常需要实时输出一些运行数据来判断程序是否正确的运行，一般就采用NSLog输出，但是输出的数据可能会暴露APP里面的保密数据，所以发布Release版本时需要把这些输出全部屏蔽掉，不然就会造成敏感信息泄露。将NSLog输出屏蔽掉的方法，可以将所有NSLog语句注释掉，但这样比较笨拙耗时，比较好的解决办法是在项目的-Prefix.pch文件中加入一段代码，定义NSLog只在Debug模式下输出，Release版本下不输出，代码类似：
#ifndef _*OPTIMIZE*
_#define NSLog(…) NSLog(_*VA_ARGS*_)
#else
#define NSLog(…){}
#endifRelease模式通常会定义_*OPTIMIZE*_，
而debug模式下则不会，编译器通过宏判断是否编译输出NSLog信息，
或者通过判断是否已经定义DEBUG宏，来决定编译器是否输出NSLog信息：
#ifdef DEBUG#define NSLog(…) NSLog(_*VA_ARGS*_)#else#define NSLog(…){}#endif
审核点及方法：白盒审核方法通过查看源代码中-Prefix.pch文件是否定义以上宏定义来决定编译器是否编译输出NSLog日志信息，如果没有定义，则通过查看源代码看代码文件中是否存在未注释掉的NSLog语句。
3.2 Background Snapshot
该类漏洞的审查场景：APP进入后台缓存了当前UI截图
漏洞类型说明：IOS的后台任务处理比较独特，在APP进入后台时，系统会自动截取当前APP显示的UI的一张截图缓存到Library/Caches/Snapshots目录下，以便在APP回到前台时可以快速的显示界面，因此对于一些显示敏感信息的UI，Snapshot机制就会造成信息泄露，
如果想阻止IOS的snapshot机制，可以使用类似如下代码：
(void)applicationDidEnterBackground(悲伤)UIApplication *)application
{
if (appHasPasscodeOn){
UIImageView *splashView = [[UIImageView alloc]
initWithFrame:CGRectMake(0,0, 320, 480)];
splashView.image = [UIImage imageNamed:@"Default.png"];
[window addSubview:splashView];
[splashView release];
}
}
审核点及方法：黑盒审核方法通过iFunBox等工具查看应用的Library/Caches/Snapshots目录下是否缓存了应用进入后台时的UI的截图，以及当前缓存的截图是否存在敏感信息泄露等问题。
4. IPC安全
4.1 URLScheme
该类漏洞的审查场景：不同APP之间通过URLScheme进行交互
漏洞类型说明：IOS使用沙箱机制来限制应用程序的行为，通过该种限制可以控制恶意软件的行为，也减轻了行为良好的APP被突破后的危害；在sandbox中运行的APP在访问资源时，会经过内核的审查，只有在通过检查的情况下APP才能访问请求的资源。IOS中的APP是相互隔离的，有时候为了实现不同APP之间简单的交互需要使用URLScheme，使用URLScheme在一定程度上打破了APP之间的隔离，如果处理不当就会出现URLScheme劫持和恶意注入数据的风险。经过试验发现后安装APP的URLScheme优先，因此后安装的APP通过注册相应的URLSchemes就可以劫持其他APP之间交互传输的数据，如下所示：
Source APP：
Target APP：
劫持结果：
同时如果URLScheme的目的端对源端输入的数据校验不充分，目的端根据源端所提交的数据进行相关的逻辑处理，则可能会由于注入恶意数据导致非预期的缓冲区溢出或逻辑缺陷等，如下所示：
验证URLScheme的输入可以放在下面这个AppDelegate中：
– (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
//Validate input from the urlreturn YES;
}
审核点及方法：白盒审计方法先通过iFunbox工具等在应用主目录下查看Info.plist文件，找到key为CFBundleURLTypes这个键值，确定应用注册的所有URLScheme，如下所示：
然后在源代码中针对具体的每一个URLScheme的实现逻辑进行审计，看是否可以恶意注入数据或者是否传输了敏感信息。
解决建议
1、使用更安全的“application:openURL”API 接口替代“application:handleOpenURL”;
2、校验发送者(sourceApplication)的身份，以及严格校验传入的 URL 参数。
4.2 Pasteboard
该类漏洞的审查场景：APP使用剪贴板实现应用程序之中或应用程序之间数据的共享
漏洞类型说明：在IOS中，可以使用剪贴板实现应用程序之中及应用程序之间数据的共享，剪贴板主要分为系统级和应用程序级，系统级使用UIPasteboardNameGeneral和UIPasteboardNameFind创建，当应用程序关闭或卸载时，数据都不会丢失。应用程序级通过pasteboardWithName:create创建，可以让数据在应用程序关闭之后仍然保存在剪贴板中，但是应用程序卸载之后数据就会丢失。APP进入后台或者退出的时候如果未清除剪贴板，并且APP通过剪贴板传输敏感信息，则导致敏感信息泄露风险；APP进入后台清除剪贴板内容可以放在AppDelegate中，如果你使用自定义的剪贴板，用自定义的剪贴板替换[UIPasteboard generalPasteboard]即可。
(void)applicationDidEnterBackground:(UIApplication *)application{
// If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.
[UIPasteboard generalPasteboard].items = nil;
}
审核点及方法：黑盒审计方法通过Introspy动态分析工具观察APP是否使用pasteboard传输数据及传输数据的重要性；白盒审计方法就是通过上面介绍的pasteboard创建函数定位到具体pasteboard，然后跟踪分析代码。
5 UIWebView
该类漏洞的审查场景：APP使用UIWebView展示来自URL的内容漏洞类型说明：UIWebView使用webkit内核，并且支持javascript，目前没有公开的API可以用来禁用UIWebView中的javascript，因此如果用户控制的任何输入被用作UIWebView的内容，它就可以被操纵在运行时在UIWebView中执行javascript代码，如下所示：
UIWebView的内容只要依赖了用户的输入，就可能会出现传统web安全中出现的安全问题，比如XSS、URL跳转、CSRF等，这些都属于web安全的延伸。
审核点及方法：白盒审计方法通过查找代码定位到具体的UIWebView，看UIWebView的内容是否存在依赖于用户的输入，出现的传统web安全风险的检测方法同web端检测思路是相同的。黑盒审计方法就是针对所有的用户输入点，提交相应payload查看或对比程序的响应即可判断是否存在相应安全风险。
6 Jailbreak 检测
APP 使用了+[BFDeviceInfo isJailBreak]方法检查运行环境是否越狱，由于 Objective-C 代码中的函数名在 编译生成的二进制文件中依然会以明文字符串形式保留，攻击者很容易使用 IDA/Hopper 等反汇编工具查看到， 在Jailbreak机器上可以直接使用tweak方式绕过Jailbreak的检测。该问题还出现在APP引用的内部第 三方 SDK 中，
利用场景：
在 Jailbreak 环境下，攻击者很容易通过逆向工程找到 Jailbreak 环境监测点并替换掉。
解决建议：
APP 本身需要具备有一定的二进制安全保护能力，可以从以下两方面来增加攻击难度:
1)将 isJailbreak/isDevicebreak 等敏感字符串进行混淆处理，减少类结构信息暴露给攻击者，提高逆向难度;
2)对检测点做完整性校验(如校验运行时类方法地址等)，防止地址被篡改。
7 通信安全漏洞Check
漏洞场景
目前发现的通信安全漏洞主要集中在:
a 使用不安全的 HTTP 传输协议，
b 使用 HTTPS 传输协 议，但是客户端对服务器证书验证不全面或验证方式有误，导致 HTTPS 可能被攻破。风险描述
不安全的 HTTP 协议，很容易被网络嗅探，中间人劫持和篡改，从而泄露隐私信息，冒充伪造虚 假的请求等。虽然 HTTPS 可以从理论上很好的解决窃听、冒充、篡改等风险，但是由于客户端 和服务器实现和配置不当，很可能导致 HTTPS 被绕过。客户端证书校验不全面或有误就是比较 典型的场景，通常表现为未对证书域名做校验，忽略证书校验错误等。利用场景
一种是中间人攻击，在客户端链接恶意的 Wi-Fi 等情况下，使用假的证书进行欺骗后，作为中间 人截获信息、伪造交易请求、替换钓鱼链接等。解决方案
建议采用 HTTPS，对证书域名做校验，不要忽略证书校验错误，也可以采用固定证书的形式，但 要注意固定证书的更新机制。
