移动端相比服务器，更简略被进行进犯，因而咱们有必要了解一些安全防护的常识，然后确保用户信息安全，咱们首要从本地文件和数据、源代码、网络通讯三部分进行防护

1、本地文件与数据安全

1.1、程序文件安全

风险：

  • iOS运用大部分逻辑都是在编译后的二进制文件中，但假设由于Hybrid等原因打包了js文件或其他文件，进犯者假设拿到iOS装置文件并解压，就能看到包内容，并依据js文件代码了解调用逻辑，在越狱手机上乃至能够修正js代码，然后进行进犯

安全计划：

  • 经过将js源码进行混杂和加密，避免Hacker轻易阅读和篡改相关逻辑

1.2、本地数据安全

iOS运用的数据在本地一般保存在本地文件或本地数据库中，假设本地数据未进行加密处理，很或许被Hacker篡改（存储形式：Plist文件、SQLite数据库文件、Keychain文件、缓存文件、日志文件）

因而关于本地重要数据，咱们应该加密存储或将其保存到keychain中，以确保其不被篡改

1.2.1、Plist文件

特点列表（Plist，Property List）是一种结构化的二进制格局文件，包括了内嵌键值对的可履行bundle的根本装备信息

  • Plist文件 首要用于存储App的用户设置及装备信息，例如，游戏类App经常会在Plist文件中存储游戏等级和分数信息

    • 比如你做了一款游戏，将剩余命数命名为leaveLifes存在本地plist文件中，那么就有或许被Hacker篡改成无限命

  • 一般来说，App会将存储用户数据的Plist文件保存在[App home目录]/documents/目录下

  • Plist文件 能够是XML格局 或 二进制格局

风险：

  • Plist文件首要用于存储用户设置及App的装备信息，但App或许运用Plist文件存储明文的用户名、暗码或其它一些个人灵敏信息，而保存在Plist文件中的二进制格局文件数据则能够运用Plist文件编辑器（如plutil）进行查看或修正，即便在一个没有越狱的设备上，plist文件也能够经过东西iExplorer获取

安全计划：

  1. 尽量不要在iOS设备的Plist文件中保存灵敏信息（如证件号、银行卡号、具体住址及其各对应的编码格局等）
  2. 关于有些APP功用需求，假设一定需求在iOS设备本地保存灵敏信息，则 可采用iOS供给的加密接口（如CommonCrypto）进行安全加密后保存
1.2.2、SQLite存储

SQLite是一种 自包括、可嵌入、0装备 的SQL数据库引擎的跨渠道C库文件；它的表、触发器和视图整个数据库都包括在一个硬盘文件中；SQLite数据库常见的后缀一般有.sqlitedb和.db，APP一般会将其保存在[App home目录]/documents/目录下

风险：

  • 信息走漏：iOS自带的SQLite数据库没有内置的加密支持，因而，许多iOS APP会直接以明文格局将许多灵敏数据存储在SQLite数据库中，除非APP本身对数据进行加密后再存储

    例如银行APP将用户的登录手机号、登录暗码、手势暗码悉数都以明文方法存在了客户端本地的SQLite数据库中，一旦能够物理拜访到设备或其备份文件，存储在SQLite中未加密的灵敏信息简略被走漏

  • 数据康复：在iOS中，康复被删去的SQLite数据库记载比康复被删去的文件更为简略，由于假设删去一条记载，SQLite仅会将该记载标记为已删去，但不会铲除它们，只需SQLite数据库文件本身没被删去，数据库中被删去的记载则会一向保留在SQLite文件的未分配空间内，直到新的记载掩盖它们

    进犯者能够运用strings指令打印SQLite数据库文件中数据，这其间就包括了被删去的数据

安全计划：

  • 最简略的方法便是尽量不在客户端的SQLite数据库中保存灵敏信息
  • 假设的确需求将某些灵敏信息保存在SQLite数据库中时，能够结合运用以下几种计划：
    1. 数据加密：运用如AES256加密算法对数据进行安全加密后再存入SQLite中
    2. 整库加密：可运用第三方的SQLite扩展库，对数据库进行全体的加密
    3. 数据掩盖：在删去SQLite数据库某条记载之前，能够运用废物数据update一下该条目，这样即便有人测验从SQLite文件中康复已删去的数据库时，他们也无法获取到实践的数据
1.2.3、键盘缓存

为供给自动填充和纠正的功用，iOS体系的自带键盘会缓存用户的输入信息，其会保存一个接近600个单词的列表，存放在Library/Keyboard/ en_GB-dynamic-text.dat或/private/var/mobile/Library/Keyboard/dynamic-text.dat文件中（iOS版别不同，方位及文件名会略有不同）

风险：

  • 这个功用会带来一个安全问题：它会明文存储用户在输入框中输入过的一切信息，如用户名、暗码短语、安全问题回答等；要想查看该键盘缓存，能够将上述如 en_GB-dynamic-text.dat 文件仿制到电脑上，并运用十六进制编辑器翻开

