越权访问是Web应用程序中的一种常见漏洞， 在OWASP发布的2021年十大Web应用安全风险榜单中排列第一。在攻防实战中，越权漏洞也常常是红方进行渗透的重要手段之一，不仅运用范围广，危害也较大，本次话题讨论将围绕如何防范越权漏洞，就相关问题展开讨论。

现在越权漏洞有哪些检测方法？比较好的思路是什么？

A1：

目前只知道越权漏洞需要通过人工来检测，如果公司能力有限，比较好的思路就是请经验丰富的人来测试。

A2：

越权漏洞算是逻辑漏洞里面比较容易自动化发现的了吧，我记得看过某公司的DevSecOps材料，他们通过收集Session和功能接口自动重放请求，来判断是否存在越权访问。

A3：

这种的应该算集成的DevSecOps流程内部了，一是能铺开DevSecOps的企业少，二是能铺开还要用好的团队更少。所以，从内部看待这个问题，还好。从外部发现此类逻辑漏洞的话，我是不太看好的。

A4：

我是这么看的，现在系统越来越复杂，但没有权限控制策略来指导开发人员，那么拍脑袋做的系统一定会埋雷，风险控制最好的方式我认为是角色、权限表制定好，由前端还是后台负责鉴权也明确好方案，然后开发才能取得比较好的效果。

A5：

我认为好的思路就是通过测试传参的方式进行测试，越权不管水平还是垂直都是传参到后台请求，没规范传参值导致越权，常见的参数通过修改Get、Post请求，修改Cookie、ID订单号之类的值。

A6：

有时候请求本身就是带一个加密的参数，比如加盐Hash过的UserID，其实本身也是鉴权的一部分。有不少白帽子直接用AB两个账号，把A的post请求参数弄下来让B发成功，就提了。除非能从其它接口获取A的该参数，不然有有什么用呢。你能拿到A的UserID，都等于拿到他密码或者Cookie了，直接登录什么操作不能做，还越什么权？

A7：

这个意思是A的UserID就等同于A的Cookie了吗？能保证UserID不被其他方式获取到吗？

A8：

是的，找到那也应该其实他的问题，譬如敏感信息泄露导致查看到UserID。

A9：

UserID加密只是提升了利用的难度，漏洞依然是存在的，不能回避这个问题，你可以降级评级，但不能忽略说无影响。

A10：

漏洞存在，但是不能利用或者提高利用门槛一样也算是一种解决方案。

A11：

提高利用门槛不是指标不治本吗？如果真的无法解决的话确实可以尽量提高门槛。

A12：

大部分时候还真是提高利用门槛，直接规避风险，对于线上业务来说，难度还是比较高的，除非是一些小问题。

A13：

ID用来引用对象，Cookie用来辨识身份，若是没有做好资源调用的鉴权就是算失效的访问控制，还是算存在漏洞的。

A14：

拿到加密的UserID和拿到Cookie还是不一样的吧。前端加密还是可以扒拉出来的。

A15：

确实是不一样的，Cookie应该不是永久性的，但UserID一定是不变的。

A16：

确实不一样，我就是举个例子，你不能用登录账号才能拿到的信息去越权，我也说了，如果你有其他端口或手法可以拿到这个加密后的参数，那肯定也算越权。

A17：

不过一般白帽子做这种越权测试都是这种手法，就像测试越权删除修改这类操作，越权删除修改了其他用户的数据就不太好。

Q：在用户权限之外执行业务功能，为啥不能叫越权？

A1：

你确定是用户权限之外？你拿了用户只有登录才能获取的加密后的参数去执行，我为什么认定在用户权限之外，这明明就是用这个用户的身份去执行的。

A2：

你说的加密后的参数是指这种不能遍历猜解随机生成的吗？

A3：

就是不安全的直接对象引用，毕竟ID是唯一标识符为静态的，只是说模糊处理后的利用条件难了。

A4：

加密后的参数是指对象引用的ID，还是类似用户动态的Token，如果类似这种，UserID=189035692570394624，UserID存在越权，拿到UserID怎么就跟用户身份画上等号了？

A5：

