mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 04:17:17 +00:00
85 lines
4.2 KiB
Markdown
85 lines
4.2 KiB
Markdown
# App 数据安全篇
|
||
|
||
> 之前的研究了 web 站点的数据安全，同时也用[文章](https://github.com/FantasticLBP/Anti-WebSpider)记录下来分享给大家。接着又研究了下 App 的安全，同样写文章记录下来
|
||
|
||
|
||
|
||
## 现状
|
||
|
||
目前 App 的安全比较低，体现在哪？很多人在想用了 HTTPS 不是就很安全吗？其实并不是，专业的抓包工具还是可以抓 HTTPS 包。根据接口规律，做自动化请求接口，将数据保存窃取是我们不想看到的结果。所以如果只用了 HTTPS 还是不安全。
|
||
|
||
所以需要实现的安全表现在：1. App 数据防止抓包；2. 防止中间人攻击；3. 下下策。即使抓包成功拿到的数据也是密文。如果想解密，是不可逆的。
|
||
|
||
|
||
|
||
## 解决方案
|
||
|
||
1. App 数据防止抓包
|
||
|
||
原理：抓包工具工作原理见[文章](https://github.com/FantasticLBP/knowledge-kit/blob/master/第四部分%20开发杂谈/4.10.md)
|
||
|
||
|
||
|
||
**验证证书的真伪**其实一般来说这个过程应该是安全的，因为一般的证书都是由操作系统来管理。所以只要操作系统没有证书链验证等方面的 bug 是没有什么问题的，但是为了抓包其实我们是在操作系统中导入了中间人的 CA，这样中间人下发的公钥证书就可以被认为是合法的，可以通过验证的（中间人既承担了颁发证书，又承担了验证证书，通过验证）。
|
||
|
||
|
||
|
||
措施： 客户端为了解决这个问题，最好的方式其实就是内嵌证书，比对一下这个证书到底是不是自己真正的“服务端”发来的，而不是中间被替换了。
|
||
|
||
- 跟服务端人员拿到 https 证书，导入 Xcode 工程项目中
|
||
|
||
- AFNetworking设置以下代码
|
||
|
||
```objective-c
|
||
AFSecurityPolicy * policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
|
||
manager.securityPolicy = policy;
|
||
```
|
||
|
||
AF的安全策略会自动的在bundle里面查找公钥证书，建立https的时候进行比对。不一样直接就失败了。
|
||
|
||
AFNetworking 的 AFSSLPinningMode 的三个级别
|
||
|
||
AFSSLPinningModeNone: (默认级别)，客户端无条件信任任何下发的公钥证书
|
||
|
||
AFSSLPinningModePublicKey: 客户端本地去验证服务端下发的公钥证书的 public keys部分。如果正确才通过
|
||
|
||
AFSSLPinningModeCertificate: 客户端本地去验证服务端下发的公钥证书的所有部分。如果正确才通过
|
||
|
||
这样做了之后，就可以即使手机上安装了抓包工具的CA，抓包工具也不能抓到包了。因为你的客户端在验证“服务端”下发的公钥证书的真伪的时候就不会通过“中间人”下发的公钥证书，也就不会建立起来https的连接了。
|
||
|
||
2. 防止中间人攻击
|
||
|
||
即使我们的 App 被大神逆向了（iOS + 网络精通），抓到网络请求，然后原封不动去向服务器发起请求，但是服务端做了防重放，也是很安全的。所以防重放机制是 Server 端的安全措施
|
||
|
||
[防重放](https://www.cnblogs.com/yjf512/p/6590890.html)
|
||
|
||
3. 密文，反向解密不可逆
|
||
|
||
采用 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算法原理（一）](http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html)
|
||
|
||
[RSA算法原理（二）](http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.htmll)
|
||
|
||
[素数](https://zh.wikipedia.org/zh-cn/互質)
|
||
|
||
[防重放](https://www.cnblogs.com/yjf512/p/6590890.html)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|