API

API 接口安全思考

API 接口加密以及接口安全验证

Posted by lijian on January 30, 2019

缘由

  • 接口有效性
  • 接口参数没有被篡改
  • 接口传递了用户标识

策略

  • 除了原有参数，多传递三个参数 ： 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&timestamp=32323333333333333&token=sdfasdfasdfa&sign=xxxxxx
  • 这样就相当于我们对于一个普通的接口，我们额外添加了 四个参数， key , token , timestamp , sign
  • 这四个参数，key 肯定是参与加密生成sign 便于后端验证 ，既然key 参与加密就要参与排序 ， token , timestamp 建议还是不参与加密，这样最后加上这三个参数即可，也不用参与排序
  • url = http://xxx? 包括key排序后的参数列表&timestamp=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，时间戳有效性 等进行验证
CATALOG