前后端交互如何保证安全性？ _前后端

前言

文章插图

web与后端，andorid与后端，IOS与后端，像这种类型的交互其实就属于典型的前端与后端进行交互。在与B端用户进行交互的过程中，我们通常忽略了其安全性（甚至从未考虑安全性）。比如，请求和响应数据的明文传输，对接口并没有做严格的身份校验。如果我们还是按照这种思路去做C端用户的交互，那么等待着必将是血淋淋的教训。接下来，我带领大家如何在与C端用户安全的进行交互。
【前后端交互如何保证安全性？】保证安全性的几种方式
前后端安全性的交互，大致可以分成如下几类：
1、通信请求使用https
2、对请求参数进行签名，防止数据被踹改
3、对请求参数以及响应进行加密解密处理
4、App中使用ssl pinning防止抓包操作
使用https
谷歌 Chrome 在18年七月份已经将所有的 HTTP 网站标记为“不安全” 。并且已经有越来越多的第三方服务开始推荐甚至是强制要求使用 HTTPS 连接方式，比如现在用得特别多的微信登录、微信支付、短信验证码、地图 API 等等，又比如苹果公司 2016 年在 WWDC 上宣称，公司希望官方应用商店中的所有 iOS App 都使用安全的 HTTPS 链接与服务器进行通信。
那为什么越来越多的 HTTP 都在逐渐 HTTPS 化？HTTP 协议（超文本传输协议）是客户端浏览器或其他程序与 Web 服务器之间的应用层通信协议；HTTPS 协议可以理解为 HTTP+SSL/TLS，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输，http与https的区别如下图所示：

文章插图

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

所有信息都是加密传播，第三方无法窃听。
具有校验机制，一旦被篡改，通信双方会立刻发现。
配备身份证书，防止身份被冒充。

因此强烈建议，为了你的系统安全性，赶快切到https中去吧。
对请求进行签名
我们先来看一个例子，假设用户在下完单之后，可以更改订单的状态，用户对后端发起请求 /user?orderId=123, 假设后端刚好也没有对这笔订单的身份进行验证，那么后果就是，我们根据orderId, 将这笔订单的状态进行了修改：

文章插图

文章插图

如果这时候，尝试着将请求中的orderId 换成另外一个orderId, 也会同样对这笔订单做了修改，从安全角度来说这是我们不希望看到的，当然我们也可以加一下身份校验，判断该笔订单是否属于当前的用户；除此之外，我们还应该对请求参数做一次签名处理。
加签和验签就是在请求发送方将请求参数通过加密算法生成一个sign值，放到请求参数里；请求接收方收到请求后，使用同样的方式对请求参数也进行加密得到一个sign值，只要两个sign值相同，就说明参数没有被篡改。
签名参数sign生成的方法

将所有以头参数(注意时所有参数)，出去sign本身，以及值是空的参数，按参数键字母升序排序。
然后把排序后的参数按参数1值1参数2值2......参数n值n(这里的参数和值必须是传输参数的原始值，不能是经过处理的，如不能将"转成"后再拼接)的方式拼接成一个字符串。
把分配给接入方的验证密钥key拼接在第2步得到的字符串前面。
在上一步得到的字符串前面加上密钥key(这里的密钥key是接口提供方分配给接口接入方的)，然后计算md5值，得到32位字符串，然后转成大写,得到的字符串作为sign的值放到请求参数里。

举例
现在假设需要传输的数据:/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn(实际情况最好是通过post方式发送)