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