registration-abuse

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 语义"分类（不按业务命名）：

• 普通用户注册：邮箱注册 / 手机号注册 / 用户名密码注册等显式 web 注册接口
• OAuth / 第三方登录回调：首次 OAuth 登录自动建号的 /oauth/callback 等
• 邀请码 / 激活码注册：/register?inviteCode=xxx 或后台批量生成的激活码入口
• 一键试用 / 临时账号：免注册体验、试用账号生成、匿名账号转正
• 子账号 / 协作成员添加：在主账号下创建子账号、邀请协作成员（也会形成账号）
• API 应用 / 开发者注册：开放平台 app 创建、应用注册、API key 申请等也产生账号实体
• 跨子系统覆盖：多个子系统各自有独立注册入口——每个入口的反滥用配置都需独立测
• 代码模式：后端代码出现 userRepo.Create(req) / db.Insert("user", ...) / auth.SignUp() 直接调用、上层无 rate-limit / no captcha / no uniqueness check

思考检查点

加载本 skill 时按这些问题思考：

• 这个端点最终是否会触发 INSERT user 并签发可登录凭证？还是只是预注册待审？
• 是否有验证码、邮箱/手机校验、邀请码、设备指纹等反自动化校验？是否都仅前端展示、服务端可绕过？
• 同一类 sink（"用户创建"）的其他入口（OAuth / 邀请 / API 应用）是否独立配置反滥用？
• 邀请码是否可枚举 / 可预测 / 可重置 / 无次数上限？
• 邮箱校验是否真校验？是否能用 disposable 邮箱 / 别名变体 / 临时邮箱绕过？
• 跨子系统的注册模块是否各自独立结账？

前置条件与安全边界

• 仅在测试环境与测试数据执行；不跨租户、不碰真实用户手机号/邮箱。
• 默认最多创建 10 个测试账号后停止并清理；若环境无法清理，缩减至 3~5 个并显式记录。
• 不能只看"注册接口返回 success"，至少要结合账号能否登录 / 用户列表是否出现 / 邀请码核销记录 / 欢迎资源发放等真实证据之一确认账号已创建。
• 一旦确认存在批量创建能力，立即停止扩展样本，进入证据固化并清理测试数据。

检测步骤

Step 1：基线与最小可行注册参数

1. 确认注册接口所需字段与最小可行注册参数（哪些 required / 哪些 optional / 哪些是反滥用挑战字段）。
2. 用一组合法参数完成一次注册，确认成功业务码、失败业务码和提示字段。
3. 区分"HTTP 200 但业务失败"与"账号真实创建"（用户列表 / 登录尝试 / 后台审计）。

Step 2：批量发起 + 反滥用维度扫描

1. 以不同账号标识（邮箱/手机号/用户名）连续发起注册请求，记录每次的响应。
2. 仅改变以下单一维度，观察服务端是否真校验：
   • 验证码 / 行为挑战：是否仅前端展示，API 直连绕过页面后是否仍校验
   • 邮箱归一化：是否真校验邮箱可达性，能否用 disposable 邮箱、别名变体、临时邮箱
   • 手机号归一化：是否真发短信校验，能否用虚拟号
   • 来源识别链：X-Forwarded-For / X-Real-IP / Forwarded 是否影响限流键
   • 设备指纹 / Session / 登录态切换

Step 3：邀请码 / OAuth / API 应用等专用入口

1. 邀请码：可枚举性（递增 / 短码） / 单码次数上限 / 过期机制 / 是否可重置。
2. OAuth 注册回调：是否对 OAuth provider 返回的 email / sub 做唯一性约束，是否能用同一第三方账号建出多个本地账号。
3. API 应用 / 开发者注册：是否有每用户的应用配额、是否能批量创建消耗 API key 池。

Step 4：账号真实可用性确认 + 跨端点 / 跨子系统传播

1. 抽样登录验证一批创建出的账号，确认凭证真实可用。
2. 验证是否真实消耗了邀请码、配额、欢迎资源、新人福利等系统对象。
3. 若该端点确认存在批量注册能力 → 按"端点矩阵传播"横扫同子系统其他注册入口 + 跨子系统的注册模块。

示例库

正例形态（代码层根因）

• 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）

窄化反例（必须避免）