安全计划：

  • 关于以下方位或方法的输入，iOS不会对其输入内容进行缓存：
    • 在 标记为secure的字段、passwords字段 内输入的内容不会缓存
    • 输入 只包括数字的字符串不会被缓存，这也即意味着银行卡号、信誉卡号是安全的（iOS 5之前的版别会缓存）
    • 十分短的输入，如只需1或者2个字母组成的单词 不会被缓存
    • 禁用了自动纠正功用的文本框 不会缓存输入的内容

  1. 在不需求缓存的文本框处禁用自动纠正功用，如下代码所示：

    UITextField *textField = [[UITextField alloc] initWithFrame: frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

  2. 输入框也能够被标记为暗码输入类型，使得输入变得更加安全，避免缓存：

    textField.secureTextEntry = YES;

  3. 在一切灵敏信息输入处均运用自界说键盘，当然自界说键盘也不能缓存用户输入（这或许会影响用户体会）

  4. 除了文本输入的当地，在iOS体系上，当数据被仿制到张贴板上的时分，也会被进行明文缓存，而且张贴板内容一切APP均可拜访，为禁用文本框的仿制/张贴功用，使得用户无法在某些当地进行仿制和张贴，可在该文本输入的当地增加以下方法：

    -(BOOL)canPerformAction:(SEL)action withSender:(id)sender {
    UIMenuController *menuController = [UIMenuController sharedMenuController]; 
    if (menuController) {
        menuController.menuVisible = NO;
    }
    return NO;
}
1.2.4、运用快照缓存

当一个运用在后台被挂起时，iOS会生成一个当时屏幕的快照，当运用被从头唤起时，能够快速复原该APP之前的内容，以提高用户的运用体会

风险：

  • 运用快照保存在/var/mobile/Containers/Data/Application/XXXXXXX-XXXXXXXXX-XXXXXXXXX/Library/Caches/Snapshots/目录下，歹意APP可经过读取该文件并发送至长途服务端，然后取得其快照内容信息，其间就或许包括灵敏信息

安全计划：

  • 要避免这种信息走漏途径，屏幕内容就必须在iOS体系进行屏幕快照之前进行躲藏或含糊化处理，而iOS体系也供给了许多回调方法来提示程序将被挂起，例如以下两个方法：

    // 运用程序将要入非活动状态履行,在此期间,运用程序不接纳音讯或事情
-(void)applicationWillResignActive:(UIApplication *)application
// 程序将被推送到后台
-(void)applicationDidEnterBackground:(UIApplication *)application

  • 下图为APP压入后台的进程，右边则是可供APP回调的方法，可利用其完结自己的一些需求：

    iOS-安全防护

  1. 躲藏界面：设置要害窗口的hidden特点为YES，这样当时在屏幕上显现的内容将被躲藏，回来一个空白的快照来代替任何内容

    [UIApplication sharedApplication].keyWindow.hidden = YES;

    留意：假设在当时窗口后面有其他的窗口，当要害窗口被躲藏时，那些窗口将会被显现出来，所以当运用这种方法时要确保也躲藏了其他窗口

    • 当运用程序即将进入非活动状态时（如接到一个电话或切换到其他运用程序时），applicationWillResignActive方法会被回调，因而能够用以下代码来躲藏窗口 
      -(void)applicationWillResignActive:(UIApplication *)application
{
    [UIApplication sharedApplication].keyWindow.hidden = YES;
}
    • 当APP被压入后台但在屏幕快照被调用前，aplicationDidEnterBackground方法中会被调用 
      -(void)applicationDidEnterBackground:(UIApplication *)application
{
    [UIApplication sharedApplication].keyWindow.hidden = YES;
}

  2. 含糊处理：除躲藏当时界面内容外，还能够对当时界面所展示的内容进行含糊化处理；在上述的回调方法中，经过运用iOS的毛玻璃（blur glass）技能，能够到达程序后台运转界面的含糊化作用

1.2.5、运用日志

根据iOS APP程序开发排错的需求，开发人员一般都会写一些数据到日志中，而这些数据就或许包括证件号、登录用户名和暗码、认证token或其它的一些灵敏信息

风险：

  • 运用程序的过错日志是不被运用程序的沙盒隔离维护的，一个APP发生的过错日志能够被另一个APP读取，因而，假设一个APP运用日志功用输出了某些灵敏信息，那么歹意APP就能够读取到这些信息，并可将其发送到一个长途服务器上
  • 能够直接从AppStore上下载装置console运用，查看iOS体系及APP输出的过错日志信息，能够在/var/log/目录下找到iOS的日志文件

安全计划：

  1. 不要在APP的日志中记载或打印灵敏信息
  2. 在正式发布时封闭日志打印开关
1.2.6、Keychain存储

Keychain是一个具有有限拜访权限的SQLite数据库（AES256加密），能够为多种运用程序或网络服务存储少量的灵敏数据（如用户名、暗码、加密密钥等，以供给透明的认证，使得不必每次都提示用户登录）；在iPhone上，Keychain存放在/private/var/Keychains/keychain-2.db的SQLite数据库

  • Keychain数据库包括了一些Keychain条目，每个条目都由加密的数据和一系列未加密的描述特点组成，Keychain条目被分为5种类型：

    类型 缩写
    一般暗码(generic passwords) kSecClassGenericPassword
    网络暗码(internet passwords) kSecClassInternerPassword
    证书(certificates) kSecClassCertificate
    秘钥(keys) kSecClassKey
    数字身份(digital identities) = 证书 + 秘钥 kSecClassIdentity

  • 在iOS的Keychain中，一切的Keychain条目都被存储在Keychain SQLite数据库的4张表中：genp、inet、cert和keys

    • genp数据表 存储了 一般暗码 的Keychain条目
    • inet数据表 存储了 网络暗码 的Keychain条目
    • cert数据表 存储了 证书 的Keychain条目
    • keys数据表 存储了 密钥 的Keychain条目

  • Keychain的数据库内容运用了设备唯一的硬件密钥进行加密，该硬件密钥无法从设备上导出；因而，存储在Keychain中的数据只能在该台设备上读取，而无法仿制到另一台设备上解密后读取

    iOS-安全防护

  • iOS APP的Keychain数据是存储在运用沙箱外面的，各APP的keychain数据内容为逻辑隔离，由体系进程securityd施行拜访控制

    • 一个运用默许无法读取到另一个运用在Keychain中存储的数据
    • 在iOS体系中，每个APP都附带一个唯一的运用标识符，而Keychain服务则运用这个运用标识符约束其对其它Keychain数据的拜访；默许状况下，APP只能拜访与他们的运用标识符相关联的数据
    • 为了在多个APP间能够同享Keychain信息，Apple引入了 Keychain拜访组 概念：具有相同Keychain拜访组标识符的运用，能够同享Keychain数据
    • APP的Keychain拜访权限（即标识符）被加密嵌入在了APP的二进制文件中，但能够经过运用grep或sed指令将其从该文件中提取出来

  • 随着iOS引入了数据维护机制，存储在Keychain中的数据被另一层，与用户设备暗码(passcode)相关联的加密机制维护

    • 数据维护加密密钥（维护类密钥-protection class keys）是由一个设备 硬件密钥 和一个 由用户暗码衍生的密钥 一起发生的

    • 能够经过向Keychain接口的SecItemAdd或SecItemUpdate方法的kSecAttrAccessible特点供给一个数据维护可拜访常量来启用Keychain的数据维护

    数据维护可拜访常量 的值决议一个Keychain条目在何时可被运用拜访，一起也决议某个Keychain条目是否答应移动到另一台设备上

    常量 Keychain条目拜访状况 留意
    kSecAttrAccessibleWhenUnlocked 只能在设备被解锁后被拜访 此刻用于解密Keychain条意图数据维护类密钥只在设备被解锁后才会被加载到内存中，而且当设备锁定后，加密密钥将在10s钟内自动铲除
    kSecAttrAccessibleAfterFirstUnlock 能够在设备第一次解锁到重启进程中被拜访 此刻用于解密Keychain条意图数据维护类密钥只需在用户重启并解锁设备后才会被加载到内存中，而且该密钥将一向保留在内存中，直到下一次设备重启
    kSecAttrAccessibleAlways 即便在设备锁定时也可被拜访 此刻用于解密Keychain条意图数据维护类密钥一向被加载在内存中
    kSecAttrAccessibleWhenUnlockedThisDeviceOnly 只能在设备被解锁后被拜访 无法在设备间移动
    kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly 可在设备第一次解锁后拜访 无法在设备间移动
    kSecAttrAccessibleAlwaysThisDeviceOnly 即便在设备锁定时也可被拜访 无法在设备将移动

  • Keychain条意图 数据维护可拜访常量 被映射到各Keychain表(genp、inet…)中的pdmn列(protection domain)，下表显现了keychain数据维护可拜访常量和pdmn值之间的映射关系：

    iOS-安全防护

风险：

  • 为避免每次提示用户登录，APP很或许会在Keychain中直接存储明文的认证信息（如WiFi、邮箱暗码），关于越狱的iOS设备运用Keychain_dumper东西可导出一切Keychain条目，它运用“*”通配符格局的Keychain拜访组权限，因而能够拜访到设备上一切的Keychain条目

  • APP在增加Keychain条目时或许也会设置 数据维护可拜访常量，如前文所述，该可拜访常量决议了Keychain条目何时才干被拜访，而数据维护机制又是与用户暗码相关联的，只需在当用户设置iOS暗码时，它才会维护数据

    • 当设置了iOS暗码且未解锁时，无法拜访到Keychain中的数据
    • 解锁后 或 未设置iOS暗码，即可拜访到Keychain中的数据
      iOS-安全防护

安全计划：

  • 一旦进犯者能够物理接触到没有设置暗码的iOS设备时，他就能够经过越狱该设备，运转如keychain_dumper这样的东西，读取到设备一切的Keychain条目，获取里边存储的明文信息。而 即便在运用向Keychain中存储数据时运用了数据维护的接口（即上文提到的keychain数据维护可拜访常量），未设置用户暗码的Keychain数据仍没有被有效地维护着，为确保Keychain中存储的数据的安全，可采用以下建议：
  1. 尽量不在Keychain中直接存储明文的灵敏信息
  2. 向Keychain中存储数据时，不要运用kSecAttrAccessibleAlways，而是 运用更安全的kSecAttrAccessibleWhenUnlocked或kSecAttrAccessibleWhenUnlockedThisDeviceOnly选项
  3. 假设必需求存储，则可先检测用户是否设置了设备暗码，并进行相应的风险提示

2、源码安全

2.1、反汇编二进制文件

风险：

  • 经过class-dump、theos、otool、Hopper、IDA等反汇编东西，Hacker能够对编译后的二进制文件进行反汇编，得到可读性很高的内容，然后制造注册机、破解网络协议制造机器人账号等

安全计划：

  1. 运用宏（#define），来混杂类名、替换易读的字符串，但手动写入文件工作量巨大，因而能够凭借代码混杂东西；比如 codeobscure（原理是经过运转ruby脚原本遍历工程中的特点、方法、类名进行混杂），或许的坑：

    • 三方库、以及其他不需求混杂的文件留意分文件夹办理，以备后续经过装备忽略途径来忽略这些不需求混杂的文件
    • 由于codeobscure 不会混杂静态字符串，如@”text”，因而以下几类不能混杂：
      • 与网络恳求相关的模型类的特点不能混杂，而且您运用了MJExtension等直接将json方针转换为模型的三方库
      • 运用了 NSClassFromString(@”classNameA”)方法将静态字符串转换为Class的该类的类名不能混杂
      • 被键值调查的特点不能被混杂, 如以下canExchange这个特点就不能被混杂： 
        [self.viewModel addObserver:self forKeyPath:@"canExchange" options:NSKeyValueObservingOptionNew context:nil];

  2. 要害逻辑运用纯C完结（微信的通讯底层便是C完结）

2.2、阻止动态调试

风险：

  • Hacker或许会运用调试器 GDB、LLDB来进犯你的App

安全计划：

  • 你能够在 main.m 文件中刺进以下代码： 
    #import <dlfcn.h>
#import <sys/types.h>
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#if !defined(PT_DENY_ATTACH)
#define PT_DENY_ATTACH 31
#endif  // !defined(PT_DENY_ATTACH)
void disable_gdb() {
    void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
    ptrace_ptr_t ptrace_ptr = dlsym(handle, "ptrace");
    ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
    dlclose(handle);
}
int main(int argc, char *argv[]) {
    // Don't interfere with Xcode debugging sessions.
    #if !(DEBUG) 
        disable_gdb();
    #endif
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil,
            NSStringFromClass([MyAppDelegate class]));
    }
}

