---

name: django-access-review description: django-access-review risk: unknown source: community

---

name: django-access-review description: Django访问控制和IDOR安全审查。用于审查Django视图、DRF视图集、ORM查询或任何处理用户授权的Python/Django代码。触发关键词："IDOR"、"访问控制"、"授权"、"Django权限"、"对象权限"、"租户... --- LICENSE

<!-- 参考材料基于OWASP Cheat Sheet Series (CC BY-SA 4.0) https://cheatsheetseries.owasp.org/ -->

Django访问控制与IDOR审查

通过调查代码库如何回答一个问题来发现访问控制漏洞：

用户A能否访问、修改或删除用户B的数据？

何时使用

• 你需要审查Django或DRF代码中的访问控制缺陷、IDOR风险或对象级授权失败。
• 任务涉及确认一个用户是否可以访问、修改或删除另一个用户的数据。
• 你想要一个调查驱动的授权审查，而不是通用的模式匹配。

理念：调查优于模式匹配

不要扫描预定义的漏洞模式。相反：

1. 理解此代码库中授权的工作方式
2. 提出问题关于特定的数据流
3. 追踪代码找到访问检查发生的位置（或是否发生）
4. 报告仅通过调查确认的内容

每个代码库实现授权的方式不同。你的工作是理解这个特定的实现，然后找到缺陷。

---

阶段1：理解授权模型

在寻找漏洞之前，回答关于代码库的这些问题：

授权是如何执行的？

研究代码库以找到：

□ 权限检查在哪里实现？
  - 装饰器？(@login_required, @permission_required, 自定义？)
  - 中间件？(TenantMiddleware, AuthorizationMiddleware？)
  - 基类？(BaseAPIView, TenantScopedViewSet？)
  - 权限类？(DRF permission_classes？)
  - 自定义混入？(OwnershipMixin, TenantMixin？)

□ 查询是如何限定范围的？
  - 自定义管理器？(TenantManager, UserScopedManager？)
  - get_queryset() 重写？
  - 设置查询上下文的中间件？

□ 所有权模型是什么？
  - 单用户所有权？(document.owner_id)
  - 组织/租户所有权？(document.organization_id)
  - 层级式？(组织 -> 团队 -> 用户 -> 资源)
  - 上下文内基于角色？(组织管理员 vs 成员)

调查命令

# 查找认证通常如何完成
grep -rn "permission_classes\|@login_required\|@permission_required" --include="*.py" | head -20

# 查找视图继承的基类
grep -rn "class Base.*View\|class.*Mixin.*:" --include="*.py" | head -20

# 查找自定义管理器
grep -rn "class.*Manager\|def get_queryset" --include="*.py" | head -20

# 查找模型上的所有权字段
grep -rn "owner\|user_id\|organization\|tenant" --include="models.py" | head -30

在理解授权模型之前不要继续。

---

阶段2：映射攻击面

识别处理用户特定数据的端点：

存在哪些资源？

□ 哪些模型包含用户数据？
□ 哪些具有所有权字段（owner_id, user_id, organization_id）？
□ 哪些通过URL或请求体中的ID访问？

暴露了哪些操作？

对于每个资源，映射：

• 列表端点 - 返回什么数据？
• 详情/检索端点 - 对象是如何获取的？
• 创建端点 - 谁设置所有者？
• 更新端点 - 用户能否修改他人的数据？
• 删除端点 - 用户能否删除他人的数据？
• 自定义操作 - 它们访问什么？

---

阶段3：提出问题并调查

对于每个处理用户数据的端点，问：

核心问题

"如果我是用户A并且知道用户B资源的ID，我能访问它吗？"

追踪代码来回答这个问题：

1. 资源ID从哪里进入系统？
   - URL路径: /api/documents/{id}/
   - 查询参数: ?document_id=123
   - 请求体: {"document_id": 123}

2. 该ID在哪里用于获取数据？
   - 找到ORM查询或数据库调用

3. 在(1)和(2)之间，存在什么检查？
   - 查询是否限定到当前用户？
   - 是否有显式的所有权检查？
   - 是否有对象的权限检查？
   - 基类或混入是否强制执行访问？

4. 如果找不到检查，是否有遗漏的？
   - 检查父类
   - 检查中间件
   - 检查管理器
   - 检查URL级别的装饰器

后续问题

□ 对于列表端点：查询是否过滤到用户的数据，还是返回所有内容？

□ 对于创建端点：谁设置所有者 - 服务器还是请求？

□ 对于批量操作：它们是否限定到用户的数据？

□ 对于关联资源：如果我可以访问一个文档，我能访问它的评论吗？
  如果文档属于其他人呢？

□ 对于租户/组织资源：组织A中的用户能否通过更改URL中的
  org_id来访问组织B的数据？

---