Nemo

Nemo 关注TA

路漫漫其修远兮,吾将上下而求索。

Nemo

Nemo

关注TA

路漫漫其修远兮,吾将上下而求索。

  •  普罗旺斯
  • 负责帅就完事了
  • 写了1,496,113字

该文章投稿至Nemo社区   编程综合  板块 复制链接


APP接口安全规范约定规则小思考

发布于 2019/04/11 11:02 1,767浏览 2回复 723

728da9773912b31b92d722638b18367adbb4e1c5.jpg

举两个情景栗子:

app端请求短信验证码下发接口,如果服务端不做安全性校验,那么很可能会导致短信验证码接口被恶意盗刷。

app端发起登录的时候,会向服务端提交用户名/密码参数。如果有人抓到当前请求的数据包,那么当前登录用户的用户名和密码也就泄露了。


第一个情景:

需要校验请求是由自己的app发起的请求。

考虑需要在每个请求中加入校验密钥,这个密钥的规则需要跟服务端约定。这里考虑使用RSA非对称加密,app端保存公钥对校验密钥进行加密,服务端则保存私钥对这个校验密钥进行解密。如果后端对校验密钥解密成功,则认为请求合法,是由自己的app发起的。


第二个情景:

需要对请求参数进行加密。服务端在接收到请求的时候,首先对参数进行解密。

这里考虑使用AES对称加密方式对参数进行加解密。为提高安全性,这里使用的加密密钥由app端随机生成。app使用随机生成的加密密钥对请求参数进行加密,并把这个加密密钥放到请求的某处,如请求头中。服务端在收到请求的时候,首先拿到加密密钥,然后使用加密密钥对参数进行解密。

这里有一个问题,就是加密密钥是明文的。所以需要对解密密钥也做一些处理。


结合以上两个情景,情景2解决方案中的解密密钥其实可以使用情景1中的校验密钥代替。

基本接口安全校验流程整理如下:

1、客户端产生随机【加密密钥】。

2、客户端使用【加密密钥】对请求参数进行【AES加密】。

3、客户端对【随机密钥】使用【RSA公钥】进行加密。

4、客户端将加密后的【随机密钥】放在【请求头】中,对服务端发起请求。

5、服务端接收到请求。

6、服务端对接收到的请求头中的【加密密钥】使用【RSA私钥】解密得到参数【加密密钥】。

7、服务端使用得到的参数【加密密钥】对请求参数进行【AES解密】。

本文标签
 {{tag}}
点了个评