以下是注册滥用维度的典型窄化误判：

• "看起来有验证码 → 安全" — 错。验证码可能可重放、API 直接调用绕过页面、自动化求解；必须验证服务端是否真校验。
• "已测了 web 注册 → 跳过 OAuth 注册" — 错。OAuth 注册 / 邀请码注册 / API 应用注册 / 子账号添加等不同入口都是独立 sink，必须按端点账本逐个测。
• "邀请码限 1 次 → 安全" — 错。邀请码可能可枚举 / 可预测 / 可重置 / 后台批量生成无次数控制；需独立测邀请码空间本身的可枚举性与重放性。
• "已在子系统 A 命中 → B 也假定同样" — 错。跨子系统的注册模块独立配置，必须按子系统独立结账。
• "注册后还要邮箱验证 → 已防滥用" — 错。需验证邮箱验证是否真校验（API 直接调用绕过验证 endpoint）、是否能用 disposable 邮箱、未验证邮箱的账号是否仍消耗欢迎资源 / 邀请码 / 配额。

反例义务（必须遵守）

为什么这里是「必须」：反例义务属于交付契约——"该子系统注册滥用已防护"结论是覆盖完整性的产物声明，缺失反向验证清单会让下游误信"该维度全站安全"。

写"未发现注册滥用"或"已防护"前，产物必须包含：

• 测过的注册候选端点完整清单（按 sink 语义枚举：所有"用户输入触发用户创建"的端点；含普通注册 / OAuth / 邀请码 / 一键试用 / 子账号 / API 应用注册等全部触发线索类别）
• 每个端点测过的反滥用维度（速率限制 / 服务端验证码强制 / 邮箱可达性校验 / 邀请码枚举与重放 / 唯一性约束 / 多维限流键 / disposable 邮箱）
• 每个端点的账号真实创建证据（登录成功 / 用户列表 / 后台审计 / 邀请码核销 / 资源消耗）

清单不完整 → 结论降级为 partial-coverage 并显式声明未覆盖范围。

特别警示：只测了"普通邮箱注册"而未覆盖"OAuth / 邀请码 / API 应用 / 子账号"等其他入口，不能下"全站无注册滥用"结论。

闭环验证要求（必须遵守）

通用闭环口径见同根目录 common/closure-verification.md（技能表 path 列同一抽取根下，需要时 read_file 读取）。核心：结论须形成「输入 → 处理 → 真实危害 → 可复核证据」完整证据链；仅凭注册接口返回 success / 前端提示等中间信号最多判 suspected，证明实际批量创建了可用账号或绕过了关键反滥用机制（验证码 / 频率 / 唯一性 / 邀请码）才判 confirmed。

实际效果验证方向（至少证明一类）

• 批量注册后账号真实创建成功，并可登录或出现在用户列表/后台
• 注册动作真实消耗邀请码、配额、欢迎资源或系统对象，形成自动化滥用效果
• 服务端反滥用维度（验证码 / 唯一性 / 多维限流）被证实可绕过，并真实落库
• 若只有注册接口返回成功，但未证明账号真实存在和可用，不能给 confirmed

判定标准

现象	判定
连续注册大部分成功且账号被真实创建可使用，无有效反自动化/限速	confirmed
可注册数量受限但仍存在批量创建迹象，或账号可用性未完全确认	suspected
注册流程具备有效风控（服务端校验的验证码、多维频控、设备/IP 限制、邀请码强约束）且难以批量成功	not vulnerable
只测了部分子系统 / 部分注册入口 / 部分反滥用维度	partial-coverage（不得宣称 safe）

修复建议

• 对注册链路接入多维风控（IP、设备指纹、账号维度、来源识别链）
• 强制服务端校验的验证码 / 行为挑战，高风险来源提高校验强度
• 引入注册速率阈值与异常注册告警，支持自动封禁与人工复核
• 强制邮箱 / 手机号可达性校验，禁止 disposable 邮箱与虚拟号
• 邀请码采用高熵随机串 + 单码次数严格限制 + 过期机制 + 防枚举
• OAuth 回调对 provider 返回的 sub / email 做唯一性约束，避免反复建号
• 对每用户的子账号 / API 应用数量设上限，并对欢迎资源发放做去重