关于等保可以查看文章企业等保2.0的那些事 和 什么是等保测评？，以及不做等保有什么后果？
1、注入攻击风险
检测 ipa 包是否存在注入攻击风险，关于这一点等保的描述是：
危害：攻击者通常有两种手段进行攻击，第一种是修改 app 的二进制文件增加攻击 代码，第二种是通过注入外部库，即启动前通过设置 DYLD_INSERT_LIBRARIES 环境变量指定第三方库文件，加载前会优先加 载第三方库文件。攻击者可以通过注入攻击将一段恶意代码写到目标进程， 这段代码可以加载其它可执行程序，进而实施 hook，监控程序运行、获取 敏感信息等。常见的动态注入，可以实现窃取输入的登录账号、密码、支付 密码，修改转账的目标账号、金额，窃取通讯数据等。
解决方案：开发者自查:xcode 设置 Other Linker Flags，参数增加 -Wl,-sectcreate,__RESTRICT,__restrict,/dev/null
这一点大致意思就是动态库存在注入风险，解决很简单，按解决方案在Other Linker Flags的release模式下添加：
-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null
这里按一整行设置，不要自作聪明分行设置！
但在此文章中有提到：新版的dyld源码中去掉了__RESTRICT检测。从iOS10开始，这种防护手段已失效，而且个别系统打出来的包还会发生Crash，和Swift混编的项目时候可能会出问题，所以现在不建议用这种方式,反正这一点就按等保提示设置即可。
2、不安全的 API 函数引用风险
检测 iOS App 程序中是否引用了不安全的系统 API 函数，关于这一点等保的描述是：
危害：iOS 中提供的系统 API 函数中，包含一些存在安全隐患或者需配合指定方式 使用的系统 API，否则将会导致安全性问题。其中，比较明显的一种问题就 是缓冲区溢出攻击。此类 API 中无法自动对栈中的数组进行边界检查，而且 局部变量和状态信息，都存在栈中。这样，对越界的数组元素的写操可能会 破坏存储在栈中的状态信息。当程序使用这个被破坏的状态，试图重新加载 寄存器或执行 ret 指令时，就会出现很严重的错误，可能导致程序运行失败、系统关机、重新启动。更加致命的情况是让程序跳转去执行攻击者的恶意指
令，比如非法提升权限，执行恶意代码等。解决方案：开发者移除应用程序中调用的系统风险函数和过期 api,同时防止系统直接调 用存在 C 缓冲区溢出的函数如 memcpy、scanf、sprintf、strcpy、vsprintf
亲测混淆无效！想要尝试的可以参考第3条。
解决方法还是得找相关代码，移除或找到替换方案：
-
1、全局搜索。我自己的项目中，多个方法名包含了
scanf，当然我自己是有大写的ScanFeed，为防万一对方法名做了修改 -
2、存在问题的第三方库，是通过直接引入的方式，拖入工程的，请使用使用
cocoapods引入 -
3、删除尽量可以删除的第三方库，总之尽可能去删除这些函数的使用，或找到替换方案。个人项目有
AliyunOSSiOS和libextobjc两个库存在以上函数，看了下libextobjc主要使用到weakify和strongify，我在SDWebImage的SDInternalMacros下找到了替换方案，所以将这个库移除了。从之后的结果上看，AliyunOSSiOS存在函数memcpy，但测评机构给出的结果是安全，这个库正常使用就行。这里就很奇怪了，不知道是不是会忽略部分第三方库，类似设置了白名单之类的，还是与
#ifndef和#define有关，因为AliyunOSSiOS使用函数memcpy的.h文件中有使用 -
4、工程代码已经自查完毕，但还是存在问题，这里查看
podfile是否使用use_frameworks!，没有添加进去。 -
5、如果还没有解决，可以全局搜索代码，并截图证明未在工程内使用相关api函数
3、关于混淆
基本上也不需要做这一步操作，顺便看到了就提一下，参考文章
其中func.list文件内如下：
memcpy
scanf
sprintf
strcpy
vsprintf
codeObfuscation.h文件内容自动生成，confuse.sh中的内容参考文章中的内容即可，里面提到的路径要以自己实际项目路径为准，查看自己是否比里面的内容多一层路径。
运行sh脚本的时候，可能存在类似Permission denied的问题，就是无权限编译，打开终端设置：
sudo chmod -R 777 Xcode工程所在根目录
4、篡改和二次打包风险
检测 ipa 包是否存在篡改和二次签名打包的风险，关于这一点等保的描述是：
危害：应用篡改后二次打包不仅已经严重危害开发者版权和经济利益，而且也使 app 用户遭受到不法应用的恶意侵害。对客户端程序添加或修改代码，修改 客户端资源图片，配置信息、图标，添加广告，推广自己的产品，再生成新 的客户端程序，可导致大量盗版应用的出现分食开发者的收入;恶意的二次 打包还能实现应用钓鱼、添加病毒代码、添加恶意代码，从而窃取登录账号 密码、支付密码，拦截验证码短信，修改转账目标账号、金额等等
解决方案：开发者自查:增加程序检测防止二次签名
网上解决方案大致如下：
-
判断是否修改teamid，即在程序启动时判断
embedded.mobileprovision文件内的teamid是否和自己的teamid一致 -
_CodeSignature/CodeResources文件内，判断embedded.mobileprovision文件的hash值，感觉跟上面的差不多 -
根据
SignerIdentity判断是否二次打包 -
网络请求加了一层代理判断
-
main函数内加入防动态调试 -
然后使用混淆，把这些方法名都做了混淆
以上都是代码内部做的一些常规措施，但测评机构应该不会去检查，代码内部是否有做这些处理。后来突然想到了bitcode，就将bitcode设置为false，结果这个问题没了
4.1、防二次打包
关于这个问题，几个项目项目遇到的解决方案稍有不同，如果检测结构的截图有二次打包截图之类的，建议在AppDelegate中处理下。
const char* breaken_pathes[] = {
"/Applications/Cydia.app",
"/Library/MobileSubstrate/MobileSubstrate.dylib",
"/bin/bash",
"/usr/sbin/sshd",
"/etc/apt"
};
#define ARRAY_SIZE(a) sizeof(a)/sizeof(a[0])
在didFinishLaunchingWithOptions中加入：
if ([self prisonBreakenDetection]||[self checkMach_O]) {
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[self exitApplication];
});
}
具体方法为：
// 退出应用
- (void)exitApplication{
//运行一个不存在的方法,退出界面更加圆滑
[self performSelector:@selector(exitApp)];
abort();
}
// 越狱检测
- (BOOL)prisonBreakenDetection
{
if ([self isSimulator] == YES)
{
return NO;
}
for (int i = 0; i < ARRAY_SIZE(breaken_pathes); i++) {
if ([[NSFileManager defaultManager] fileExistsAtPath:[NSString stringWithUTF8String:breaken_pathes[i]]]) {
return YES;
}
}
return NO;
}
// 是否模拟器
- (BOOL)isSimulator {
#if TARGET_OS_SIMULATOR
return YES;
#else
return NO;
#endif
}
// 判断Mach-O文件否被篡改
- (BOOL)checkMach_O
{
NSBundle *bundle = [NSBundle mainBundle];
NSDictionary *info = [bundle infoDictionary];
if ([info objectForKey: @"SignerIdentity"] != nil){
//存在这个key，则说明被二次打包了
return YES;
}
return NO;
}
4.2、顺便再提一下bitcode：
官方：
Bitcode is an intermediate representation of a compiled program. apps you upload to App Store Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the App Store.
For iOS apps, bitcode is the default, but optional. For watchOS and tvOS apps, bitcode is required. If you provide bitcode, all apps and frameworks in the app bundle (all targets in the project) need to include bitcode.
翻译：
Bitcode是编译后的程序的中间表现，包含Bitcode并上传到App Store Connect的Apps会在App Store上编译和链接。包含Bitcode可以在不提交新版本App的情况下，允许Apple在将来的时候再次优化你的App 二进制文件。
对于iOS Apps，Enable bitcode 默认为YES，是可选的（可以改为NO）。对于WatchOS和tvOS，bitcode是强制的。如果你的App支持bitcode，App Bundle（项目中所有的target）中的所有的Apps和frameworks都需要包含Bitcode。
红色部分大致就是Bitcode只是一个中间码，不能在任何平台上运行，但是它可以转化为任何被支持的CPU架构，包括现在还没被发明的CPU架构。
也就是说，如果你的项目bitcode功能是打开的，提交到AppStore之后，再未来的某天，苹果新出了一款手机，并新设计了新指令集的新CPU，那么苹果可以继续从这份bitcode，编译出能在新CPU上执行的可执行文件，以供用户下载安装，而不需要重新打包提交。
由此猜测测评机构可能通过某种方式篡改了bitcode的包，但在上传AppStore时你可以放心设置为YES。
最后的话
以上内容仅供参考，可能对你的项目并不一定适用
网友评论