缘由
- 接口有效性
- 接口参数没有被篡改
- 接口传递了用户标识
策略
- 除了原有参数,多传递三个参数 : token , timestamp , sign
- token 标识用户信息,具体生成策略下次讨论
- timestamp 时间戳标识请求时间,比如1分钟之前的请求可以直接返回错误
- sign 将所有的参数按照 key 升序排列,按照指定算法加密生成 sign
关于sign 的思考
- 服务端有一个 <key,value> ,比如
[ {"app":"dfkajsdfkajdkfsajdf"}, {"h5":"dsfkljsadkfjsadkfja"}, {"web":"2dfsakdfjasdkfjaskdf"}, {"xxxxx":"2323jkfdsadfadjfadjfadkf"} // 可以是提供给其他公司的公共接口 ]
- 将各端对应的 value 给各端作为秘钥,key 作为公钥传输
- 这样接口的 url 就成了 http://xxxx?city=22222&name=lisi&key=app×tamp=32323333333333333&token=sdfasdfasdfa&sign=xxxxxx
- 这样就相当于我们对于一个普通的接口,我们额外添加了 四个参数, key , token , timestamp , sign
- 这四个参数,key 肯定是参与加密生成sign 便于后端验证 ,既然key 参与加密就要参与排序 , token , timestamp 建议还是不参与加密,这样最后加上这三个参数即可,也不用参与排序
- url = http://xxx? 包括key排序后的参数列表×tamp=32323333333333333&token=sdfasdfasdfa&sign=xxxxxx
- 注意:上面说的 key 参与加密,指的是用key 对应的value 进行加密,而不是key 自己参与加密,key 的职责是告诉服务端用的是哪个加密串,而不是自己参与进去加密
- 注意:这种方法只适合于 key , value 不会被泄露的情况中,比如服务端调用服务端,对于 html 这种并不能保证一定是安全的,因为恶意用户很可能查看你的源码,查看到对应的key,value 从而自己进行加密
另一种加密方案思考
- 上面的这种方案,最主要的是key,value 一定不能泄露,是不是可以将 key , value 的生成改成动态的,每次都是加密前自己获取自己的 value , 而自己获取的这个 value 只在一次session 甚至一次 request 中有效
- 每次加密使用动态生成的这个value 进行加密
- 服务端验证参数的时候最好不只是对key 进行验证,同时也对这个value 生成时的 请求版本号,机器设备,机器IP,时间戳有效性 等进行验证