App 数据安全篇

之前的研究了 web 站点的数据安全，同时也用文章记录下来分享给大家。接着又研究了下 App 的安全，同样写文章记录下来

现状

目前 App 的安全比较低，体现在哪？很多人在想用了 HTTPS 不是就很安全吗？其实并不是，专业的抓包工具还是可以抓 HTTPS 包。根据接口规律，做自动化请求接口，将数据保存窃取是我们不想看到的结果。所以如果只用了 HTTPS 还是不安全。

所以需要实现的安全表现在：1. App 数据防止抓包；2. 防止中间人攻击；3. 下下策。即使抓包成功拿到的数据也是密文。如果想解密，是不可逆的。

解决方案

App 数据防止抓包

原理：抓包工具工作原理见文章

验证证书的真伪其实一般来说这个过程应该是安全的，因为一般的证书都是由操作系统来管理。所以只要操作系统没有证书链验证等方面的 bug 是没有什么问题的，但是为了抓包其实我们是在操作系统中导入了中间人的 CA，这样中间人下发的公钥证书就可以被认为是合法的，可以通过验证的（中间人既承担了颁发证书，又承担了验证证书，通过验证）。

措施：客户端为了解决这个问题，最好的方式其实就是内嵌证书，比对一下这个证书到底是不是自己真正的“服务端”发来的，而不是中间被替换了。
- 跟服务端人员拿到 https 证书，导入 Xcode 工程项目中
- AFNetworking设置以下代码
```
AFSecurityPolicy * policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
manager.securityPolicy = policy;
```
  AF的安全策略会自动的在bundle里面查找公钥证书，建立https的时候进行比对。不一样直接就失败了。
  
  AFNetworking 的 AFSSLPinningMode 的三个级别
  
  　　AFSSLPinningModeNone: (默认级别)，客户端无条件信任任何下发的公钥证书
  
  　　AFSSLPinningModePublicKey: 客户端本地去验证服务端下发的公钥证书的 public keys部分。如果正确才通过
  
  　　AFSSLPinningModeCertificate: 客户端本地去验证服务端下发的公钥证书的所有部分。如果正确才通过
  
  这样做了之后，就可以即使手机上安装了抓包工具的CA，抓包工具也不能抓到包了。因为你的客户端在验证“服务端”下发的公钥证书的真伪的时候就不会通过“中间人”下发的公钥证书，也就不会建立起来https的连接了。
防止中间人攻击

即使我们的 App 被大神逆向了（iOS + 网络精通），抓到网络请求，然后原封不动去向服务器发起请求，但是服务端做了防重放，也是很安全的。所以防重放机制是 Server 端的安全措施

防重放
密文，反向解密不可逆

采用 RSA 非对称加密算法。
- iOS 端和 Server 端各生成自己的公钥和私钥
  
  使用 openssl 生成所需秘钥
- iOS 端生成的公钥和私钥定义为 iOSPublicKey、iOSPrivateKey，Server 端生成的公钥私钥定义为ServerPublicKey、ServerPrivateKey。将 **iOSPublicKey ** 给 Server 端使用，让它用 **iOSPublicKey ** 加密数据传给 iOS 端，iOS 端用 iOSPrivateKey 解密；Server 端将 ServerPublicKey 给 iOS 端，iOS 端用 ServerPublicKey 加密数据后上传给 Server 端，Server 端利用 ServerPrivateKey 去解密，这样就实现了数据传输过程中的加密与解密
资料

RSA算法原理（一）

RSA算法原理（二）

素数

防重放

4.2 KiB Raw Blame History Unescape Escape

App 数据安全篇

现状

解决方案

资料

4.2 KiB

Raw Blame History