挖逻辑漏洞不懂数据权限怎么赚大钱？

从开发的角度看权限漏洞的最后一篇了，也就是数据权限篇。
0x00

相比于之前的未授权《一文明白权限类漏洞产生的原因之未授权篇》与功能权限《权限类漏洞剖析——功能权限篇》，数据权限实现起来就贫苦了，也是最轻易出错的，因为数据权限的通用实现很复杂，它的场景太多了。
   详细那里复杂我就不细说了，要否则几篇文章都写不完，反正就是它很难实现像功能权限那样的简单通用处理逻辑，以是很多开发是直接在接口内里去判断的，然而，做得越多，错得越多。
  实现

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

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

复制代码

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

1. #略过了功能权限校验
2. def order_detail(order_id):
3.     order_info = get_orders_by_id(order_id)
5.     user_info = get_current_user()
6.     # 这里要判断订单的用户ID是否和当前用户ID匹配
7.     if order_info.user_id != user_info.id:
8.         return 'no permission'
9.     return order_info

复制代码

几乎 90% 的数据越权漏洞，都是因为在实现的时候没有背面那一步操作，也就是判断数据的用户归属信息。为什么他这么轻易出现？以我的经验来看，重要大概是：
1、开发没有安全思维，觉得既然列表只返回当前用户的订单了，那在查询详情的时候，肯定是列表中的数据，就没有必要再判断了。即只思量正常场景，没有思量异常场景。
2、疏忽了，这太常见了。因为像涉及到这种根据ID举行操作的接口，都需要举行对应的判断，查询判断了，删除呢？更新呢？如果没有对数据权限举行充分的计划，那就肯定会出现问题。
漏洞发现

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

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

   同样的，这里的BP插件是我自己写的。你也可以去github上搜索类似的插件，挺多插件是可以实现这个操作的。
  0x01

虽然看起来好像挺简单的样子，但是不开打趣的说，我80%以上的高危漏洞泉源于它。我碰到的只要是这类越权，最低中危，最高严重。而且一但遇见了自增ID之类的可遍历数据权限越权，那几乎都是4位数以上（除了某些SRC）。以是了解一下它的产生原因及实现照旧有必要的，你知道它怎么实现的，才知道怎样更好的去挖掘。

---

欢迎关注我的公众号“混入安全圈的步调猿”，更多原创文章第一时间推送!

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。