2.3、模拟器检测

  • OC供给了宏TARGET_OS_SIMULATOR来查看你的App是否运转在模拟器环境。 
     if (TARGET_OS_SIMULATOR) {
     // 模拟器
 } else {
     // 非模拟器
 }

2.4、避免二次打包

风险：

  • 有些Hacker或许会经过篡改你的程序包（包括资源文件和二进制代码）参加一些广告或者修正你程序的逻辑，然后从头签名打包

安全计划：

  • 由于Hacker获取不到签名证书的私钥，因而 会替换掉程序包中签名相关的文件：embedded.mobileprovision，咱们能够直接查看此文件是否被修正，来判别是否被二次打包，假设程序被篡改，则退出程序 
    // 校验值,可经过上一次打包获取
#define PROVISION_HASH @"w2vnN9zRdwo0Z0Q4amDuwM2DKhc="
static NSDictionary * rootDic=nil;
void checkSignatureMsg()
{
    NSString *newPath=[[NSBundle mainBundle] resourcePath];
    if (!rootDic) {
        rootDic = [[NSDictionary alloc] initWithContentsOfFile:[newPath stringByAppendingString:@"/_CodeSignature/CodeResources"]];
    }
    NSDictionary*fileDic = [rootDic objectForKey:@"files2"];
    NSDictionary *infoDic = [fileDic objectForKey:@"embedded.mobileprovision"];
    NSData *tempData = [infoDic objectForKey:@"hash"];
    NSString *hashStr = [tempData base64EncodedStringWithOptions:0];
    if (![PROVISION_HASH isEqualToString:hashStr]) {
        abort();//退出运用
    }
}
  • 能够在多个重要的当地参加此代码，避免第三方进犯人员发现某一处检测代码后绕过检测

