这样的明文接口设计是否已经满足了大多数场景下的 openapi 的安全要求

月食之后
  • 21

前提说明:面向应用的 openapi 调用(不使用 ouath 验证)

首先分配给调用方 appKey(用于身份校验)和 appSecret(用于签名)

接口基本构成 appKey,reqId,timstamp,业务参数,sign

最后的参数 sign = md5(appSecret+appKey=xxx+reqId=xxx+timestamp=xxx+username=xx+vip=xxx+appSecret) 参数是以 key 增序排列的 增加了 reqId (使用 UUID)用来防范重放攻击

说明: 我们假定 timestamp 的有效时间是 1 小时,即 now-1 <timestmap< now+1 都是有效的 这时 reqId(存储在 redis 中)我们设置有效时间是 1 小时 校验逻辑是先验证签名,再验证 timstamp 有效性,再验证 reqId 有效性。 sign 保证了传输过程中没有被篡改,timestamp+reqId 保证没有重放攻击(因为在接下来的一个小时内,重放攻击发生时,因为 reqId 已经使用过,服务会被拒绝。过了这个小时,重放攻击会因为 timstamp 失效而被拒绝服务)

后端:reqId 存放在 redis,appSecret 也存放在 redis 用来提高访问性能

后续:启用 https 可以防止明文传输被人解读

回复
阅读 2.9k
1 个回答

基本上还是满足了,而且一般也都是这样操作的。
只是感觉这个时间戳的有效时间设置的有一点点长。
然后就是,客户端的话要注意密钥的保存,要预防反编译

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