前后端交互如何保证数据安全?

前言

前后端交互如何保证数据安全?

web与后端,andorid与后端,ios与后端,像这种类型的交互其实就属于典型的前端与后端进行交互。在与B端用户进行交互的过程中,我们通常忽略了其安全性(甚至从未考虑安全性)。比如,请求和响应数据的明文传输,对接口并没有做严格的身份校验。如果我们还是按照这种思路去做C端用户的交互,那么等待着必将是血淋淋的教训。接下来,我带领大家如何在与C端用户安全的进行交互。

保证安全性的几种方式

前后端安全性的交互,大致可以分成如下几类:

  • 通信请求使用https
  • 对请求参数进行签名,防止数据被踹改
  • 对请求参数以及响应进行加密解密处理
  • 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方式发送)

  • 拼接字符串,首先去除值是空的参数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按照上述的规则进行同样的操作,计算得到参数的签名值,然后和参数中传递的sign值进行对比,如果一致则校验通过,否则校验不通过。

对请求和响应进行加解密

可能有人会问,都使用了https了,为什么还要对请求和响应再做一次加解密,因为有些第三方抓包工具,例如Charles 通过某些手段是可以抓取https的明文的,因此对一些敏感数据,我们需要进行加密处理,常见的加解密方式有AES 对成加密方式和RSA非对成方式,至于如何运用,可以参考https的原理,有点复杂,不过可以简单分成如下几步:

前后端交互如何保证数据安全?前后端交互如何保证数据安全?

  • 服务器端有一个密钥对,即公钥和私钥,是用来进行非对称加密使用的,服务器端保存着私钥,不能将其泄露,公钥可以发送给任何人。
  • 服务器将自己的公钥发送给客户端。
  • 客户端收到服务器端的公钥之后,会对公钥进行检查,验证其合法性,如果发现发现公钥有问题,那么HTTPS传输就无法继续。严格的说,这里应该是验证服务器发送的数字证书的合法性,关于客户端如何验证数字证书的合法性,下文会进行说明。如果公钥合格,那么客户端会生成一个随机值,这个随机值就是用于进行对称加密的密钥,我们将该密钥称之为client key,即客户端密钥,这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密,这样客户端密钥就变成密文了,至此,HTTPS中的第一次HTTP请求结束。
  • 客户端会发起HTTPS中的第二个HTTP请求,将加密之后的客户端密钥发送给服务器。
  • 服务器接收到客户端发来的密文之后,会用自己的私钥对其进行非对称解密,解密之后的明文就是客户端密钥,然后用客户端密钥对数据进行对称加密,这样数据就变成了密文。
  • 然后服务器将加密后的密文发送给客户端。
  • 客户端收到服务器发送来的密文,用客户端密钥对其进行对称解密,得到服务器发送的数据。

相关推荐