1. 客户端防护

1.客户端双向认证。在app中预置证书（跨平台也是一致的方案），要求更高的话使用专用的证书设备，线下签发，例如银行的U盾。
2.客户端双反hook，反调试，防逆向。
3.客户端运行环境校验，通过读取硬件信息识别pc还是移动设备以及设备MAC相关信息。

2. 传输层防护

1.传输协议防护，首先接口建议使用 HTTPS 协议，这样至少会给破解者在抓包的时候提高一些难度。

3. 服务端防护

1.验证签名与授权信息是否合法，是否失效。
2.参数合法性校验，例如时间戳和参数签名校验。过滤一些非法参数。
3.数据加密，签名可以采用非对称加密，参数采用对称加密，密匙采用非对称的私匙。
4.定时更新签名以及加密信息。
5.接口监控，接口的使用设备，使用频率，调用顺序是否合法。
6.风控策略防护，有一点作用但是对于有明确指向性的攻击意义不大，IP可以换，频率可以变，很容易就绕过了，策略的设计上要注意尽量少用短命的规则，而且一般只对低级别的对抗有效。
7.通过风控平台进行用户行为分析，数据挖掘，然后通过机器学习形成风控模型，对风险进行全方位识别，预警以及管控。

4. 安全鉴权案例

4.1 微盟开放平台

微盟也是根据OAuth2.0授权流程实现。

微盟鉴权文档地址：https://cloud.weimob.com/saas/word/detail.html?tag=564&menuId=2

4.2 微信开放平台

微信开放平台授权需要7部才能完成，并且在此之前还需要通过开放平台开发配置，数据通过AES加密验证。
1、配置授权事件URL，用于接收[component_verify_ticket]。
2、获得component_verify_ticket后，按照[获取第三方平台 component_access_token]接口文档，调用接口获取component_access_token。
3、获得component_access_token后，按照[获取预授权码 pre_auth_code]接口文档 ，调接口获取pre_auth_code。
4、获得pre_auth_code后，按照[授权技术流程说明]文档 ，引导用户授权后获取authorization_code
5、获得authorization_code后，按照[使用授权码换取公众号或小程序的接口调用凭据和授权信息]接口文档 ，调接口获取authorizer_refresh_token。
6、获得authorizer_refresh_token后，按照[获取/刷新授权公众号或小程序的接口调用凭据]接口文档 ，调接口获取authorizer_access_token。
7、按照接口文档，代替公众号或小程序调用接口。

微信开放平台授权文档地址：https://developers.weixin.qq.com/doc/oplatform/Third-party_Platforms/2.0/api/Before_Develop/creat_token.html

1 / 验证码（最简单有效的防护），采用点触验证，滑动验证或第三方验证码服务，普通验证码很容易被破解

2 / 频率，限制同设备，同IP等发送次数，单点时间范围可请求时长

3 / 归属地，检测IP所在地是否与手机号归属地匹配；IP所在地是否是为常在地

4 / 可疑用户，对于可疑用户要求其主动发短信（或其他主动行为）来验证身份

5 / 黑名单，对于黑名单用户，限制其操作，API接口直接返回success，1可以避免浪费资源，2混淆黑户判断

—

6 / 签名，API接口启用签名策略，签名可以保障请求URL的完整安全，签名匹配再继续下一步操作

7 / token，对于重要的API接口，生成token值，做验证

—

8 /  https，启用https，https 需要秘钥交换，可以在一定程度上鉴别是否伪造IP

9 / 代码混淆，发布前端代码混淆过的包

10 /  风控，大量肉鸡来袭时只能受着，同样攻击者也会暴露意图，分析意图提取算法，分析判断是否为恶意 如果是则断掉；异常账号及时锁定；或从产品角度做出调整，及时止损。

11 / 数据安全，数据安全方面做策略，攻击者得不到有效数据，提高攻击者成本

12 / 恶意IP库，https://threatbook.cn/，过滤恶意IP

tips：

鉴别IP真伪（自己识别代理IP和机房IP成本略高，可以考虑第三方saas服务。由肉鸡发起的请求没辙，只能想其他方法）

手机号真伪（做空号检测，同样丢给供应商来处理，达不到100%准确率，效率感人，并且不是实时的，可以考虑选择有防攻击的运营商）

安全问题是长期的和攻击者斗智斗勇的问题，没有一劳永逸的解决方案，不断交锋，不断成长

--------------------- 本文来自 初见-子非鱼 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/a895458278/article/details/78655461?utm_source=copy

【0】使用https保证网络传输的安全；

【1】中间人攻击防范策略：
接口调用身份私钥签名公钥验签，这种方式既可以防止参数在传输过程中被篡改，因为一旦篡改，sing签名将对应不上，调用失败；
同时使用公钥和配对的私钥进行签名和验签，保证了服务端和客户端的身份

【2】重放攻击防范策略：
客户端第一次请求使用签名sign，服务端验证通过，给客户端返回一个唯一的订单号，并将该订单号存放在redis缓存中（为了防止脏数据的挤压，给该订单号60秒的过期时间），
客户端接收到该订单号，继续使用签名算法并带上这个订单号请求服务器，服务器验证签名，并验证订单号的存在，
如果签名正确（保证客户端身份），同时订单号存在，则继续处理业务，并将该订单号删除，严格保证充值，消费，转账等接口不被重放；
如果用户在第一次请求的时候被中间人拦截掉请求的所有信息，中间人伪装成客户，请求服务器，
这个时候服务器只是返回一个订单号，因为中间人没有加密算法和公钥，所以不能成功封装第二次请求信息，

如果用户在第二次请求的时候被中间人拦截掉请求的所有信息，中间人伪装成客户，请求服务器，
因为服务器缓存了该订单号并且在验签成功之后业务处理完成，将该订单号删除了，所以真实客户和中间人只能有一个
请求成功，即使中间人请求成功，请求参数也和客户是一模一样的，

这样就保证了该接口不能被重放攻击；
针对POS机移动设备设备，登陆成功之后，更新针对这台设备的秘钥加密之后发送给他，这样反编译获取的那个秘钥也就没用了，之后的秘钥就在内存里面更新

为了保护接口的安全和核心代码不被二次打包，感觉客户端还是需要做些反编译的工作，这属于系统级别的安全。
可以借助第三方安全平台：http://www.ijiami.cn/做apk加密