Skip to main contentauth-bypass-methodology
认证绕过完整方法论 — 基于 300+ HackerOne/Bugcrowd 真实报告提炼。覆盖未授权访问、登录逻辑缺陷、MFA 绕过、Session 管理攻击、认证降级、默认/泄露凭据、注册逻辑漏洞、API 认证缺失、Response 篡改、Race Condition 认证绕过。任何出现 login/session/token/cookie/Authorization/MFA/2FA/验证码/注册验证/受保护 API 的场景都必须使用此 skill。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/haibo3434358/ScareAISec --skill auth-bypass-methodologyيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
المهن ذات الصلةSOC
استنادا إلى تصنيف SOC المهني
| name | auth-bypass-methodology |
| description | 认证绕过完整方法论 — 基于 300+ HackerOne/Bugcrowd 真实报告提炼。覆盖未授权访问、登录逻辑缺陷、MFA 绕过、Session 管理攻击、认证降级、默认/泄露凭据、注册逻辑漏洞、API 认证缺失、Response 篡改、Race Condition 认证绕过。任何出现 login/session/token/cookie/Authorization/MFA/2FA/验证码/注册验证/受保护 API 的场景都必须使用此 skill。 |
| priority | 9 |
| vuln_types | ["认证绕过","未授权访问","MFA绕过","Session管理缺陷","认证降级","登录逻辑缺陷","账户接管"] |
| triggers | ["login","signin","auth","session","cookie","Authorization","Bearer","token","mfa","2fa","otp","captcha","register","verify","logout","refresh_token","/api/v1/","/internal/"] |
| synonyms | ["authentication bypass","auth bypass","login bypass","unauthenticated access","mfa bypass","2fa bypass","session fixation","session bypass","认证缺失","登录绕过"] |
| metadata | {"tags":"auth bypass,authentication,login bypass,mfa bypass,2fa bypass,session,认证绕过,登录绕过,双因素,多因素,OTP,验证码,session fixation,session hijack,default credentials,凭据泄露,注册漏洞,认证降级,response manipulation,race condition,account takeover,未授权访问,api key","category":"discovery","authority":"expert"} |
认证绕过完整方法论
关于本 Skill 的使用边界
本 Skill 提供的是认证绕过挖掘的通用思路与常见场景清单，不是执行脚本，更不是必须严格按顺序走完的流程。
- 如果在某个 Phase 已经获得了清晰证据（例如删 Cookie 后仍返回业务数据、或 MFA 临时 token 已可调用业务 API），不必再机械执行后续 Phase。
- 当目标的真实表现与本 Skill 描述不符（例如认证架构是自研、Session 机制不常见、MFA 流程走的不是主流模式）时，以现场观察为准，本 Skill 仅作参考。
- 如果你判断当前场景需要一个本 Skill 未覆盖的攻击路径（例如某个 SDK 的 token 交换逻辑、某个中间件的身份头传递、某个微服务间的隐式信任、某个开源组件的认证默认配置问题），请直接按你的推理执行，不要因为不在清单里就放弃。
- "最低必测自检"用于防止漏测，不是用于压制你的判断。如果某项确实不适用，标记原因即可，不要为凑数而硬测。
🤖 Agent 工具映射
| 操作 | Agent 工具 |
|---|
| 记录完整登录/注册/MFA/注销流程 | browser_* + proxy_get_traffic |
| 删除认证、空 token、随机 token、旧 token 对照 | proxy_send_request(..., drop_auth=True) |
| 重放并修改 Cookie、Authorization、Session、MFA 参数 | proxy_replay / proxy_send_request |
| 直接访问最后一步页面/API 验证跳步 | browser_goto + proxy_send_request |
| 对比认证前后、MFA 前后、注销前后响应 | proxy_diff_responses |
| 查看 Set-Cookie、重定向、权限字段和错误详情 | proxy_get_flow_detail |
| 抓取 LocalStorage/SessionStorage/JWT/MFA 页面状态 | browser_evaluate + browser_get_cookies |
| 固化认证绕过证据与后续影响补充 | checklist_mark + note_add |
| JWT/OAuth/密码重置/403 绕过等专项 | knowledge_load_skill |
执行约束：认证绕过必须证明“未经完整认证却获得受保护资源或敏感操作能力”；页面跳转不是证据，必须直接请求后端 API 做二次校验。
0. 立即执行摘要：认证绕过先测“删除/替换/降级/跳步”
看到登录、注册、MFA、验证码、Authorization、Cookie、session、token、refresh_token、/api/v1/、移动端 API、内部 API、受保护资源时，必须进入本 skill。认证绕过的第一目标不是爆破密码，而是证明 服务端是否在每条受保护路径、每个步骤、每种客户端、每个旧版本接口上都执行了认证检查。
优先顺序：
- 对所有受保护 API 做删除认证、空 token、随机 token、过期 token、低权限 token 对照。
- 登录/MFA/注册/找回流程必须尝试直接访问最后一步或业务 API，检查是否可跳步。
1. 认证响应判定状态机
| 响应现象 | 不要立刻下结论 | 下一步 |
|---|
删除认证后 200 + 业务数据 | 高危信号 | 与正常登录响应对照，确认是否受保护数据 |
删除认证后 200 + 空对象 | 可能软拒绝或数据为空 | 换对象 ID、分页、导出接口、移动端接口 |
302 到登录页 | 页面拒绝不代表 API 拒绝 | 直接请求 JSON API，看是否仍返回数据 |
401/403 | 有认证检查但可能不完整 | 方法切换、路径变体、Header 伪造、旧版本 API |
404 | 可能权限伪装 | 用高权限/合法对象确认资源存在 |
| MFA 未完成但有临时 token | 高危信号 | 用临时 token 调业务 API |
| 注销后页面跳登录 | 不足以证明失效 | 用旧 Cookie/Token 直接请求 API |
⚠️ 关键认知
认证绕过 ≠ 密码爆破。90% 的认证绕过来自逻辑缺陷，而非密码学弱点。开发者实现了认证，但在某些路径上忘了检查、检查不完整、或检查可被绕过。
- 不一致的认证执行（41%）— 主入口有认证，但旁路/内部/v1 接口没有
- 可预测/可操纵的认证状态（23%）— Session/Token/Cookie 可伪造或重用
- 多步骤流程中的逻辑跳跃（18%）— 直接请求最后一步跳过验证
- 客户端验证依赖（12%）— 前端检查但后端不检查
- 默认/弱/泄露凭据（6%）— 听起来简单但仍然是最快的入口
⛔ 安全边界（真实渗透测试必读）
- 禁止影响真实用户：账户锁定/OTP 爆破测试只对自己的测试账号执行，不要锁定真实用户
- 并发测试需谨慎：Race Condition 测试可能导致数据不一致，仅在测试环境或获得明确授权后执行
- 禁止使用窃取的凭据：发现泄露的 API Key/密码后截图报告即可，不要实际使用
- Session 测试用自己的账号：Session 固定/劫持测试仅在自己的两个测试账号间进行
- 注册测试及时清理：重复注册/Unicode 绕过等测试创建的账号要及时删除
- MFA 绕过验证即停：确认可跳过 MFA 后立即记录，不要继续操作业务功能
Phase 1: 认证机制侦察
1.1 识别认证类型
检查目标使用的认证方式（常多种并存）：
├── Session-based（Set-Cookie: PHPSESSID/JSESSIONID/connect.sid）
├── Token-based（Authorization: Bearer eyJ...）→ 转 jwt-attack-methodology
├── API Key（X-API-Key / ?api_key= / Authorization: ApiKey）
├── Basic Auth（Authorization: Basic base64(user:pass)）
├── OAuth/SSO（redirect_uri + code）→ 转 oauth-sso-attack
├── SAML（SAMLResponse）
├── mTLS/客户端证书
└── 自定义（Cookie 中的自定义字段）→ 转 cookie-analysis
1.2 认证端点枚举
必查端点（不管爬虫有没有发现）：
/login, /signin, /auth, /authenticate, /api/login, /api/auth
/register, /signup, /api/register, /api/users (POST)
/logout, /signout, /api/logout
/forgot-password, /reset-password → 转 password-reset-attack
/verify, /confirm, /activate
/api/token, /api/refresh, /oauth/token
/admin, /admin/login, /manage, /dashboard
/.well-known/openid-configuration
/api/v1/*, /api/v2/* (版本差异)
/internal/*, /debug/*, /test/*
1.3 认证流程全记录
先正常走一遍完整登录流程，用 proxy 记录每一个请求：
记录项：
1. 登录请求格式（POST body 字段名、是否加密）
2. 登录成功响应（Set-Cookie? Token? redirect?）
3. 后续请求如何携带认证（Cookie? Header?）
4. 认证失败的响应特征（状态码、错误消息、响应体差异）
5. 是否有 MFA/2FA 第二步
6. 是否有"记住我"功能
7. 是否有验证码（CAPTCHA）
Phase 2: 未授权访问（最快路径）
在测试任何绕过之前，先检查是否有端点根本就没加认证。
2.1 去除认证头直接访问
对每个已知的 API 端点：
1. 正常请求（带 Cookie/Token）→ 200
2. 去掉 Cookie/Authorization 头 → 还是 200？→ 未授权访问！
3. 用空 Token → Authorization: Bearer → 200？
4. 用无效 Token → Authorization: Bearer invalid → 200？
2.2 高概率未授权端点
| 端点模式 | 原因 | 优先级 |
|---|
/api/v1/*（旧版本） | 新版加了认证，旧版忘了 | 🔴 高 |
/internal/*, /debug/* | 内部接口假设不会被外部访问 | 🔴 高 |
/api/public/* 之外的 public 路由 | 开发者标记错误 | 🔴 高 |
/health, /status, /metrics | 运维端点信息泄露 | 🟡 中 |
/graphql（Introspection） | Schema 暴露所有 API | 🔴 高 |
/api/docs, /swagger.json | API 文档暴露 | 🟡 中 |
WebSocket ws:// | WS 连接常缺认证 | 🟡 中 |
静态资源路径（/uploads/） | 文件直接可访问 | 🟡 中 |
/api/*/export, /api/*/download | 导出接口常被遗漏 | 🔴 高 |
2.3 HTTP 方法差异
GET /api/admin/users → 401
POST /api/admin/users → 200？（不同方法不同的认证中间件）
OPTIONS /api/admin/users → 200 + 敏感 Header 泄露？
PUT /api/admin/users → 200？
Phase 3: 登录逻辑缺陷
3.1 SQL 注入登录绕过
用户名字段测试（经典但仍有效）：
admin' --
admin' OR '1'='1' --
admin'/*
' OR 1=1 --
" OR 1=1 --
admin') OR ('1'='1
发现信号：登录失败消息不同（"用户不存在" vs "密码错误"）→ 用户名枚举 + SQL 注入可能。
3.2 响应操纵（前端依赖）
抓取登录失败的响应：
POST /api/login → {"success": false, "role": "none"}
用 proxy_replay 修改响应：
{"success": true, "role": "admin"}
如果前端据此跳转 → 认证仅在前端执行
HackerOne 真实案例：多个 SPA 应用（React/Vue）在登录响应中返回 {"authenticated": true}，前端直接据此显示管理面板，后续 API 调用也不再验证。
3.3 参数操纵
正常登录：POST /login {"username":"user","password":"pass"}
测试：
1. 删除 password 字段 → {"username":"admin"}
2. 空密码 → {"username":"admin","password":""}
3. null 值 → {"username":"admin","password":null}
4. 数组 → {"username":"admin","password":[]}
5. 对象 → {"username":"admin","password":{}}
6. 布尔 → {"username":"admin","password":true}
7. 添加字段 → {"username":"admin","password":"x","admin":true}
8. 添加字段 → {"username":"admin","password":"x","verified":true}
3.4 认证降级
如果正常登录需要 MFA：
1. 找旧版 API → /api/v1/login（可能没有 MFA）
2. 找移动端 API → /mobile/api/login（可能简化认证）
3. 找第三方集成 → /integrations/auth（可能绕过 MFA）
4. Basic Auth 降级 → Authorization: Basic base64(admin:password)
5. API Key 降级 → 找泄露的 API Key 直接使用
3.5 默认凭据（仍然有效）
高频默认凭据：
admin:admin, admin:password, admin:123456, admin:admin123
root:root, root:toor, root:password
test:test, guest:guest, demo:demo
operator:operator, support:support
框架默认：
Spring Boot Actuator: /actuator（常无认证）
Tomcat Manager: tomcat:tomcat, admin:admin
Jenkins: 无初始密码或 admin:admin
Grafana: admin:admin
phpMyAdmin: root:（空）
Phase 4: MFA/2FA 绕过
4.1 直接跳过 MFA 步骤
正常流程：
Step 1: POST /login → 200 {"mfa_required": true, "temp_token": "xxx"}
Step 2: POST /mfa/verify → {"code": "123456", "temp_token": "xxx"}
Step 3: 获得完整 session
绕过测试：
1. Step 1 后直接访问 /dashboard → 如果 200 → MFA 可跳过
2. Step 1 后直接调用业务 API → 如果 200 → MFA 仅限前端
3. Step 1 的 temp_token 直接当正式 token 用 → 权限相同？
4.2 OTP 验证码绕过
1. 空验证码 → {"code": ""} 或 {"code": null}
2. 通用码 → {"code": "000000"} / {"code": "123456"}
3. 负数 → {"code": -1}
4. 超长值 → {"code": "000000000000"}
5. 响应中泄露 → 检查 Step 1 响应体/Header 是否包含 OTP
6. 无速率限制 → 6 位数字 = 100 万种，无限制可爆破
7. 前一个 OTP 仍有效 → 请求新 OTP 后旧的没失效
8. OTP 未绑定 session → A 的 OTP 用在 B 的 session 上
4.3 备用验证方式绕过
1. "记住此设备"Cookie → 复制 remember_device Cookie 到新浏览器
2. 备用码（Recovery Code）→ 检查是否可预测或可枚举
3. 短信/邮件回退 → 用 Host 头投毒劫持验证链接
4. 安全问题回退 → 答案可能被猜测或在其他泄露中
4.4 MFA 配置阶段攻击
1. MFA 绑定时替换 user_id → 给受害者绑定攻击者的 2FA 设备
2. MFA 解绑请求无二次认证 → 直接 DELETE /mfa 解除保护
3. TOTP Secret 泄露 → 检查 /mfa/setup 响应中的 otpauth:// URI
- Shopify #629892 — $4,000 — 通过 GraphQL 禁用任意用户的 2FA
- GitLab #743096 — $3,000 — MFA 验证码不过期，可无限重试
Phase 5: Session 管理攻击
5.1 Session 固定（Session Fixation）
1. 访问目标获取 Session ID（未登录状态）
2. 将此 Session ID 传给受害者（通过 URL/Cookie 注入）
3. 受害者用此 Session ID 登录
4. 攻击者用同一 Session ID 获得受害者权限
检测：登录前后 Session ID 是否改变？
→ browser_get_cookies 对比登录前后的 session cookie
→ 如果相同 → Session Fixation 可能存在
5.2 Session 不过期/过长有效期
1. 登录获取 session
2. 退出登录
3. 用旧 session 继续请求 → 如果仍有效 → Session 未正确注销
4. 长时间不活动后 session 仍有效？
5. 密码修改后旧 session 仍有效？
6. 角色变更后旧 session 权限未更新？
5.3 并发 Session 控制
1. 设备 A 登录
2. 设备 B 登录同一账户
3. 设备 A 的 session 是否失效？
→ 如果不失效：攻击者一旦获得凭据，受害者改密码也踢不掉
5.4 Session Token 可预测
收集 5-10 个 session token，分析：
1. 是否包含可识别的模式（时间戳、递增数字）
2. 熵是否足够（短 token 可爆破）
3. 是否包含 Base64 编码的用户信息 → 解码检查
4. 是否使用已知弱算法（MD5(username+timestamp) 等）
Phase 6: 注册逻辑漏洞
6.1 重复注册覆盖
1. 注册 admin@target.com（如果允许）
2. 如果"邮箱已存在"→ 测试大小写绕过：Admin@target.com
3. 测试 Unicode 绕过：ɑdmin@target.com（拉丁字母 ɑ）
4. 测试空格注入：" admin@target.com" / "admin@target.com "
5. 测试加号技巧：admin+anything@target.com
6.2 邮箱验证绕过
1. 注册后不验证邮箱直接登录 → 能访问功能？
2. 修改注册响应中的 verified 字段 → {"verified": true}
3. 验证链接中的 token 可预测？
4. 验证请求中修改邮箱 → POST /verify {"token":"xxx","email":"other@x.com"}
6.3 邀请码/注册码绕过
1. 删除邀请码字段 → 注册成功？
2. 空邀请码 → {"invite_code": ""}
3. 常见弱码 → 000000, 123456, default
4. 其他用户的邀请码重复使用 → 未绑定一次性？
Phase 7: API 认证缺失模式
7.1 微服务间信任
微服务架构中，服务间通信常假设"内网可信"：
1. 添加 Header → X-Internal-Request: true
2. 添加 Header → X-Service-Name: auth-service
3. 内网 IP 伪造 → X-Forwarded-For: 10.0.0.1
4. 直接访问内部端口 → 目标:8080/internal/api
真实案例：Uber #1090871 — $6,500 — 内部 API 通过 X-Uber-Source header 信任请求
7.2 GraphQL 认证盲点
1. Introspection 查询 → {__schema{types{name,fields{name}}}} → 无需认证
2. 找到 mutation 后直接调用 → 部分 mutation 忘加认证
3. 不同 operation 不同认证 → query 需要认证，mutation 不需要
4. Batch query 绕过速率限制 → [{"query":"..."}, {"query":"..."}]
7.3 API Key 管理漏洞
API Key 泄露来源：
1. 前端 JS 源码中硬编码
2. GitHub/GitLab 公开仓库
3. 移动端 APK 反编译
4. HTTP Referer 头泄露（Key 在 URL 中）
5. 错误响应中泄露有效 Key
6. .env/.config 文件直接可访问
API Key 权限测试：
- Key 是否区分读/写权限？
- Key 吊销后是否立即失效？
- Key 是否绑定 IP/域名？
Phase 8: Race Condition 认证绕过
8.1 并发登录绕过锁定（⚠️ 仅对自己的测试账号）
账户锁定策略：5 次失败后锁定
验证方式（使用自己的测试账号）：
1. 同时发送 10 个登录请求（不同密码）
2. 如果锁定计数器非原子操作 → 实际可尝试 10+ 个密码
3. 记录现象即可证明漏洞
⛔ 禁止：对真实用户账号执行此测试（会导致账号被锁定）
8.2 并发 OTP 验证
OTP 验证后应失效，但如果非原子操作：
1. 获取有效 OTP
2. 同时发送 5 个验证请求（相同 OTP）
3. 如果多个返回成功 → OTP 验证非原子，可重用
8.3 并发注册同一用户名
1. 同时发送 10 个注册请求（相同用户名/邮箱，不同密码）
2. 如果多个成功 → 竞态条件
3. 用不同密码尝试登录 → 确定哪个密码生效
4. 真实案例：HackerOne #1131204 — 通过竞态条件绕过邮箱唯一性约束
Phase 9: 认证绕过决策树
💡 决策树警告：下面的 Step 1–6 是最常见的 6 个排查方向，不是穷尽列举，更不是"6 步走完就能下结论"。
特别注意：
- "全部失败 → 转向其他攻击面"是误导性描述——很多认证缺陷恰恰在这棵树之外：BFF/网关身份透传（
X-User-Id、X-Real-User、内部 JWT）、SSO backchannel logout 未生效、CDN/反代缓存了带身份的响应（不同用户读到同一份缓存）、负载均衡粘性会话错位、Service Worker / PWA / Electron IPC / WebView jsBridge 提供的高权限通道、运维端点（/_internal、/__debug、/actuator/*）走业务端口对外暴露、反向代理后的原始服务可被直达（origin bypass）、gRPC/Dubbo/RPC 内部调用默认信任。
- "登录端点测了 = 认证机制测过了"是错觉——主登录可能很硬，但
/api/v1/、移动端 /m/api/、小程序 /mp/、合作方 /partner/、Webhook、消息队列消费者 HTTP 入口、定时任务触发接口的鉴权可能完全不一样。
- "Session 测试通过 = 会话管理无缺陷"也是错觉——多租户
X-Tenant-Id 切换、JWT 与 Session 双轨制下的就低原则、刷新令牌与访问令牌的不对等失效、设备绑定逻辑漏洞，这些都不在 Step 4 的常规清单里。
- 以现场实际响应为准：决策树是思考起点，不是判断终点。一旦发现任一 Step 已构成证据（哪怕只走到 Step 1），先
checklist_mark vulnerable 再继续深挖，不要等树跑完。
目标有认证机制？
│
├── Step 1: 未授权访问检测
│ ├── 去掉认证头访问所有 API → 有 200？→ 漏洞！
│ ├── 旧版本 API（/v1/, /v2/） → 认证缺失？→ 漏洞！
│ └── 内部/调试端点 → /internal/, /debug/ → 可访问？→ 漏洞！
│
├── Step 2: 登录逻辑测试
│ ├── SQL 注入 → admin' -- → 登录成功？
│ ├── 参数操纵 → 删除/空/null 密码 → 登录成功？
│ ├── 默认凭据 → admin:admin → 登录成功？
│ └── 响应操纵 → 改 false→true → 前端绕过？
│
├── Step 3: MFA 绕过（如果有 MFA）
│ ├── 直接跳过 → Step 1 后直接访问业务页 → 可用？
│ ├── OTP 绕过 → 空码/通用码/爆破/响应泄露
│ └── 备用方式 → 记住设备 Cookie/备用码/短信回退
│
├── Step 4: Session 测试
│ ├── 固定 → 登录前后 Session ID 不变？
│ ├── 不过期 → 注销/改密码后旧 Session 仍有效？
│ └── 可预测 → Token 熵不足/包含用户信息？
│
├── Step 5: 注册逻辑
│ ├── 重复注册 → 大小写/Unicode/空格 绕过唯一性
│ ├── 验证绕过 → 不验证邮箱直接使用？
│ └── Mass Assignment → 注册时注入 role=admin？→ 转 privilege-escalation-web
│
├── Step 6: 高级绕过
│ ├── Race Condition → 并发绕过锁定/OTP/注册
│ ├── 认证降级 → 旧 API/移动端/Basic Auth
│ └── 微服务信任 → X-Internal-Request/X-Forwarded-For
│
└── 全部失败 → 转向其他攻击面
├── JWT 攻击 → jwt-attack-methodology
├── OAuth 攻击 → oauth-sso-attack
├── 密码重置 → password-reset-attack
├── 403 绕过 → 401-403-bypass
└── 权限提升 → privilege-escalation-web
Phase 10: 真实案例速查表
| 目标 | 漏洞 | 赏金 | 关键发现技巧 |
|---|
| Uber | 内部 API 通过 Header 信任请求 | $6,500 | X-Uber-Source header 伪造 |
| Shopify | GraphQL 禁用任意用户 2FA | $4,000 | mutation 未检查当前用户 |
| Starbucks | API v1 认证缺失 | $4,000 | /api/v1/ 完全无认证 |
| Airbnb | MFA 跳过（直接访问仪表盘） | $3,500 | Step 1 后 session 已完全认证 |
| Microsoft | 并发注册覆盖账户 | $5,000 | 竞态条件绕过唯一性约束 |
🚨 证据级响应与记录时机
认证绕过一旦出现“未经完整认证却获得受保护权限”的证据，立即 checklist_mark(... result="vulnerable")。 不要为了继续挖账户接管链路而延迟记录；后续影响力用 note_add(type="result") 追加。
认证绕过证据级响应（任一即可）
- ✅
drop_auth=True 或删除 Cookie/Authorization 后，仍能访问原本需要登录的 API 数据
- ✅ 登录流程失败响应被前端信任，修改响应后可进入受保护页面，且后续 API 没有二次校验
- ✅ MFA 流程未完成时，临时 token/session 已能访问业务 API 或仪表盘
- ✅ 注销、改密、角色变更后，旧 Session/Token 仍可执行敏感操作
- ✅ 注册/验证/邀请流程可跳步，未完成验证即可获得已验证用户能力
- ✅ 旧版本、移动端、内部端点比主流程少认证步骤，返回同等权限数据
结果分级
vulnerable：可复现地绕过认证前置条件，并访问受保护资源或完成敏感动作needs_review：发现登录态异常、响应差异、临时 token 权限过大等线索，但还不能证明权限获得not_vuln：完成最低必测自检，未授权、MFA、Session、注册、降级路径均无绕过证据skipped：缺少账号、MFA、注册权限、测试环境或授权范围导致无法验证，必须写明缺失条件
输出格式
[认证绕过检查]
入口/流程：登录/API/MFA/注册/找回/Session/旧版本/内部接口/其他
认证方式：Cookie/Bearer/JWT/APIKey/Basic/OAuth/自定义/未知
测试动作：删认证/空token/错token/低权限/跳步/MFA未完成/旧session/降级路径/响应操纵
响应差异：状态码/业务字段/跳转/错误消息/权限结果
结论：confirmed_vuln | suspected_vuln | needs_review | not_vuln
未测原因：缺账号/缺MFA/缺注册权限/缺旧接口样本/其他
证据收集规范
认证绕过漏洞的核心证据 = 证明"未经合法认证获得了已认证用户的权限"。
有效 PoC 必须包含
- 正常认证流程截图：展示正常需要的认证步骤
- 绕过过程的完整请求/响应：每一步的 HTTP 请求（含 Header）+ 响应
- 绕过后的权限证明：证明确实获得了受保护资源/功能的访问权
- 影响范围：是否影响所有用户？管理员？特定角色？
升级影响力
✅ 好的证据:
"目标应用 /api/v2/users 端点需要 Bearer Token 认证，
但 /api/v1/users 端点未添加认证中间件。
直接 GET /api/v1/users 返回所有用户列表（含邮箱、手机号）。
进一步测试 POST /api/v1/users/{id}/reset-password 同样无需认证，
可重置任意用户密码实现账户接管。
影响：全部 50,000+ 用户的个人信息泄露 + 任意账户接管。"
❌ 差的证据:
"不带 Cookie 访问 /api/users 返回了 200"
（没有对比正常流程、没有说明影响）
每确认一个认证绕过立即 vuln_verify + note_add(type="result") 记录。
⛔ 「最低必测自检」— 标 not_vuln/skipped 前必答
任何认证绕过项准备标 not_vuln 或 skipped 前，必须逐条回答下面问题。只测了正常登录失败，不等于测过认证绕过。
| # | 必测项 | 跳过的合法理由 |
|---|
| 1 | 无认证基线：对目标受保护 API 使用 drop_auth=True 或删除 Cookie/Authorization 重发，确认是否仍返回业务数据 | 目标功能本身公开，无认证要求 |
| 2 | 无效认证对照：使用空 token、随机 token、过期 token、其他测试账号 token 访问同一接口，看是否被正确拒绝 | 目标只使用 Session Cookie 且无法构造 token |
| 3 | 登录流程跳步：记录完整登录流程后，直接访问最后一步页面/API；如果有 MFA，必须测试 MFA 未完成时访问业务 API | 目标没有多步骤认证/MFA |
| 4 | 响应操纵检查：如果前端根据登录响应字段跳转，尝试把 success:false、authenticated:false、role:user 改成成功/管理员值，确认后端 API 是否二次校验 | 非 SPA/前端不依赖响应字段控制权限 |
| 5 | Session 生命周期：注销、改密、角色变更后，旧 Session/Token 是否仍能访问敏感 API | 无法执行注销/改密/角色变更操作 |
| 6 | 认证降级路径：测试 /api/v1/、移动端 API、内部 API、Basic Auth、API Key、旧 OAuth 回调等是否比主流程少认证步骤 | 已确认不存在旧版本/移动端/内部路径 |
| 7 | 注册/验证绕过：注册后不验证邮箱/手机号能否使用核心功能？邀请/注册码能否删除、复用、置空、替换？ | 目标无注册/邀请/验证流程 |
| 8 | 默认/泄露凭据只读验证：如果发现默认凭据或泄露 Key，只做登录成功/权限范围截图，不继续操作业务数据 | 无凭据线索 |
跳过的"非法"理由
- ❌ "登录接口不能爆破，所以没有认证绕过" → 认证绕过重点是流程和状态，不是爆破
- ❌ "前端跳不过去，所以后端安全" → 必须直接请求后端 API 验证
- ❌ "MFA 页面拦住了" → 必须验证 MFA 前的临时 session/token 是否能调用业务 API
- ❌ "注销后页面跳登录" → 必须用旧 Cookie/Token 直接请求 API，而不是只看页面跳转
⚠️ Skill 边界与逃逸
本 Skill 是辅助参考，不是束缚你的脚手架。在以下情况下，请主动跳出本 Skill 的清单，按你自己的判断行动：
-
现场证据与本 Skill 矛盾时
- 例如本 Skill 说"删除认证头后 200 = 未授权"，但你看到目标返回 200 却只是公开默认响应体，真正的鉴权可能在 Header、在渲染阶段、在下一跳接口才生效 —— 以现场为准，重新定义你的证据门槛。
- 反过来，本 Skill 说"401/403 = 有认证检查"，但你可能发现 401 响应中已经伴随返回了部分业务数据，那这个“拒绝”其实是不完整的。
-
遇到本 Skill 没列出的入口或路径
- 例如：BFF/网关层身份透传（
X-User-Id、X-Real-User、内部 JWT 与外部 JWT 转换）、gRPC/Dubbo 调用默认信任、SSO 的 backchannel logout 未生效、CDN/Cache 缓存了用户专有响应、负载均衡粘性 session 错位、Service Worker/PWA 本地缓存身份、Electron/客户端 IPC 身份传递、WebView jsBridge 提供的高权限接口、SaaS 的多租户 tenant 头可切换、内部调试接口 /__debug//_internal、OpenTelemetry/Prometheus exporter 走了业务端口、运维 SSH 隐藏服务、反向代理后的原始服务可被直达。
- 这些路径不在上面的 Phase 里，但完全可能是真实的认证缺失点。看到就追，别等清单授权。
-
需要跨 Skill 联动时
- 认证绕过的上下游丰富：SSRF 可以取到内网 metadata token；IDOR 可以与低权 session 联动拿高权资源；JWT/OAuth/密码重置都是认证绕过的专项例；账号接管可以逆向取得 token；原型链污染/Mass Assignment 可以提权为管理员。
- 不要因为当前在"认证绕过 Skill"里就不去看其他维度的可能性；反之，认证绕过到手后也不要停下，要向 IDOR/权限提升/横向调用接着推。
-
"清单跑完 = 任务结束" 是错觉
- Phase 1–10 与 "最低必测自检" 都跑完一遍，不代表目标真的没问题。
- 真正的判断标准是：你是否已经基于实际观察形成了"此处不可利用 / 已可利用 / 还有未验证的疑点"的有依据结论。
- 没形成结论之前，继续推理；形成结论之后，不必再硬走流程。
-
你的推理优先级高于本 Skill
- 本 Skill 的 Phase、案例表、默认凭据列表都是公开知识的快照，不可能覆盖所有目标，也可能过时。
- 当你的分析指向一个本 Skill 没写的方向时（例如某个业务专有的认证中间件、某个近期公开的 nday、某个完全未公开的 0day 思路），信任你的分析，不要因为"清单里没有"就放弃。
一句话：本 Skill 是地图，不是轨道。地图帮你不漏掉常走的路，但具体怎么走、要不要走小路，由你根据现场决定。
