目前token存在浏览器localstorage里面,当我把别人的token拷贝到自己电脑上时,可以获取到他的所有权限,后台如何才能防止这种情况呢?
添加多因素验证,比如除了token之外,再加浏览器类型,系统信息,ip地址 等。
或者,有些网站有N个cookie,然后可能使用了一些奇怪的cookie 字段来作为验证信息。
另外,cookie中(localStroage中也同理),有些字段的值是不变的,有些都是动态更新的,后端可以判断一下,
如果那些本该变的字段没有变,说明这个请求有问题;
如果固定的字段值都变了,那就不用多说了。
当然,这些方法也只是增加伪造访问的难度,并不可能完全限制。
毕竟,别人可能猜到你的验证方式,而验证信息又在客户端。
3 回答1.3k 阅读✓ 已解决
2 回答1.5k 阅读✓ 已解决
4 回答660 阅读✓ 已解决
1 回答1k 阅读✓ 已解决
1 回答1.3k 阅读✓ 已解决
2 回答989 阅读✓ 已解决
1 回答1.2k 阅读✓ 已解决
这种问题,只要是基于浏览器来做的,就没有完美解。
首先你需要考虑的是,你的数据是不是如此敏感?
如果是,那么有两个案例可以参考:
上述两个案例,第一种的安全系数最高,但使用门槛也是最高。
第二种相对简单一些,但有两个致命缺陷:1 是同一子网下的设备对外是共用一个公网 IP 的,单从 IP 并不能完全区分出设备是否一致;2 是这种方式只适用于公网 IP 不会频繁变化的固定设备(比如公司电脑),如果你的接口是提供给移动端的,手机的公网 IP 可是会因接入基站不同而频繁变化的,这种情况下还用 IP 来区分,体验是十分糟糕的(想象一下坐一站公交就得重新登录一次的场景吧)。
如果你的数据没那么敏感,但又有一些关键操作需要安全系数更高的验证手段,那么可以考虑二次密码或双因子验证机制。
比如很多支付类 App,其 Token 只能用于访问一些基础接口,一旦需要敏感操作(比如提现、转账),此时需要输入二次密码进行验证。这种设计可以尽可能降低 Token 泄漏的风险。
还有一些安全策略是从用户行为特征分析去入手。比如携带同一个 Token 的请求(假设以 Token 来标定用户),前一分钟还在河北省内,一分钟后的请求却来自广东了,这种情况大概率是有问题的。
但这种手段已经脱离了开发本身,而接近是更上游的流量管控问题了,实现起来也比较复杂,需要大数据集来训练。往往是支付宝、微信支付这类业务场景下采用;或是大众点评、知乎这类有强烈反爬虫需求的。
如果你的数据完全没有什么敏感性可言……