接口合法性验证思路

349 篇文章 3 订阅
126 篇文章 11 订阅

在对接API接口时,接口地址和参数结构都很容易被黑客抓包,从而模拟发送请求。

考虑到安全性,防止别人冒名调用,要对接口请求进行合法性验证。

基本原理如下

双方约定

APPID:参与签名和网络传输

APPSecretKey:约定秘钥,保存在双发服务器,只参与签名,不参与网络传输

签名方法

调用API时,需要将所有参数名称以及参数值加入签名,
即:系统级参数(除去SIGN)名称、系统级参数值、应用级参数名称、应用级参数值全部加入签名。

签名参数排序

签名时,根据参数名称,将除签名(sign)外所有请求参数按照字母先后顺序排序: key + value .... key + value 。
注:
1、排序若首字母相同,则对第二个字母进行排序,以此类推。
2、value无需编码。
3、对于非必选参数,如果没有value值,也参与签名。(说明:非必选参数没有value值时,将参数名放到字符串中,即参数名要参加签名)
例如:将“foo=1,bar=2,baz=三”排序为“bar=2,baz=三,foo=1”参数名和参数值链接后,得到拼装字符串bar2baz三foo1。

签名算法

将分配的得到的密钥(SecretKey)接到参数字符串尾部进行md5加密(UTF8编码),再转化成大写,
格式是:md5(key1value1key2value2...Secret)。

双方根据本次请求的参数采用相同的排序生成字符串,并用相同加密算法(一般MD5,也可以用多次加密处理),最后得到的消息摘要sign肯定是一样的,依次判断请求的合法性。

服务端在处理的时候要注意多次请求避免重复处理的情况,这时可以通过三方业务唯一标识ID去区分处理,接口响应要保持幂等性(在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。)。

 

当然上面的加密方式消息体依然是明文传输的,如果有重要信息,还是有泄露信息的可能性存在。

更高级的方法是参考HTTS的原理,通过公钥、私钥进行消息体的加密处理。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值