yhy0 Auth Bypass Vulnerability Patterns (CWE-285/287/863)
当审计 Python 代码中涉及认证流程、权限检查、访问控制逻辑时加载此 Skill。
Detection Strategy
通用检测模型，适用于此类漏洞的所有变体。
Sources（攻击入口）：
- HTTP 请求参数/头部（用户名、密码、token）
- SAML/OAuth/OpenID 响应中的身份断言
- API Key / Session Cookie
- 消息总线事件（如 Salt minion 事件）
- SSO IdP 返回的用户标识
Sinks（受保护资源/操作）：
- 管理面板 API 端点（用户管理、系统配置）
- XML-RPC / REST API 的特权操作
- 系统参数/配置信息读取接口
- 身份关联操作（account linking, identity binding）
- 事件总线上的任务发布/执行
Sanitization（认证/授权屏障）：
- 认证装饰器（
@login_required,@permission_required） - Django REST Framework
permission_classes（IsAuthenticated,IsAdminUser） - 共享密钥校验（shared secret comparison）
- SAML 签名验证 + 身份确认逻辑
- OpenID Provider URL 白名单校验
- RBAC 角色/权限检查中间件
- 事件标签黑名单/白名单过滤
- CSRF Token 校验（尤其在 SSO/OAuth 身份关联场景中防止跨站身份绑定）
检测路径：
搜索认证/授权模式的 Grep 模式：
# DRF 视图缺少 permission_classes
grep -rn "class.*APIView\|class.*ViewSet" --include="*.py"
grep -rn "permission_classes" --include="*.py"
# 异常处理中的 fallback
grep -rn "except.*return" --include="*.py"
# 认证装饰器
grep -rn "login_required\|permission_required" --include="*.py"
# SSO/OAuth 相关
grep -rn "SAML\|OAuth\|OpenID\|IdP" --include="*.py"
# 事件总线
grep -rn "event.*handler\|on_event\|publish(" --include="*.py"
- 搜索受保护的资源/操作端点（API view、RPC method、event handler）
- 检查是否有认证/授权屏障保护（装饰器、permission_classes、手动校验）
- 验证屏障是否可被绕过：
- 异常处理中的 fallback 值是否可预测？
- 条件判断逻辑是否存在运算符优先级/短路求值问题？
- 视图类是否遗漏了 permission_classes 声明？
- 用户输入是否直接作为身份提供者 URL 使用？
- 配置优先级变更是否导致限制条件失效？
- 路由权限映射是否过于宽泛？
- 事件/消息总线是否缺少标签/类型过滤？
- 若无屏障或屏障可被绕过 -> 标记为候选漏洞
Detection Checklist
- 异常处理返回值审计 (CWE-287)：
except块中是否返回可预测的 fallback 值（如-1,None,""），且该值可被攻击者用于绕过后续校验？ - 条件表达式优先级审计 (CWE-287)：
if A and B or C类型的复合条件是否因缺少括号导致逻辑与预期不符？（and优先级高于or） - DRF 视图 permission_classes 审计 (CWE-285)：所有
APIView/ViewSet是否显式声明了permission_classes？未声明时 DRF 默认使用DEFAULT_PERMISSION_CLASSES，可能为AllowAny。 - SSO/OAuth identity binding 审计 (CWE-287)：身份关联操作是否验证了「当前登录用户 == 待关联用户」？
is_authenticated不等于「是本人」。 - OpenID/OAuth Provider URL 白名单审计 (CWE-863)：身份提供者 URL 是否来自预配置白名单？用户是否能直接提交任意 IdP URL？
- 路由权限映射审计 (CWE-285)：API 路由到角色的映射是否使用前缀匹配（如
/user匹配/user/admin）？低权限角色的路由列表是否包含高权限端点？ - 配置优先级审计 (CWE-863)：当多个配置项共同控制访问时（如
allow_all+identity_provider），升级框架版本后优先级是否发生变化？ - 事件总线标签过滤审计 (CWE-285)：消息/事件处理器是否校验事件标签/类型？已认证的低权限实体是否能注入高权限事件？
False Positive Exclusion Guide
以下模式不是此类漏洞：
- 异常处理返回 fallback 但后续有二次校验 -- 如果 fallback 值在被使用前经过了额外的有效性检查（如
if secret != -1 and secret == input），则不是漏洞 - 视图未设 permission_classes 但项目级 DEFAULT_PERMISSION_CLASSES 已配置为 IsAuthenticated -- 需要检查 settings.py 中的 REST_FRAMEWORK 配置
- 内部 API 仅绑定 localhost -- 如果端点仅监听 127.0.0.1 且无代理转发，风险较低
- 测试/开发环境的认证豁免 -- 如
DEBUG=True时跳过认证，需确认生产环境不受影响
以下模式需要深入检查：
except Exception: return default_value-- 宽泛异常捕获 + 返回默认值是高危模式，必须追踪 default_value 的使用方式if user.is_authenticated-- 仅检查认证状态而不验证身份（是否是正确的用户），在 account linking 场景中可能导致冒充permission_classes = []或permission_classes = [AllowAny]-- 显式移除权限检查，需确认是否为公开接口- 框架版本升级后的行为变更 --
allow_all等配置项的语义可能因框架升级而改变 - 前缀路由匹配 --
/user路由权限是否意外覆盖了/user/admin等子路径
Real-World Cases
详见 references/cases.md（7 个真实案例，需要时加载）。