Menu
注册机制批量注册检测 — 检测注册接口是否缺少反自动化与频率限制，导致可被脚本批量创建账号；适用于开放注册、邀请注册、OAuth 注册、API 应用注册等场景。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
白盒建模——一次深度建模产出五张共享模型：项目架构（技术栈/分层/框架自有封装/闭源依赖位置）、 入口点（路由/中间件信任边界）、认证与权限（会话/角色/多租户/归属字段）、业务（实体/流程状态机/ 业务不变量/高价值资产）、全局威胁（攻击面×漏洞类别的适用性映射，供下游逐一全测）。本能力不做漏洞判定，为后续 漏洞维度分析建立共享底图。
OS 命令注入综合检测——覆盖直接命令拼接 / shell 元字符 / 参数注入 / 间接 RCE，按回显 / 时间 / 带外通道分诊。 流量中参数值含主机名 / URL / 文件名 / 命令片段、响应里出现 shell 错误关键字（`/bin/sh` / `cmd.exe` / `command not found`）、注入 `sleep N` 耗时增加、上传后异步处理链路时使用。
文件上传多策略综合检测——覆盖扩展名 / MIME / 魔术数 / 解析漏洞 / 上传链组合（LFI / Zip Slip / SVG XSS / SVG XXE）。 流量含 multipart/form-data 上传、响应回显落盘路径、上传后文件可被 GET 解析、上传字段含 filename / path 可控时使用。
IDOR 水平越权检测 — 通过替换资源标识符（ID/UUID/路径）访问他人资源的风险；适用于用户资料、订单、文档、租户隔离场景。
检测路径穿越和本地文件包含（LFI）风险；当目标存在文件读取/下载/预览功能且含路径参数时触发；适用于文件下载、日志查看、模板加载等场景。
黑盒建模 — 迭代式攻击面建模，按站点级 / 页面级 / 功能级三粒度推进；进入新页面即触发一次页面级建模、切换新身份各刷新一次，产出端点账本与页面语义模型，为后续漏洞维度的适用性判断提供依据。
| name | registration-abuse |
| description | 注册机制批量注册检测 — 检测注册接口是否缺少反自动化与频率限制，导致可被脚本批量创建账号；适用于开放注册、邀请注册、OAuth 注册、API 应用注册等场景。 |
| when-to-use | 当需要检测注册接口是否存在批量注册滥用风险时 |
| allowed-tools | read_file,list_files,rg,bash,list_skills |
| user-invocable | false |
| argument-hint | <target_url> |
| arguments | ["target_url"] |
注册滥用成因：source（注册请求）→ sink（用户创建：数据库 INSERT user / session 签发 / 邀请码核销 / 新用户欢迎资源发放）。无速率限制 / 无唯一约束 / 无验证码 / 无邮箱手机校验 / 邀请码可枚举，业务命名不可作筛选——无论入口叫"普通注册"、"OAuth 注册"、"邀请码注册"、"一键试用"、"临时账号"、"子账号"、"API 应用注册"，sink 语义都是"输入流向用户创建"，属同一范围。详见同根目录 pentest/web-security-testing/SKILL.md 漏洞成因图谱 · 注册滥用行（不在本 skill 重复成因）。
关键 sink 形态：服务端在接收请求后，未做有效的多维反自动化校验就把账号写入数据库并签发可登录凭证——攻击者可低成本批量创建账号（账号农场 / 撸羊毛 / 大量子账号污染）。
以下是已知的常见注册滥用触发线索，作为基线起点而非必检硬清单。结合目标代码与上下文动态调整：
[x] done[-] n/a (原因)，原因要具体到代码事实[+] added (来源)基线触发线索按"sink 语义"分类（不按业务命名）：
/oauth/callback 等/register?inviteCode=xxx 或后台批量生成的激活码入口userRepo.Create(req) / db.Insert("user", ...) / auth.SignUp() 直接调用、上层无 rate-limit / no captcha / no uniqueness check加载本 skill 时按这些问题思考：
INSERT user 并签发可登录凭证？还是只是预注册待审？X-Forwarded-For / X-Real-IP / Forwarded 是否影响限流键userRepo.Create(req) 在未做服务端验证码 / 速率限制校验前直接落库并签发 token（register-email-no-captcha-no-ratelimit-registration-abuse）/oauth/callback 拿到 OAuth provider 返回的 email 后直接 userRepo.Upsert(email)，攻击者可对同一 provider 不同 sub 反复创建（oauth-callback-auto-create-user-registration-abuse）invite-code-enumerable-bulk-account-registration-abuse）/app/register 对每个用户无应用数量上限，可批量创建 app 消耗 API key 池 / 调用配额（api-app-register-no-quota-registration-abuse）以下是注册滥用维度的典型窄化误判：
为什么这里是「必须」：反例义务属于交付契约——"该子系统注册滥用已防护"结论是覆盖完整性的产物声明，缺失反向验证清单会让下游误信"该维度全站安全"。
写"未发现注册滥用"或"已防护"前，产物必须包含：
清单不完整 → 结论降级为 partial-coverage 并显式声明未覆盖范围。
特别警示：只测了"普通邮箱注册"而未覆盖"OAuth / 邀请码 / API 应用 / 子账号"等其他入口，不能下"全站无注册滥用"结论。
通用闭环口径见同根目录 common/closure-verification.md（技能表 path 列同一抽取根下，需要时 read_file 读取）。核心：结论须形成「输入 → 处理 → 真实危害 → 可复核证据」完整证据链；仅凭注册接口返回 success / 前端提示等中间信号最多判 suspected，证明实际批量创建了可用账号或绕过了关键反滥用机制（验证码 / 频率 / 唯一性 / 邀请码）才判 confirmed。
confirmed| 现象 | 判定 |
|---|---|
| 连续注册大部分成功且账号被真实创建可使用，无有效反自动化/限速 | confirmed |
| 可注册数量受限但仍存在批量创建迹象，或账号可用性未完全确认 | suspected |
| 注册流程具备有效风控（服务端校验的验证码、多维频控、设备/IP 限制、邀请码强约束）且难以批量成功 | not vulnerable |
| 只测了部分子系统 / 部分注册入口 / 部分反滥用维度 | partial-coverage（不得宣称 safe） |