freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

如何发现并处置越权漏洞? | FreeBuf甲方群话题讨论
2022-06-22 16:52:16

越权访问是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个工作日)-邮件通知-加入会员俱乐部

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

本文作者:, 转载请注明来自FreeBuf.COM

# events
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
评论 按热度排序

登录/注册后在FreeBuf发布内容哦

相关推荐
\
  • 0 文章数
  • 0 评论数
  • 0 关注者
文章目录
登录 / 注册后在FreeBuf发布内容哦