从开发的角度看权限漏洞的最后一篇了，也就是数据权限篇，虽然之前的都没什么人看，但想了想还是花时间写完了，也算有始有终吧。

0x00

相比于之前的未授权《》与功能权限《》，数据权限实现起来就麻烦了，也是最容易出错的，因为数据权限的通用实现很复杂，它的场景太多了。

实现

还是以之前的订单功能为例，如果我需要查询订单，那我肯定只能查询自己的，那意味着，我保存的订单信息里面，最少要有订单创建人这个属性，那实现一个查询订单列表可能是这样的：

#略过了功能权限校验
deforder_list():
# 获取当前登录用户
    user_info = get_current_user()
# 根据当前用户查询所有订单信息
return get_orders_by_user(user_info.id)

好像也很简单哦？实际上也是，几乎不太可能出错，因为错误太明显了，就算开发实现错了，测试阶段也会被发现，不可能发布到线上的。我们实际在挖洞的时候，这种列表也几乎没什么操作的空间，最多看看是不是返回的数据是不是包含敏感信息了。

那如果是查询订单详情呢？可能会这样实现：

#略过了功能权限校验
deforder_detail(order_id):
    order_info = get_orders_by_id(order_id)

    user_info = get_current_user()
# 这里要判断订单的用户ID是否和当前用户ID匹配
if order_info.user_id != user_info.id:
return'no permission'
return order_info

几乎 90% 的数据越权漏洞，都是因为在实现的时候没有后面那一步操作，也就是判断数据的用户归属信息。为什么他这么容易出现？以我的经验来看，主要可能是：

1、开发没有安全思维，觉得既然列表只返回当前用户的订单了，那在查询详情的时候，肯定是列表中的数据，就没有必要再判断了。即只考虑正常场景，没有考虑异常场景。

2、疏忽了，这太常见了。因为像涉及到这种根据ID进行操作的接口，都需要进行对应的判断，查询判断了，删除呢？更新呢？如果没有对数据权限进行充分的设计，那就一定会出现问题。

漏洞发现

那像这种漏洞又如何去找呢？一个一个去找当然没有问题，看到参数中带有ID的就试一试改ID，但是怎么说呢，我更喜欢自动化，同样可以使用和测试功能权限一样的方法：

1. 建两个普通用户A和B。
2. 找到对应的鉴权方式，比如是使用cookie或者是某些请求头。
3. 开启bp插件，功能是替换指定的请求头，并重放我的所有请求。
4. 配置鉴权相关的请求头，将他们全部替换为用户B的。
5. 使用用户A登录并点一遍所有功能。
6. 过滤所有接口参数中带有id字样的重放请求，看是否有成功返回数据的，因为理论上应该全部失败，因为重放的接口是使用B的鉴权参数访问A的数据。如果有成功，则认为有越权的可能。