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

Dear，大家好，我是“前端小鑫同学”，😇长期从事前端开发，安卓开发，热衷技术，在编程路上越走越远～

背景介绍：

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

重构报文格式：

重构后的报文格式如下由header和request两部分构成我们的请求报文格式，响应报文格式类比请求报文。

在header中指明请求的业务位置requestType。

header报文发送的来源from，主要区别为PC端，Android端，IOS端或H5端。

header报文与服务端协商的固定表示appKey，来保证C端发送的合法性，阻止未知客户端请求。

在request中添加接口实际需要的业务数据内容。

{
 "packages": {
     "header": {
         "requestType": "",
         "appKey": "",
         "from": ""
     },
     "request": {
         "uasrname": "",
         "password": ""
     }
 }
}

前端发送报文加密过程：

组装如上格式的报文信息；

将request中的JSON对象转为字符串并使用3DES加密算法进行请求数据的加密并将加密后的数据替换原报文的request的内容；

将这个报文JSON对象转字符串后使用加盐的MD5算法进行整体报文的验签生成；

发送加密报文：

我们报文统一采用POST请求方式；

我们使用MD5生成的验签由url携带传递。

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

通过相同的加盐MD5对POST发送来的报文进行再次验签生成与url携带的验签对比，信息一致进行下一步；

解析报文中未加密的header部分来对报文合法做初次筛选，合法后进行下一步；

使用前后端一致的3DES加解密秘钥进行报文解密后交由对应的业务层使用。

原始资料图片：

image.png

image.png

总结：

以上加密为半加密处理即只针对报文中的业务数据加密，也可以考虑将header一同加密（全加密）；

以上采用的3DES对称加密算法进行加解密，秘钥的安全存储需要着重考虑；

以上采用加盐MD5保证接收前后的报文一致性；

报文安全可考虑的地方还有不少，安全渗透的公司会经常做重放测试等；

加解密也是相对的，破解的事会干也不能干。