Android开发技术周报182学习记录

教程

App安全二三事

记录

为什么要安全

App的移动安全主要包括下面几种：

密钥破解，导致本地加密数据被盗取。
通信密钥破解，导致接口数据被盗取。
伪造接口数据上报。
接口签名被破解，导致接口可以被重放攻击。

归结起来，就是三种模式：

diamante反编译。
so破解。
中间人攻击。

用户要的安全

对于用户来说，他所需要的安全，是自己的铭感数据不被泄漏，不被第三方所知晓，所以，客户端数据的安全，一般会使用加密的方式保证安全。

本地加密

proguard混淆，最简单的加密，成本最低，只是加大了阅读难度。
通过Dexguard、各种第三方so加固服务、加壳服务等方式来进行保护，极大的增加破解这的破解成本。
密钥的加密也可以加强。

接口加密

接口上的安全，最基本的保证就是Https，同时对SSL协议的域名进行校验，在此之上，请求的接口上，一般会带上一个签名，或者叫token，这个加密的密钥串，就是身份的象征，一般来说，这个签名也就是通过本地密钥来进行生成的。

服务端要的安全

服务端需要的安全，主要是希望收到的请求，都真实的来自正常用户的正常触发。
但客户端在由不受信第三方（比如用户）控制的情况下，基本不存在能够验证请求是来自“自己的”客户端的方法，只能通过以下两种方式来增加破解者的破解成本。

本地密钥+算法，用于生成接口签名，难点在于如何保证本地密钥和算法的安全性。
动态密钥，将密钥的生成放在服务端，难点在于如何保证通信协议的安全性，同时也需要本地密钥来保证请求动态密钥的接口安全。

动态密钥方案，需要在保证通信协议安全的情况下，才有实现价值，设置网络请求框架的NO_PROXY模式，就是一个最简单的方案。

考虑到服务器设备的安全性，目前主流的防作弊检测都是在服务端进行，当然最主要的原因还是本地根本无法保证绝对的安全。

识别用户请求链路

根据必要的API调用流程和闭环，限制一组API调用中不同个体API的调用频率（相对次数）限制。设定几个硬币的参数关联逻辑，是跟业务逻辑环环相扣的，如果其他人想要自己拼装参数，往往会打破这个隐秘约束。
但这个检测通常需要耗费一定的系统资源，同时，当业务比较复杂时，如何保证请求检测的实时性和高效性，就成了一个很难平衡的问题。

网关层拦截、人机识别

网关层拦截同IP的大量重复请求，设置同IP访问的阈值。
大数据识别，对识别为恶意请求的进行封号处理。

TCP加密

目前大部分的App都是通过Http来进行数据交互，但基于TCP，可以实现自己的通信协议，另外，利用TCP包的无序性来增加破解的难度，这样，利用TCP心跳来维持一个安全的通信通道，也不错，但是操作难度比较大。

修改业务逻辑处理方式

在设计业务技术实现方案时，将业务判断逻辑放在后端，客户端只做指令算法，判断是否生效，在服务端进行判断。

后现代安全

量子加密、白盒加密、人工智能分析，这些基本都是下一代的安全策略。