3、网络安全

移动端与服务器通讯的网络传输进程中或许会经过不安全的中心节点，即便是HTTPS的加密通讯，Hacker也或许经过中心人进犯（Man-in-the-middle attack）来截取通讯内容，所以咱们要对数据加密维护

3.1、暗码传输安全

3.1.1、URL明文防护

风险：

  • 登录时不能运用明文暗码进行登录，尤其是不能运用HTTP的GET方法进行登录，由于GET的参数直接拼接到url中，被截获一眼就能知道暗码；且GET的url数据一般会保存在服务器的access log中，因而Hacker假设攻破服务器，只需扫描access log就能取得一切用户的暗码

  • 用自己的电脑在公共场所设置免费Wifi，假设有人衔接了你的Wifi一起运用了一款明文传输暗码的APP，那么他的暗码就会轻易被你获取

3.1.2、HTTPS安全

风险：

  • 在iOS运用程序中，运用HTTPS进行通信是一种更为安全的做法，也是官方所引荐的做法，可是即便运用了 HTTPS，也有或许由于没有校验服务器证书的原因导致 被中心人绑架。假设交互恳求数据处理不当，进犯者能够解密得到明文通信数据；乃至进一步假造App的恳求，这是极大的安全风险

  • 这个检测方法也十分简略，便是翻开APP登录帐号，运用抓包东西如Charles去看是否有恳求获取灵敏信息，比如获取资源包或者文件脚本

