审查 Django 代码中的访问控制与 IDOR…

在审查 Django/DRF 视图、ORM 查询或任何处理用户授权的 Python 代码时，用调查式方法发现 IDOR 和访问控制缺陷。

适用场景

解决思路

1. 先理解当前代码库的授权模型，不要直接套用预定义的漏洞模式：查找权限检查实现位置（装饰器如 @login_required、@permission_required、自定义装饰器；中间件如 TenantMiddleware、AuthorizationMiddleware；基类如 BaseAPIView、TenantScopedViewSet；DRF permission_classes；自定义 mixin 如 OwnershipMixin、TenantMixin）
2. 查明查询如何被限定范围：自定义 manager（TenantManager、UserScopedManager）、get_queryset() 重写、设置查询上下文的中间件
3. 确定所有权模型：单用户所有权（document.owner_id）、组织/租户所有权（document.organization_id）、层级结构（org -> team -> user -> resource）、上下文内基于角色（org admin vs member）
4. 用 grep 调查命令辅助理解：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
5. 在理解授权模型之前不要继续下一步
6. 映射攻击面：识别哪些模型包含用户数据、哪些有所有权字段（owner_id、user_id、organization_id）、哪些通过 URL 或请求体中的 ID 被访问
7. 对每个资源映射暴露的操作：列表端点返回什么数据、详情/检索端点如何获取对象、创建端点由谁设置 owner、更新端点能否修改他人数据、删除端点能否删除他人数据、自定义 action 访问什么
8. 对每个处理用户数据的端点追问核心问题：如果我是用户 A 且知道用户 B 资源的 ID，我能访问它吗
9. 追踪代码回答核心问题：资源 ID 从哪里进入系统（URL 路径 /api/documents/{id}/、查询参数 ?document_id=123、请求体 {"document_id": 123}）；该 ID 在哪里被用于获取数据（找到 ORM 查询或数据库调用）；在输入与数据访问之间有哪些检查（查询是否限定到当前用户、是否有显式所有权检查、是否有对象级权限检查、基类或 mixin 是否强制访问控制）；如果找不到检查，是否遗漏了父类、中间件、manager、URL 级装饰器
10. 追问列表端点：查询是否过滤到用户数据，还是返回全部
11. 追问创建端点：owner 由服务端设置还是由请求设置
12. 追问批量操作：是否限定到用户数据
13. 追问关联资源：如果能访问一个 document，能否访问它的 comments，即使 document 属于他人
14. 追问租户/组织资源：Org A 的用户能否通过修改 URL 中的 org_id 访问 Org B 的数据
15. 选取一个具体端点完整追踪：找到处理 URL 的视图、检查它继承自什么、检查 permission_classes、检查 get_queryset()、检查是否实现 has_object_permission()、检查 retrieve() 方法、得出结论
16. 追踪时关注潜在缺口指标（需进一步调查，不要自动标记）：get_queryset() 返回 .all() 或未按用户过滤、直接 Model.objects.get(pk=pk) 且查询中无所有权、敏感操作的 ID 来自请求体、权限类只检查认证不检查所有权、没有 has_object_permission() 且 queryset 未限定范围
17. 追踪时识别可能安全的模式（但仍需验证实现）：get_queryset() 按 request.user 或用户组织过滤、自定义权限类实现 has_object_permission()、基类强制限定范围、manager 自动过滤
18. 只报告通过调查确认的问题，使用置信度分级：HIGH 表示已追踪流程并确认无检查，附证据报告；MEDIUM 表示检查可能存在但无法确认，标记待人工验证；LOW 表示理论性且很可能已缓解，不报告
19. 建议的修复必须强制访问控制而非仅文档说明：坏修复是添加注释说“调用方必须验证权限”；好修复是添加实际验证权限的代码，在继续前验证用户有权限、未授权时抛出异常或返回错误、使未授权访问不可能而非仅被劝阻
20. 如果无法确定正确的强制机制，就说明这一点，但绝不要建议用文档作为修复
21. 按指定格式报告：包含授权模型简述、发现（ID 编号、标题、严重性、位置、置信度、核心问题、调查步骤、证据代码片段、影响、强制授权的修复代码）、待人工验证项、未审查区域
22. 参考常见 Django 授权模式（作为可能发现，而非匹配清单）：查询限定（Document.objects.filter(owner=request.user)、Document.objects.filter(organization=request.user.organization)、Document.objects.for_user(request.user) 需调查其行为）；权限强制（permission_classes = [IsAuthenticated, IsOwner]、自定义 has_object_permission 返回 obj.owner == request.user、@permission_required('app.view_document')、手动检查 if document.owner != request.user: raise PermissionDenied()）；所有权赋值（服务端安全方式 perform_create 中 serializer.save(owner=self.request.user)，来自请求的方式 serializer.save(**request.data) 需调查 request.data 是否包含 owner）
23. 使用调查清单引导审查（非通过/失败清单）：理解代码库通常如何实现授权、识别所有权模型、映射处理用户数据的关键端点、对每个敏感端点追踪流程并追问 ID 来源/数据获取位置/输入与数据访问之间的检查、通过检查父类和中间件验证发现、只报告通过调查确认的问题

适用边界 · 注意事项

• 不要扫描预定义的易受攻击模式，而应理解当前代码库的授权实现方式
• 在理解授权模型之前不要继续调查
• 不要报告未通过调查确认的问题，LOW 置信度问题不应报告