上一篇【一文理解权限类漏洞产生的原因之未授权篇】有讲过未授权漏洞产生的原因，但是在我实际的挖洞过程中，其实遇见很少，我有印象的好像只有几个非核心站点的中危。
但是对于另一类权限漏洞，功能及数据权限相关的漏洞就不一样了，我挖的逻辑漏洞中，大部分来源于它们，从中危到严重，危害等级没有上限。
我只能说，即使是一个资深开发人员，也有可能在这部分功能设计上存在疏忽。
本文主要从开发的角度讲一下对应的功能权限功能是如何实现的，以及我们可以怎样的去发现这类漏洞。
0x01
开始之前，我先从开发的角度简单地介绍一下一个系统的权限设计是怎么做的：一般会分为接口/功能权限和数据权限这两部分。
功能权限一般是用于描述某个用户允许访问某些功能，现在大部分系统都是使用RBAC（Role-Based Access Control）的权限模型，也就是基于角色的访问控制。这个我们应该比较熟悉，比如一个用户可能会属于普通用户角色、管理员角色等，不同的角色允许访问不同的功能。
而数据权限则用于描述某个用户允许访问哪些数据，这个应该更好理解，比如我创建了一个收货地址，那应该只有我可以查询到，其它人是看不到这个信息的。
0x02
为了方便理解，我用一个业务场景作为栗子吧。比如我们常见的订单功能，先从功能上来区分的话，可能会包含以下功能点：
-
查询订单
-
创建订单
-
删除订单
-
修改订单
假设管理员角色有所有的功能权限和数据权限，而普通用户的功能权限只有查询、创建和删除，并且只允许操作自己的订单。
实现
那么基于RBAC的权限模型，功能权限应该是下面这样的：
很简单不是吗？而且实现很非常容易，当用户登录时，拿到它的角色，判断是否有当前请求的接口的权限就行了：
def modify_order(order_info):
# 获取当前登录用户
user_info = get_current_user()
role = user_info.role
# 根据用户角色获取允许访问的资源
resources = get_resource_by_role(role.id)
# 当前访问的路径在不在资源范围内
if current_path() not in resources:
return 'no permission'
# 继续执行
do_next()很简单的逻辑，而且很通用，只需要将这段代码放在拦截器里面，那么在用户访问每个接口之前，都会进行这个判断，那么对于攻击者来说，普通用户想要越权访问管理员的功能就比较困难了。
那为什么还会存在越权访问的情况呢？
大部分来源于配置错误，像这种资源、角色映射关系的配置，一般都是有一个管理后台进行配置的，可能某次新增接口，忘记配置了，或者配置错误，那自然对应的接口就存在越权漏洞了。
为什么说大部分？因为真的有些网站实现不用框架，也不用拦截器，每个接口都写一遍的，那写错的概率就太高了。
漏洞发现
那我们应该怎么快速地去找这类漏洞？这里分享一下我的方法（仅仅是我自己的测试方式，不代表最好！）
一般这种漏洞在存在多种角色的管理后台，我一般会按以下流程操作：
-
建一个普通用户A，一个管理员用户B。
-
找到对应的鉴权方式，比如是使用cookie或者是某些请求头。
-
开启bp插件，功能是替换指定的请求头，并重放我的所有请求。
-
配置鉴权相关的请求头，将他们全部替换为普通用户A的。
-
使用管理员用户B点击所有仅允许管理员访问的功能。
-
查看重放接口，如果某个重放的请求成功了，那就证明此接口存在越权，理论上所有重放的请求都应该失败，因为重放时是使用普通用户A的鉴权token。
这里的BP插件是我自己写的，其实手动也可以，就是麻烦了一点。如果有兴趣的师傅们也可以去github上搜索，我看上面也有挺多插件是可以实现这个操作的。
0x03
最后，本来想功能和数据权限一篇写完的，但是我着实高估了我的耐心，加上工作比较忙，周末回家又只想躺平，所以关于数据权限篇就只能放在下次啦。如果感觉有点用就点个赞赞咯。
欢迎关注我的公众号“混入安全圈的程序猿”，更多原创文章第一时间推送!
标签：功能,解析,访问,接口,漏洞,普通用户,权限 From： https://blog.csdn.net/ooooooih/article/details/140353270