ip、域名、DNS、端口、内网、http协议等介绍
  • 2台设备A与B通讯就像2个人写信：
    • ip地址：便是家庭具体地址（省市区具体地址门牌号）
    • 域名：便是ip地址方便记忆的别名（比如这个地址门牌是蜜雪冰城西安路店）
      • 域名解析：从域名解析到ip地址的进程
      • 域名解析是由DNS服务器完结的，当咱们拜访www.baidu.com时，浏览器会向DNS服务器提交域名，DNS服务器回来这个域名的ip地址给浏览器，咱们看到的是经过域名拜访，实践上一切的通讯都是经过ip进行的
      • DNS绑架：Hacker经过 DNS缓存感染或信息绑架 等方法，将过错的ip放回给用户，导致用户被引导到其他不良网站，或者刺进广告等不法意图
    • 端口：便是家中具体收信的人
    • JSON数据：便是信的内容（因轻便简略替换了XML）
    • 内网（局域网）：便是2人的不同小区
      • 假设收件人和寄件人身处经过小区，那他们的ip地址其实只需求包括楼栋和门牌号即可，如(5#1004)，ip地址亦然
      • IPv4地址中预留了3个IP地址段，作为私有地址，共家庭、企业、学校等内部组网运用，最常见的是C类地址段192.168.0.0–192.168.255.255，192.168.1.1 是大多数路由器的ip地址，也便是小区大门的ip地址，这样就能够衔接192.168.1.1(不包括)-192.168.1.255共254台设备，一般家庭路由器运用现已足够了
      • 这样就会导致不同的局域网，或许有相同的ip地址，就像不同的小区都有(5#1004)一样，可是信息依然能够精确送达，正是由于192.168.x.x是局域网地址，假设需求跨小区沟通还需求公网地址
    • 路由器（网关）：便是小区大门，对进出内容进行管控
    • 因特网：便是门外世界
  • 恳求头、响应头、恳求体、响应体：恳求头用于带着附加的信息，GET恳求和POST恳求都包括恳求头，恳求头一般包括：
    • 【Host】：方针地址的地址+端口
    • 【User-Agent】：浏览器的类型
    • 【Content-Length】：恳求音讯内容的长度
    • 【Content-type】：恳求音讯内容的类型，如 application/x-www-form-urlencoded 或application/json；等
ARP诈骗
  • ip与MAC地址关系：当咱们的设备联网时会取得一个在这个局域网内唯一的ip地址，假设没有指定ip地址，咱们的设备每次联网ip地址都或许发生改动；因而ip地址仅代表这个时分，这台设备在网络中的方位，它只代表一个别名，MAC地址也叫作物理地址，类似设备的身份证号，是设备的唯一标识，不论在何种网络环境下，MAC地址都是不会改动的
  • ARP协议用于将IP地址转换为MAC地址；当局域网内的两台设备需求通讯，表面上看它们是经过ip知道对方的方位进行通讯，实践上它们需求先依据ip找到对方的MAC地址，网络设备是经过MAC地址进行通讯的，而非ip地址
  • 运用ARP诈骗的进犯者经过假造数据包ARP报文，向局域网内的网络设备广播，将自己的MAC地址伪装成网关的MAC地址，使得局域网内的网络设备的ARP缓存表中的网关IP对应的MAC地址变为自己设备的MAC地址，此刻其他设备的一切恳求都将发往进犯者的设备上，若进犯者对这些恳求转发至网关或外网，则恳求正常，不然其他设备将悉数断网
  • 进犯者经过ARP诈骗将自己的设备假形成网关，使得衔接这个路由器的一切网络设备的恳求都经过自己的设备，经过这个方法，进犯者无需是路由器的一切者，也无需或者路由器的拜访权限即可捕获乃至修正局域网内网络设备的一切恳求
加密方法
  • 对称加密（AES、DES）：加密和解密是同一把秘钥
  • 非对称加密（RSA）：公私钥一者用于加密则需用别的一者解密
  • Hash算法（MD5）：将任意长度的字符串生成16字节的散列值，不同字符串散列值不同，相同字符串有相同的散列值，而且无法依据散列值倒推回本来的明文，只能从 MD5字符串 – 密文对应表 中匹配暴力破解（字符串简略在对应表中被找到了你就被破解了）
* HTTPS原理与中心人进犯

  • https是指http + SSL/TLS协议，在传输进程中对数据进行加密，开发者无法自己设定加密逻辑

  • 移动端与服务器端经过https进行通讯，数据加密 运用到了非对称加密(一般是RSA)和对称加密，大致流程如下：

    1. 移动端向服务端建议https恳求
    2. 服务端 将之前生成的一对RSA密钥中的公钥回来给客户端
    3. 移动端 随机生成一个对称加密(如AES)的key(密钥)，并经过服务器供给的RSA公钥，对这个key进行加密，将加密后的对称加密key发送给服务端
    4. 服务端 拿到这个对称加密后的key，经过自己的私钥对这个密文进行解密，拿到与移动端进行对称加密通讯的明文key
    5. 服务端与移动端经过这个key加密密文进行通信

    疑问1：
    为什么这个流程这么繁琐？服务端直接把对称加密的密钥给移动端不行吗？

    答：
    服务端把对称加密密钥给移动端的途中，或许被中心人阻拦，中心人取得 对称加密的key 之后，加密形同虚设

  • 中心人进犯流程：

    1. 上述流程中有个很大的缝隙！服务端将RSA非对称加密的公钥发送给移动端的途中，中心人能够将公钥阻拦下来
    2. 中心人自己也创立一对RSA密钥，将中心人的RSA公钥发送给移动端
    3. 移动端 经过这个被篡改的RSA公钥对自己随机生成的对称加密密钥进行加密 后，发送给服务端
    4. 在发送途中，中心人能够将此密文阻拦下来，并经过中心人的RSA私钥进行解密(由于客户端实践上是用自己的公钥加密的)，此刻中心人能够拿到明文的对称加密密钥
    5. 中心人 经过从前截获的服务端的RSA公钥对此对称密钥进行加密，并发送给服务端
    6. 服务端经过自己的RSA私钥能够获取到对称加密密钥的明文，此刻 中心人现已悄然获取了二者将来进行的对称加密通讯的密钥，就能够轻松解密和篡改二者的通讯信息了

    安全措施：
    实践上https通讯进程中还有一个极为重要的人物：CA(Certificate Authority)数字证书颁布组织，CA实践上是指多个威望的证书颁布组织，CA会生成一对公钥和私钥，并将公钥存储于操作体系和浏览器中，经过CA的介入能够完美处理，CA介入以后的加密流程如下：

    1. 移动端向服务端建议https恳求
    2. 服务端将RSA公钥，经过CA的RSA私钥加密，回来给移动端
    3. 移动端拿到加密后的服务器公钥，经过浏览器或体系中预先装置好的CA公钥进行解密
      • 若能够解密，则https恳求能够继续进行，移动端顺畅拿到服务器公钥的明文，并运用这个公钥对随机生成的对称加密密钥加密，将加密后的对称加密key发送给服务端
      • 若无法解密，则代表公钥被篡改，https恳求终止，且浏览器会显现warning
    4. 服务端拿到这个对称加密后的key，经过服务端私钥对这个密文进行解密，拿到与移动端进行对称加密通讯的明文key
    5. 服务端与移动端经过这个key加密密文进行通信
    6. 假设这个加密后的公钥若被中心人阻拦
      • 由于CA的公钥是公开的，所以中心人能够解密并获取服务器的公钥明文
      • 可是中心人无法将服务端公钥替换为自己的公钥，由于需求CA的私钥来对自己的公钥来进行加密
      • 若直接将明文的公钥或是运用别人私钥加密后的公钥提交给客户端，由于客户端中没有能够解密的公钥，https恳求将终止

    疑问2：
    为什么大多数的抓包东西，在我的手机装置一个根证书并让我信赖后，就能够抓到https恳求？

    答：

    1. CA证书防护的是中心人向移动端传递篡改的RSA公钥进程（中心人传递给服务端的进程不论），由于中心人一旦拆开服务端经CA私钥加密的内容，他就装不回去了
    2. 那么只需一种方法，便是换个包装，然后诈骗移动端说这是新包装也是正品请放心运用~
    3. 根证书中包括着一对公钥和私钥，装置根证书并信赖，实践上便是在体系和浏览器的CA公钥列表中刺进中心人的RSA公钥，如此就能让移动端解密私钥然后经过CA身份验证

    留意：

    • 信赖根证书意味着信赖根证书下的一切证书，此操作会极大影响用户的信息安全!!!

    • 避免用户抓取https恳求 –> SSL Pinning：一些运用将服务端的证书直接打包到App中，能够在https树立衔接时对比本地证书与服务器回来的证书信息，若不匹配，则立即终止https衔接；可是由所以在移动端判别证书一致性，因而能够 经过hook的方法修正移动端的判别逻辑来绕过SSL pinning

    • 以上https恳求被阻拦和篡改的条件是，用户自动在设备中装置并信赖了根证书，因而在绝大多数状况下，https能够极大确保用户的信息安全，许多企业和组织开端强制要求开发者运用https进行通讯以确保用户的信息安全

安全计划
  1. 运用POST方法传递暗码
  2. 避免运用有缝隙的第三方网络库(如 AFNetworking < 2.5.3 版别)
  3. 要害数据(如登录暗码、卡号、买卖暗码等)单独加密
  4. App内要对HTTPS证书做校验
  5. 运用非对称加密（RSA），事前生成一对用于加密的公私钥
    • 移动端登录时，运用公钥将用户暗码加密，再将密文传输到服务器
    • 服务器运用私钥解密暗码，然后加盐（Salt：经过在暗码任意方位刺进特定的字符串，让散列后的成果和运用原始暗码的散列成果不相符）
    • 再屡次进行MD5加密，最后与服务器中存储的暗码匹配回来登录成果
  • 留意：

    • 服务器只需求匹配加密后暗码一致，而不是用户明文暗码；这也是现在APP只供给重置暗码而非找回暗码的原因，由于他们也不知道暗码是多少

    • Hacker没有私钥，即便截获密文也无法获悉暗码；而服务器即便被攻破，也无法从加盐并屡次MD5的暗码中复原出原始暗码

    // 这种方法许多时分就够用了
NSString *publicKey = @"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0OiXHaees9Aj5h31YYGw5nfCUdS6MK0T5UrJAfIdwkUbadDOXclDVK+ftBMe+DVAn7xSORPi1cjiBBjU+lo/hmNGoDWQGgxr/LAkaJz3/A1Sv+S1d3deTc6SFN+toDQbpsx3jYOUrJM1B8olUI1a9f+DgzkF/sIKJ7V4Wh7XtlQIDAQAB";
//私钥
NSString *privateKey = @"MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBALQ6Jcdp56z0CPmHfVhgbDmd8JR1LowrRPlSskB8h3CRRtp0M5dyUNUr5+0Ex74NUCfvFI5E+LVyOIEGNT6Wj+GY0agNZAaDGv8sCRonPf8DVK/5LV3d15NzpIU362gNBumzHeNg5SskzUHyiVQjVr1/4ODOQX+wgontXhaHte2VAgMBAAECgYAljox63sXpk70fCq4DMay74P7WYQj/KrEn56S/rXOn8I48TcTGhYr0sT6WdM2O/EU83SSCdTsCzLebo4iK72Mx/VI1alKWSfyncfXi51gZePpgVaudTG9kcI8sszRG+P7zfPptr4HxZ7X2LveJy5myImqQomESEUvDVHdZCtIIgQJBANxT7Bev+LA+jH9gSV4Uc14B5YYabpLso39t/uhTaOdVNxV2eV2UAF1PGg2R3IMwlzHcjRkDDpBiWuXaxbTKCaECQQDRaCUb7J1mPDBrEIi1Aupho16b3Sy82vzZ9WGLgMl+eMKbSy0rAdJA10CtNKL2Gq7EGNoN4CpDPPulJTmm6Cd1AkAajH5BaHHmAtN5McgFbx9rr3zRyPOT/rHA1CdIJWzZmzoU+v6q2P+mPrbb9byFjmBZoMLbxbOGkGN1mQQDweihAkEAkAJ9Mr0AaeSOr7KJMWK16Tu+vpXWRHKdXQ9Ba/y/lThbLQ0AHQl9nJXrprICOBmVgspMeypkJiV0Mdht03joWQJAaF8kDoCNkpp++6aqVbqFBYysiW83AiHgL0JA5dhQ2XzIFYZIpLOsM+Je4yw9ppQ76DqePg6pqRKjR6m9Gatn+A==";
//测试要加密的数据
NSString *sourceStr = @"iOS端RSA加密";
//公钥加密
NSString *encryptStr = [RSA encryptString:sourceStr publicKey:publicKey];
//私钥解密
NSString *decrypeStr = [RSA decryptString:encryptStr privateKey:privateKey];
NSLog(@"公钥加密私钥解密后的数据 %@",decrypeStr);
//私钥加密
NSString *encryptStr1 = [RSA encryptString:sourceStr privateKey:privateKey];
//公钥解密
NSString *decrypeStr1 = [RSA decryptString:encryptStr1 publicKey:publicKey];
NSLog(@"私钥加密公钥解密后的数据 %@",decrypeStr1);
  1. 恳求验签：
    • 假设用户进行登录操作，发送恳求 {“account”:”123″,”pwd”:”456″}，经过将json转化为特定的格局，如 account=123&pwd=456（一般还会加盐)，并对其进行md5加密
    • 将加密后的MD5值放在 sign字段 中，就得到 {“account”:”123″,”pwd”:”456″,”sign”:”MD5加密后的值”} 发送给服务器
    • 服务器拿到这个json的时分，对sign前内容与移动端进行相同的加密操作，比对加密出来的成果与sign值，若相同，则能够以为account和pwd未被篡改，可信赖这个恳求，若不同，则代表必然有信息被篡改，则废弃这个恳求

3.2、通讯协议防护

风险：

  • 移动端除了明文传输暗码问题外，还要面临Hacker破解通讯协议的威胁，假设通讯协议被破解，Hacker能够模拟客户端登录，从而假造用户行为，制造机器人或发送废物广告

安全计划：

  • 能够选择Protobuf（Google供给的开源数据交换格局，特点是根据二进制，因而体积比JSON格局要小）之类的二进制通讯协议，或自己完结通讯协议来对传输内容进行加密

3.3、验证运用内付出凭据

风险：

  • 越狱手机不受沙盒维护，且苹果为了维护用户隐私，付出凭据中不包括任何账号信息（类似于不记名购物卡），因而对越狱手机Hacker或许截获付出凭据转手倒卖

安全计划：

  • 验证付出凭据真伪的一起，也需求告知用户在越狱手机上付出的风险

3.4、避免网络恳求被Charles抓包

  • 要进犯一个APP ，抓包是必不可少的，那么怎么避免被Charles 之类（中心人进犯类型）的抓包软件抓包呢？首要有以下几个思路：
    1. 检测是否运用了署理，检测到运用了署理就封闭网络恳求
    2. 运用自签名证书的运用和双向验证的运用
    3. 经过 HTTP/1.1 及以上版别的 CONNECT 恳求方法
    4. 对回来的数据进行加密(RSA | token | AES128 等，不防抓包，增加解密难度)
3.4.1、绕过署理发送恳求

  • 关于杂乱的APP，有许多接口是不必加密的，这样就呈现了防署理形式

  • 署理检测：当进行网络恳求的时分，客户端判别当时是否设置了署理，假设设置了署理，不答应进行拜访数据，示例：

    + (BOOL)getProxyStatus {
    NSDictionary *proxySettings = NSMakeCollectable([(NSDictionary *)CFNetworkCopySystemProxySettings() autorelease]);
    NSArray *proxies = NSMakeCollectable([(NSArray *)CFNetworkCopyProxiesForURL((CFURLRef)[NSURL URLWithString:@"http://www.google.com"], (CFDictionaryRef)proxySettings) autorelease]);
    NSDictionary *settings = [proxies objectAtIndex:0];
    NSLog(@"host=%@", [settings objectForKey:(NSString *)kCFProxyHostNameKey]);
    NSLog(@"port=%@", [settings objectForKey:(NSString *)kCFProxyPortNumberKey]);
    NSLog(@"type=%@", [settings objectForKey:(NSString *)kCFProxyTypeKey]);
    if ([[settings objectForKey:(NSString *)kCFProxyTypeKey] isEqualToString:@"kCFProxyTypeNone"]) {
        //没有设置署理
        return NO;
    } else {
        //设置署理了
        return YES;
    }
}

  • 绕过署理恳求设置：假设在初始化NSURLSession的时分将 connectionProxyDictionary特点设置为空，那么，当手机开启了署理服务（如：Charles ）的时分，用这个 session 建议的网络恳求并不会去走这个署理，而且默许的不走署理直接建议网络恳求

    // 关于H5页面的网络恳求仍是能够抓到的 configuration.connectionProxyDictionary = @{};

    #import "NSURLSession+SafeHttpProxy.h"
#import "SafeURLProtocol.h"
#import <objc/runtime.h>
static BOOL isDisableHttpProxy = YES;
@implementation NSURLSession (SafeHttpProxy)
+(void)load{
    [super load];
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, {
        [NSURLProtocol registerClass:[SafeURLProtocol class]];
        Class class = [NSURLSession class];
        [self swizzingMethodWithClass:class orgSel:NSSelectorFromString(@"sessionWithConfiguration:") swiSel:NSSelectorFromString(@"Safe_sessionWithConfiguration:")];
        [self swizzingMethodWithClass:class orgSel:NSSelectorFromString(@"sessionWithConfiguration:delegate:delegateQueue:") swiSel:NSSelectorFromString(@"Safe_sessionWithConfiguration:delegate:delegateQueue:")];
    });
}
+(void)disableHttpProxy{
    isDisableHttpProxy = YES;
}
+(void)enableHttpProxy{
    isDisableHttpProxy = NO;
}
+(NSURLSession *)Safe_sessionWithConfiguration:(NSURLSessionConfiguration *)configuration
                                    delegate:(nullable id<NSURLSessionDelegate>)delegate
                               delegateQueue:(nullable NSOperationQueue *)queue{
    if (!configuration){
        configuration = [[NSURLSessionConfiguration alloc] init];
    }
    if(isDisableHttpProxy){
        configuration.connectionProxyDictionary = @{};
    }
    return [self Safe_sessionWithConfiguration:configuration delegate:delegate delegateQueue:queue];
}
+(NSURLSession *)Safe_sessionWithConfiguration:(NSURLSessionConfiguration *)configuration{
    if (configuration && isDisableHttpProxy){
        configuration.connectionProxyDictionary = @{};
    }
    return [self Safe_sessionWithConfiguration:configuration];
}
+(void)swizzingMethodWithClass:(Class)cls orgSel:(SEL) orgSel swiSel:(SEL) swiSel{
    Method orgMethod = class_getClassMethod(cls, orgSel);
    Method swiMethod = class_getClassMethod(cls, swiSel);
    method_exchangeImplementations(orgMethod, swiMethod);
}
@end

  • 开VPN时或许会误伤APP导致无法运用

