移动安全协议
概述
安全的移动客户端交互协议对于业务系统来说越来越重要，由于移动协议通常是无状态协议，也就是说没有session的概念，所以协议的暴露会带来无可估量的风险及损失。如果竞争对手或者别有用心的人通过抓包或者反编译的方式获取交互协议，等于获得无限制的系统业务数据的操作权限。
本文主要需要考虑以下问题：
- 传输安全性
- 安全成本
- 与旧协议的兼容性
- 平台兼容性
- 预防DDOS攻击
- Native App 与 Web App安全性实现差别
Native App 安全协议
思路
- 算法安全
反编译是指用户通过对编译后的执行文件进行处理，获得代码源码，进而获取加密算法。解决反编译的问题比较简单，使用dll或者so库，使用c++语言对核心加密模块进行封装。
- 有效性判断
有效性判断主要用来解决复制请求的问题。比如新增协议，因为Create方法通常不是幂等协议，所以多次调用就可能会造成非法数据的生成。可以使用时间、签名等方式解决。
- 内容安全
内容安全主要是针对上行协议内容在传输阶段被监听拦截的问题。解决方法通常有两种：算法加密，序列化(一般会转化成byte[])。由于有有效性判断,上行不正确无法获取有效的下行，所以下行可以采用明文。如果考虑到加密性能可以不能满足要求，可以在某些请求上不进行内容加密。
- 关于对旧协议兼容性问题
所有校验可以在请求之前进行统一处理，比如使用拦截器来完成。
流程设计
算法设计
1. Http Header
Content-Type:xxxx
Date:xxxx(GMT)
Version:xxxx
Authorization:xxxx
ctsi-user:xxxx
ctsi-algorithm:1
2. 签名算法
本算法设计参考 阿里云OSS服务设计
Authorization
Authorization ="CTSI " + UserId + ":" + Signature?
UserId
可以是手机号，也可以不需要
Signature
Signature = base64(hmac-sha1( PublicKey ,
VERB + "\n”
+ Content-MD5 + "\n"
+ Content-Type + "\n"
+ Date + "\n"
+ CtsiHeaders))
PublicKey
可以内部写死，或者使用其他公共Key。
CtsiHeaders
- header的名字需要变成小写。
- header按字典序自小到大排序。
- 分割header name和value的冒号前后不能有空格。
- 每个Header之后都有一个换行符“\n”
3. 有效性校验
DDOS校验
同一IP连续访问接口xx次以上，则校验失败
时间戳校验
如果时间戳与服务器时间相差xxx秒以上，则校验失败
签名校验
按照签名规则重新生成并比对Header中的签名，如果签名不一致则校验失败。
4. 加密与序列化
略，如需要，必须考虑服务器侧解密性能
DEMO
略
Web App 安全协议
思路
Web App相对于Native App需要面临的问题是：
- 必须在Client端进行加密、签名,JS脚本文件对于用户来说完全开放,存在无法避免的破译风险。
- Https或者仿Https的协议会影响协议交互效率，并且需要额外的资源。
- 桌面端的抓包工具比移动端更加容易获得和使用。
所以我们解决Web App的思路应该是: 使用前端js技术,尽可能增加对方破解成本
流程设计
DEMO
DDOS攻击
以上安全协议只是在协议通讯层面保证了安全,但是也存在通过重复发送捕获协议攻击服务器的情况,所以需要防火墙做相关设置防止DDOS攻击。