那些年我们项目中的报文安全实践

背景介绍：

防止报文被窃取后暴露报文中的关键信息，如用户信息，产品信息，交易信息等敏感内容。报文重放和防止窃取不在这次考虑范围。

重构报文格式：

1. 重构后的报文格式如下由header和request两部分构成我们的请求报文格式，响应报文格式类比请求报文。
2. 在header中指明请求的业务位置requestType。
3. header报文发送的来源from，主要区别为PC端，Android端，IOS端或H5端。
4. header报文与服务端协商的固定表示appKey，来保证C端发送的合法性，阻止未知客户端请求。
5. 在request中添加接口实际需要的业务数据内容。

{
    "packages": {
        "header": {
            "requestType": "",
            "appKey": "",
            "from": ""
        },
        "request": {
            "uasrname": "",
            "password": ""
        }
    }
}
复制代码

前端发送报文加密过程：

1. 组装如上格式的报文信息；
2. 将request中的JSON对象转为字符串并使用3DES加密算法进行请求数据的加密并将加密后的数据替换原报文的request的内容；
3. 将这个报文JSON对象转字符串后使用加盐的MD5算法进行整体报文的验签生成；

发送加密报文：

1. 我们报文统一采用POST请求方式；
2. 我们使用MD5生成的验签由url携带传递。

服务端接收报文后解密过程：

1. 通过相同的加盐MD5对POST发送来的报文进行再次验签生成与url携带的验签对比，信息一致进行下一步；
2. 解析报文中未加密的header部分来对报文合法做初次筛选，合法后进行下一步；
3. 使用前后端一致的3DES加解密秘钥进行报文解密后交由对应的业务层使用。

原始资料图片：

总结：

1. 以上加密为半加密处理即只针对报文中的业务数据加密，也可以考虑将header一同加密（全加密）；
2. 以上采用的3DES对称加密算法进行加解密，秘钥的安全存储需要着重考虑；
3. 以上采用加盐MD5保证接收前后的报文一致性；
4. 报文安全可考虑的地方还有不少，安全渗透的公司会经常做重放测试等；
5. 加解密也是相对的，破解的事会干也不能干。