都说了要是能不登录A账号，拿到A的这个UserID，没人不算你越权，你要是说能遍历，就你这个18位随机生成数字，算你1亿用户，从0开始遍历，每遍历一亿次请求就能遍历出一个用户的UserID，开发和运维都是不存在的么？

A6：

遍历肯定不会遍历，但越权肯定还是算越权。

A7：

你要说你这个是什么手机号+XX+XX生成的，那不就是破解了加密算法。破解加密算法我们本身就是高危，那我暴破密码你收么？

A8：

爆破密码有验证码啊。

A9：

你们接口没有频率限制么？

A10：

有频率限制，我没说要跑ID出来，存在越权漏洞是说这个参数没有进行权限校验，而不是说这个参数值没法被获取到。

水平越权是不是要比垂直越权更难以判断？

A1：

垂直比水平更难测，垂直可以从操作系统内核发起，例如iOS越狱就是垂直。

A2：

Web上面的垂直越权跟操作系统是没有任何关系的，不管是垂直还是水平还是未授权 无非就是用户鉴权问题，查询信息接口传入用户ID未校验等问题，未授权也很好解决，给接口做鉴权就可以了，无非就是访问这个接口直接把Cookie或Token删掉还是可以返回数据。

A3：

说实话，我也没搞懂，垂直越权和内核有啥关系，不应该是没做鉴权和校验导致的吗？

A4：

是的，大部分都是参数没做鉴权，或者某个接口传入UserID，对UserID这个参数不可控导致的，常规就是遍历，如果UserID不可遍历，就俩账号替换。

A5：

水平越权和垂直越权，感觉不太适合对比；只能说水平越权的场景发现比较容易，垂直越权一旦发生，其实代表架构设计层面出现问题。两者的难点在于此类漏洞属于逻辑漏洞、业务漏洞。不同的人对这些流程、逻辑和业务层面的理解不同，是否为漏洞的界限并不清晰。

Q：既然作为逻辑漏洞的一种，为什么有说法称越权类漏洞很难通过工具进行自动化检测？

A1：

既然是逻辑漏洞，那么判断过程就需要评判流程逻辑是否合理、严谨，此类漏洞在功能上来说都是没有问题的，只是组合起来会发生奇妙的“化学”反应。

A2：

其实也可以实现自动化检测，比如在测试之前，测试人员把需要修改的Cookie、ID订单号拿出来，放入到自动化测试平台一样也可以测试，就是比较鸡肋。

A3：

工具自动化确实想精确检测不太行，Burp有款插件就可以自动化检测，原理也很简单，提前配置两个账号的Cookie或Token，每一次请求都会替换Cookie，重放，然后人工看Diff。

自动化检测比较麻烦的是，有些接口是大家都能用的，替换之后也能返回数据，不太好判断 不过可以通过白名单的方式来自定义有哪些接口是公共的，大家都有的，不过这种方式也是仁者见仁智者见智了。

根据以上的讨论，防范越权漏洞，对企业系统账号提出哪些具体安全要求？

A1：

1.权限最小化，非必要不赋权；

2.权限架构方面的设计一定要反复推演和验证；

3.如涉及业务流程和逻辑，一定要反复与业务团队确认效果。

A2：

1、前后端同时对用户输入信息进行校验，双重验证机制；

2、对于可控参数进行严格的检查与过滤；

3、直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理；

4、执行操作前验证操作用户身份，验证用户是否具备操作权限；

5、最小化控制用户权限。

A3：

越权漏洞用户层面无法解决，只能是产品+架构+开发解决。

1、明白非授权的能看什么、干什么；授权的能看什么、干什么；

2、现在都是RBAC+ABAC，就是角色+属性+权限=防范越权。

最终的产品设计：

Device 或 Container 的 Owner 可以设置 Tag；安全团队决定谁 Own 哪些 Tag、每个 Tag 关联了哪些 Permissions、Tags 会授权给哪些 Roles；产品团队决定哪些 Users 应该属于哪些 Roles。

——————————————————

本期精彩观点到此结束啦~此外，FreeBuf会定期开展不同的精彩话题讨论，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！

加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！