前后端交互如何保证安全性? |
您所在的位置:网站首页 › 前后端交互的原理 › 前后端交互如何保证安全性? |
前言 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,对请求加解密以及对请求参数进行验签,基本上能解决大部分问题,但除此之外我们还应该做到对每个接口进行身份校验,确保该接口只能由特定的用户访问,或者该笔数据只能由特定的用户去进行修改。 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |