메뉴
认证绕过完整方法论 — 基于 300+ HackerOne/Bugcrowd 真实报告提炼。覆盖未授权访问、登录逻辑缺陷、MFA 绕过、Session 管理攻击、认证降级、默认/泄露凭据、注册逻辑漏洞、API 认证缺失、Response 篡改、Race Condition 认证绕过。任何出现 login/session/token/cookie/Authorization/MFA/2FA/验证码/注册验证/受保护 API 的场景都必须使用此 skill。
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/haibo3434358/ScareAISec --skill auth-bypass-methodology명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
攻击面发现总控方法论。在爬取、抓包、JS 分析、API 文档分析、登录后探索、多角色对比阶段使用。用于把页面、接口、参数、Header、Cookie、WebSocket、GraphQL、上传、导入导出、支付、回调、对象存储等所有外部输入点系统性枚举出来，并把每个入口映射到后续漏洞 discovery skill。
Session cookie 分析与伪造方法论。当发现 Web 应用使用 cookie 进行认证、需要判断 cookie 类型并选择伪造方法时使用。覆盖 unsigned base64 cookie 直接伪造、Flask 签名 cookie（flask-unsign 爆破密钥）、加密/二进制 cookie 的识别。本技能负责 cookie 类型判断和分流：如果判断为 JWT（三段式 eyJ 开头），应转至 jwt-attack-methodology；如果判断为加密 cookie 需要 Padding Oracle，应转至 crypto-web-attack
通用漏洞发现方法论 — 当遇到不在已有SKILL覆盖范围内的场景时，教LLM如何系统性地发现漏洞。覆盖：输入点穷举、响应差异分析、边界条件探测、未知技术栈适应、容易被忽略的攻击面。
SOC 직업 분류 기준
SKILL.md 표시 중
| 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 工具 |
|---|---|
| 记录完整登录/注册/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 做二次校验。
看到登录、注册、MFA、验证码、Authorization、Cookie、session、token、refresh_token、/api/v1/、移动端 API、内部 API、受保护资源时，必须进入本 skill。认证绕过的第一目标不是爆破密码，而是证明 服务端是否在每条受保护路径、每个步骤、每种客户端、每个旧版本接口上都执行了认证检查。
优先顺序：
| 响应现象 | 不要立刻下结论 | 下一步 |
|---|---|---|
删除认证后 200 + 业务数据 | 高危信号 | 与正常登录响应对照，确认是否受保护数据 |
删除认证后 200 + 空对象 | 可能软拒绝或数据为空 | 换对象 ID、分页、导出接口、移动端接口 |
302 到登录页 | 页面拒绝不代表 API 拒绝 | 直接请求 JSON API，看是否仍返回数据 |
401/403 | 有认证检查但可能不完整 | 方法切换、路径变体、Header 伪造、旧版本 API |
404 | 可能权限伪装 | 用高权限/合法对象确认资源存在 |
| MFA 未完成但有临时 token | 高危信号 | 用临时 token 调业务 API |
| 注销后页面跳登录 | 不足以证明失效 | 用旧 Cookie/Token 直接请求 API |
认证绕过 ≠ 密码爆破。90% 的认证绕过来自逻辑缺陷，而非密码学弱点。开发者实现了认证，但在某些路径上忘了检查、检查不完整、或检查可被绕过。
五大根因（HackerOne 数据）：
检查目标使用的认证方式（常多种并存）：
├── 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
必查端点（不管爬虫有没有发现）：
/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/*
先正常走一遍完整登录流程，用 proxy 记录每一个请求：
记录项：
1. 登录请求格式（POST body 字段名、是否加密）
2. 登录成功响应（Set-Cookie? Token? redirect?）
3. 后续请求如何携带认证（Cookie? Header?）
4. 认证失败的响应特征（状态码、错误消息、响应体差异）
5. 是否有 MFA/2FA 第二步
6. 是否有"记住我"功能
7. 是否有验证码（CAPTCHA）
在测试任何绕过之前，先检查是否有端点根本就没加认证。
对每个已知的 API 端点：
1. 正常请求（带 Cookie/Token）→ 200
2. 去掉 Cookie/Authorization 头 → 还是 200？→ 未授权访问！
3. 用空 Token → Authorization: Bearer → 200？
4. 用无效 Token → Authorization: Bearer invalid → 200？
| 端点模式 | 原因 | 优先级 |
|---|---|---|
/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 | 导出接口常被遗漏 | 🔴 高 |
GET /api/admin/users → 401
POST /api/admin/users → 200？（不同方法不同的认证中间件）
OPTIONS /api/admin/users → 200 + 敏感 Header 泄露？
PUT /api/admin/users → 200？
用户名字段测试（经典但仍有效）：
admin' --
admin' OR '1'='1' --
admin'/*
' OR 1=1 --
" OR 1=1 --
admin') OR ('1'='1
发现信号：登录失败消息不同（"用户不存在" vs "密码错误"）→ 用户名枚举 + SQL 注入可能。
抓取登录失败的响应：
POST /api/login → {"success": false, "role": "none"}
用 proxy_replay 修改响应：
{"success": true, "role": "admin"}
如果前端据此跳转 → 认证仅在前端执行
HackerOne 真实案例：多个 SPA 应用（React/Vue）在登录响应中返回 {"authenticated": true}，前端直接据此显示管理面板，后续 API 调用也不再验证。
正常登录：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}
如果正常登录需要 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 直接使用
高频默认凭据：
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:（空）
正常流程：
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 用 → 权限相同？
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 上
1. "记住此设备"Cookie → 复制 remember_device Cookie 到新浏览器
2. 备用码（Recovery Code）→ 检查是否可预测或可枚举
3. 短信/邮件回退 → 用 Host 头投毒劫持验证链接
4. 安全问题回退 → 答案可能被猜测或在其他泄露中
1. MFA 绑定时替换 user_id → 给受害者绑定攻击者的 2FA 设备
2. MFA 解绑请求无二次认证 → 直接 DELETE /mfa 解除保护
3. TOTP Secret 泄露 → 检查 /mfa/setup 响应中的 otpauth:// URI
HackerOne 真实案例：
1. 访问目标获取 Session ID（未登录状态）
2. 将此 Session ID 传给受害者（通过 URL/Cookie 注入）
3. 受害者用此 Session ID 登录
4. 攻击者用同一 Session ID 获得受害者权限
检测：登录前后 Session ID 是否改变？
→ browser_get_cookies 对比登录前后的 session cookie
→ 如果相同 → Session Fixation 可能存在
1. 登录获取 session
2. 退出登录
3. 用旧 session 继续请求 → 如果仍有效 → Session 未正确注销
4. 长时间不活动后 session 仍有效？
5. 密码修改后旧 session 仍有效？
6. 角色变更后旧 session 权限未更新？
1. 设备 A 登录
2. 设备 B 登录同一账户
3. 设备 A 的 session 是否失效？
→ 如果不失效：攻击者一旦获得凭据，受害者改密码也踢不掉
收集 5-10 个 session token，分析：
1. 是否包含可识别的模式（时间戳、递增数字）
2. 熵是否足够（短 token 可爆破）
3. 是否包含 Base64 编码的用户信息 → 解码检查
4. 是否使用已知弱算法（MD5(username+timestamp) 等）
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
1. 注册后不验证邮箱直接登录 → 能访问功能？
2. 修改注册响应中的 verified 字段 → {"verified": true}
3. 验证链接中的 token 可预测？
4. 验证请求中修改邮箱 → POST /verify {"token":"xxx","email":"other@x.com"}
1. 删除邀请码字段 → 注册成功？
2. 空邀请码 → {"invite_code": ""}
3. 常见弱码 → 000000, 123456, default
4. 其他用户的邀请码重复使用 → 未绑定一次性？
微服务架构中，服务间通信常假设"内网可信"：
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 信任请求
1. Introspection 查询 → {__schema{types{name,fields{name}}}} → 无需认证
2. 找到 mutation 后直接调用 → 部分 mutation 忘加认证
3. 不同 operation 不同认证 → query 需要认证，mutation 不需要
4. Batch query 绕过速率限制 → [{"query":"..."}, {"query":"..."}]
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/域名？
账户锁定策略：5 次失败后锁定
验证方式（使用自己的测试账号）：
1. 同时发送 10 个登录请求（不同密码）
2. 如果锁定计数器非原子操作 → 实际可尝试 10+ 个密码
3. 记录现象即可证明漏洞
⛔ 禁止：对真实用户账号执行此测试（会导致账号被锁定）
OTP 验证后应失效，但如果非原子操作：
1. 获取有效 OTP
2. 同时发送 5 个验证请求（相同 OTP）
3. 如果多个返回成功 → OTP 验证非原子，可重用
1. 同时发送 10 个注册请求（相同用户名/邮箱，不同密码）
2. 如果多个成功 → 竞态条件
3. 用不同密码尝试登录 → 确定哪个密码生效
4. 真实案例：HackerOne #1131204 — 通过竞态条件绕过邮箱唯一性约束
💡 决策树警告：下面的 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
| 目标 | 漏洞 | 赏金 | 关键发现技巧 |
|---|---|---|---|
| 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 数据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/缺注册权限/缺旧接口样本/其他
认证绕过漏洞的核心证据 = 证明"未经合法认证获得了已认证用户的权限"。
✅ 好的证据:
"目标应用 /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 前，必须逐条回答下面问题。只测了正常登录失败，不等于测过认证绕过。
| # | 必测项 | 跳过的合法理由 |
|---|---|---|
| 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，只做登录成功/权限范围截图，不继续操作业务数据 | 无凭据线索 |
本 Skill 是辅助参考，不是束缚你的脚手架。在以下情况下，请主动跳出本 Skill 的清单，按你自己的判断行动：
现场证据与本 Skill 矛盾时
遇到本 Skill 没列出的入口或路径
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 隐藏服务、反向代理后的原始服务可被直达。需要跨 Skill 联动时
"清单跑完 = 任务结束" 是错觉
你的推理优先级高于本 Skill
一句话：本 Skill 是地图，不是轨道。地图帮你不漏掉常走的路，但具体怎么走、要不要走小路，由你根据现场决定。