token 被盗引发的数据安全问题

[liuzhen]

最近在过等保，测试人员拿 admin 用户的 token 替换到了 guess 用户的请求头里，得出一个存在越权的结论，给的修复方案是: 对所有用户功能基于 sessionid 判断用户权限。

但我寻思 sessionid 不也存在浏览器端吗，一样可以被等保测试人员拿到放在其他用户的请求里伪装 admin 用户

[ookkxw]

最简单的方案应是做 2 个门，guest 和 admin 的钥匙只能开对应的门😄

[zliea]

@defunct9 要用 sudo ，不要 root 登录

[IvanLi127]

再加一个 token 呗，这样 guest 拿到原先的 token 直接请求，就能因为另一个 token 校验不通过而被拦截了。 如果他再说这问题，就继续加 token ，加到他测哭了就行。

[est]

要你加你就加。那么多废话干嘛。反正麻烦的是用户。加完了你在注释里写一句 XXX 傻吊 就完事了。

[clf]

设备-IP-UA 信息二次校验，同个 token 签发的时候记录前面的信息，后续请求不一致的时候就拦截，如果伪装到一致了，那就只能当作一致了呗。

或者是只记录这样的行为，做好预警，视情况主动踢下线。

[tabris17]

伞柄测试不用理它

[defunct9]

@ztechstack sudo 有啊，人非让改掉 root 名，说容易被人猜到。

[zliea]

@defunct9 禁止 root 登录，linux 系统不可能没有 root 。

[conhost]

@IvanLi127 最简单的难道不是直接用 token 对 body 做个摘要，然后把这个摘要挂在 body 上，这样简单替换 token 就没用了

[defunct9]

@ztechstack 禁止 root 登录了啊，人非让改掉。

[gps949]

讨论具体这个问题前，你先需要区分两个概念：“安全” & “合规”。
合规不一定安全。安全不一定合规。不安全不一定不合规。不合规不一定不安全。

所谓合规，就是要按照测评认证机构（的人员）的要求做，假设他们说 C 不行 Java 可以，你就得用 Java ，假设他们说 JS 不行 PHP 可以，你就得用 PHP ，就是这么个事。

[IvanLi127]

@conhost 有道理，用 token 对 body 签名。不过我感觉把摘要挂在 header 里会简单点，这样就不用关心 body 内容了，直接对 body 文本签名就好了。

[Jf35jxN3fwBXyeLh]

请求参数加签 + 绑定设备 id ，后端校验。前端上 jsvmp ，确保加签算法不会被逆向或黑盒调，设备 id 算法同理

[Mark24]

这就是古代的兵符。

只认令牌，不认人。

自己把令牌拱手让人了。怎么说。反正令牌自己没毛病。


用户应该用 HTTPS 、用自己的密码、浏览器密码 保护自己的程序不不被复制。
你为什么要允许别人复制你机器上的东西。

这里要被修改的不是程序，而是要培训使用者的安全意识。

就像存折密码，不要随便告诉他人一样的道理。

[cnbattle]

让前端把 token 放内存里 类似 vue vuex 的实现，不要本地存储

[mytsing520]

@ajaxfunction
分享一下我的想法，仅为个人意见：
关闭 WAF 测试实际上他们是在帮你测了 WAF 不可用的场景下的问题。某种意义上也算合理，毕竟鸡蛋不能放一个篮子里。
以后新出现的 XSS 的漏洞暂且不论。

[jetpy]

可以考虑使用动态 token

[itechnology]

这测试有点逗吧，guest 拿到 admin 的 token ，那这时候 guest 就充当 admin 的用户角色了。我觉得你 3 楼说的有道理：“等于是要求你把你家钥匙给张三，要求张三去开门的时候开不了”

[Lemeng]

动态的靠谱，要不人脸

[conhost]

@itechnology 这种要求也不能说逗吧，也许跟个人对安全的理念不一样呢？不然现在为什么会出现双因子认证呢？