前言Web与后端，andorid与后端，ios与后端，这种交互其实就是典型的前后端交互。在与B端用户交互的过程中，我们通常会忽略他们的安全性（甚至从不考虑安全性）。例如，请求和响应数据的明文传输，没有对接口进行严格的身份验证。如果我们还按照这种思路去做C端的用户交互，那么等待将是血淋淋的教训。接下来，我将指导大家如何安全地与C端用户进行交互。保障安全的几种方式前后端安全交互大致可以分为以下几类：2018年7月，谷歌浏览器已将所有HTTP网站标记为“不安全”。越来越多的第三方服务开始推荐甚至强制使用HTTPS连接，如微信登录、微信支付、短信验证码、地图API等。在WWDC上宣布，该公司希望官方应用商店中的所有iOS应用都使用安全的HTTPS链接与服务器通信。那为什么越来越多的HTTPs逐渐变成HTTPS呢？HTTP协议（HypertextTransferProtocol）是客户端浏览器或其他程序与Web服务器之间的应用层通信协议；HTTPS协议可以理解为HTTP+SSL/TLS，即在HTTP的基础上增加了SSL层。HTTPS的安全基础是SSL，所以加密的详细内容需要SSL来实现安全的HTTP数据传输。http和https的区别如下图所示：HTTPwithoutSSL/TLSCommunication是未加密的通信。所有信息均以明文形式传播，带来三大风险。窃听风险（easdropping）：第三方可以获悉通信内容。篡改风险（tampering）：第三方可以修改通讯内容。假装：第三方可能假装成其他人参与通信。SSL/TLS协议就是为了解决这三大风险而设计的，希望做到：所有信息加密传输，第三方无法窃听。有了验证机制，一旦被篡改，通信双方都会立即发现。配备身份证书，防止身份冒充。因此，强烈建议为了您的系统安全，尽快切换到https。要签署请求，让我们首先看一个例子。假设用户下单后可以更改订单状态。验证，那么结果就是我们根据orderId修改这个订单的状态：如果这个时候，尝试把request中的orderId换成另外一个orderId，那么订单也会被同样的方式修改，从角度看从安全的角度来看，这是我们不希望看到的。当然我们也可以添加身份验证来判断订单是否属于当前用户；此外，我们还应对请求参数进行签名处理。签名加验是指请求发送方通过加密算法从请求参数中生成一个签名值，并将其放入请求参数中；请求接收方收到请求后，以同样的方式对请求参数进行加密，得到一个符号值。只要两个符号值相同，就说明参数没有被篡改过。签名参数sign生成的方法将所有header参数（注意所有参数）、签名本身、值为空的参数按照参数key的字母升序排序。然后按照parameter1,value1,parameter2,value2...parametern,valuen对parameters进行排序（这里的parameters和values必须是传输参数的原始值，不能处理。成"然后拼接）组成字符串，将分配给访问方的验证密钥key拼接在步骤2得到的字符串前面，在上一步得到的字符串前面加上密钥key（key这里的key是接口提供方分配给接口接入方的），然后计算md5值得到一个32位的字符串，再转换成大写得到的字符串放在请求参数中作为值例如，现在假设要传输的数据：/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn（其实最好是邮寄）拼接字符串，先去掉参数p3其值为空，保留p2=v2&p1=v1&method=cancel&pn=vn，然后将字符按照参数名升序排序得到字符串：method=cancel&p1=v1&p2=v2&pn=vn。然后拼接参数名和值，最后得到methodcancelp1v1p2v2pnvn。在上面拼接得到的字符串前面加上验证密钥key，假设是abc，得到一个新的字符串abcmethodcancelp1v1p2v2pnvn。对上面得到的字符串进行md5计算，假设得到的是abcdef，然后转为大写，得到ABCDEF的值作为sign的签名值。最终生成的url应该是这样的：/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn&sign=ABCDEF注意：在计算md5之前，请确保请求发送方和接收方使用的字符串编码一致，比如统一使用utf-8编码，如果编码方式不一致，计算出的签名将无法通过验证。签名验证过程其实就是按照上面的规则对请求url进行同样的操作，计算出参数的签名值，然后与参数中传入的签名值进行比较。如果一致则验证通过，否则验证失败。请求和响应的加解密有人可能会问，为什么我们需要重新对请求和响应进行加密和解密，因为一些第三方的抓包工具，比如Charles，可以通过一定的方式抓取https，所以我们需要加密一些敏感数据。常见的加解密方法有AES成对加密法和RSA非成对加密法。至于如何使用，可以参考https的原理。有点复杂，但可以简单分为以下几个步骤：服务器端有一对密钥，即公钥和私钥，用于非对称加密。服务器保存私钥，不能泄露。公钥可以发送给任何人。服务器将自己的公钥发送给客户端。客户端收到服务器发来的公钥后，会对公钥进行校验，验证其合法性。如果公钥有问题，HTTPS传输将无法继续。严格来说，这应该是验证服务器发送的数字证书的合法性。下面将说明客户端如何验证数字证书的合法性。如果公钥合格，客户端会生成一个随机值，这个随机值就是用于对称加密的密钥。我们称这个密钥为clientkey，即客户端密钥，这样在概念上就和服务器端的密钥很容易区分。然后使用服务器的公钥对客户端密钥进行非对称加密，使客户端密钥成为密文。至此，HTTPS中的第一个HTTP请求结束。客户端会在HTTPS中发起第二次HTTP请求，将加密后的客户端密钥发送给服务器。服务器收到客户端发送的密文后，会使用自己的私钥进行非对称解密。解密后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，使数据变成密文。服务器然后将加密后的密文发送给客户端。客户端收到服务器发送的密文，使用客户端密钥对称解密，得到服务器发送的数据。总结一下前后端的交互，如果像上面那样使用https，加解密请求并验证请求参数的签名，基本可以解决大部分问题，但是除此之外，我们还应该执行每个接口上的身份验证。确保接口只能由特定用户访问，或者数据只能由特定用户修改。