3.4.2、经过 HTTP/1.1 及以上版别的 CONNECT 恳求方法
  • 什么是CONNECT 恳求？

    • 平常工作中，GET 跟 POST 是咱们用的比较多的恳求方法，HTTP/1.0 界说了三种恳求方法： GET, POST 和 HEAD方法

    • HTTP/1.1 新增了五种恳求方法：OPTIONS、 PUT、DELETE、 TRACE 和 CONNECT 方法

    • CONNECT 首要是把服务器作为跳板，先验证用户名和暗码等信息，再让服务器代替用户去拜访其它网页，之后把数据回来给用户

  • 之所以说采用 CONNECT 恳求当跳板，能够避免Charles抓包，是由于 Charles 抓 CONNECT 的恳求，会识别为unknown，所以就能到达防抓包的意图
3.4.3、SSL Pinning

经过 对服务端生成的.cer证书进行域名校验，服务器经过.crt证书导出.cer放到客户端进行处理

  • NSURLSession处理

    - (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void ()(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler {
    //得到长途证书
    SecTrustRef serverTrust = challenge.protectionSpace.serverTrust;
    SecCertificateRef certificate = SecTrustGetCertificateAtIndex(serverTrust, 0);
    //设置ssl方针来检测主域名
    NSMutableArray *policies = [NSMutableArray array];
    [policies addObject:(__bridge_transfer id)SecPolicyCreateSSL(true, (__bridge CFStringRef)challenge.protectionSpace.host)];
    //验证服务器证书
    SecTrustResultType result;
    SecTrustEvaluate(serverTrust, &result);
    BOOL certificateIsValid = (result == kSecTrustResultUnspecified || result == kSecTrustResultProceed);
    //得到本地和长途证书data
    NSData *remoteCertificateData = CFBridgingRelease(SecCertificateCopyData(certificate));
    BOOL allChrls = NO;
    allChrls = DebugNet;
    if (allChrls) {
        NSURLCredential *credential = [NSURLCredential credentialForTrust:serverTrust];
        completionHandler(NSURLSessionAuthChallengeUseCredential,credential);
    }else{
        NSString *pathToCer = [[NSBundle mainBundle] pathForResource:@"xiaoqi" ofType:@"cer"];
        NSData *localCertificate = [NSData dataWithContentsOfFile:pathToCer];    //查看
        if ([remoteCertificateData isEqualToData:localCertificate] && certificateIsValid) {
            self.allowTask = YES;
            NSURLCredential *credential = [NSURLCredential credentialForTrust:serverTrust];
            completionHandler(NSURLSessionAuthChallengeUseCredential,credential);
        }else {
            self.allowTask = NO;
            [_dataTask cancel];
            [_downloadTask cancel];
            [_uploadTask cancel];
            completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge,NULL);
        }
    }
}

  • AF中自界说

    // 自界说安全策略
+ (AFSecurityPolicy *)customSecurityPolicy {
    // 获取证书
    NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"xiaoqi" ofType:@"cer"];
    NSData *certData = [NSData dataWithContentsOfFile:cerPath];
    NSSet *pinnedCertificates = [[NSSet alloc] initWithObjects:certData, nil];
    /*
     安全形式
     AFSSLPinningModeNone：完全信赖服务器证书；
     AFSSLPinningModePublicKey：只比对服务器证书和本地证书的Public Key是否一致，假设一致则信赖服务器证书；
     AFSSLPinningModeCertificate：比对服务器证书和本地证书的一切内容，完全一致则信赖服务器证书
     */
    AFSecurityPolicy *securityPolicy =
    [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey
                     withPinnedCertificates:pinnedCertificates];
    // allowInvalidCertificates 是否答应无效证书（也便是自建的证书），默许为NO
    // 假设是需求验证自建证书，需求设置为YES
    securityPolicy.allowInvalidCertificates = YES;
    /*
    validatesDomainName 是否需求验证域名，默许为YES；
    假设证书的域名与你恳求的域名不一致，需把该项设置为NO；
    如设成NO的话，即服务器运用其他可信赖组织颁布的证书，也能够树立衔接，这个十分风险，建议翻开。
    置为NO，首要用于这种状况：客户端恳求的是子域名，而证书上的是别的一个域名。
    由于SSL证书上的域名是独立的，假设证书上注册的域名是www.google.com，那么mail.google.com是无法验证经过的；
    当然，有钱能够注册通配符的域名*.google.com，但这个仍是比较贵的。
    如置为NO，建议自己增加对应域名的校验逻辑。
     */
    securityPolicy.validatesDomainName = YES;
    return securityPolicy;
}

  • 证书会失效，证书由所以服务端生成的依据域名来的，所以一般最长的是一年的证书，到期不换或许会对接口恳求发生问题

结语：

APP的安全防护是门很深奥的学问，参阅市面上的三方防护服务就知道还有许多许多要学习的当地，后续要涉及逆向方面的常识，大家依据需求学习提升吧

iOS-安全防护

参阅链接：

www.jianshu.com/p/dc5cef72f…
blog.csdn.net/g270382086/…
cloud.tencent.com/developer/a…