基于Hash摘要签名的公网URL签名验证设计方案

基于Hash摘要签名的公网URL签名验证设计与约定

为什么要对url参数签名

在特定的环境下存在A系统页面打开B系统(不是同一个公司)的需求,由于B系统中不存在用户登陆,所以必须保证A通过URL调用带给B的参数是可信且未经篡改的。比如A的用户需要打开B的页面查看待审批充值订单url https://admin.isexample.com/admin/abc?isid=10000011 由于这个url是在用户浏览器上可以修改的,为了避免用户在浏览器上将isid改为其他值(比如https://admin.isexample.com/admin/abc?isid=10000012 ),这会导致系统的用户信息泄露,为了避免这种情况产生,我们需要对url中的参数进行签名。

有哪些关注点

  1. url参数放篡改
  2. url参数仿复用、仿重放攻击(url有有效期,生成时间与访问时间间隔太久会阻止访问)
  3. 验证通过后需要重定向一次 防止用户刷新原来的页面导致一次性token再次使用而系统返回错误,还需要一个随机字符串来防止每次的提交可能相同,即除了时间戳还需要一个随机字符串nonce_str
  4. 需要统一时区(比如以0时区为标准)
  5. 私下约定的加密字符串更换成本(使用两个?)
  6. Get请求url太长是否影响、大小写是否影响
  7. 通用性,需要考虑出来当前网页url验证外,还可能在系统其他部分使用(可能被作>统一拦截)
  8. 签名认证的结果是否只对当前页面有效,其他页面是否可以跳过认证(不安全,认证应该是一次性的,每次不同系统的交互都应该重新认证鉴权,如何保证重定向时认证息的传递,页面刷新呢?)
  9. 加密时,需要先做签名再做urlencode,解密时需要先urldecode,再签名对比
  10. url传递的参数值不支持数组形式 比如 a=1&a=2&a=3 是不被支持的
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值