notification-abuse

name	notification-abuse
description	通知滥用/邮箱短信轰炸检测 — 检测短信、邮件、验证码、IM 推送等触达通道的轰炸与反滥用缺陷，统一分诊连续发送/冷却时间/多维限流/人机挑战/多目标资源消耗。
when-to-use	当目标存在短信/邮件/验证码发送接口，需评估通知轰炸与反滥用防护时
allowed-tools	bash,read_file,list_files,rg
user-invocable	false

通知滥用检测

成因引用

通知滥用成因：source（注册 / 发送 / 触发请求）→ sink（短信 / 邮件 / IM 触达系统：实际下发通道、运营商 API、邮件 SMTP 队列、IM 推送 worker）。无速率限制 / 无验证码 / 无目标白名单 / 无每用户额度，业务命名不可作筛选——无论端点是"注册短信"、"密码找回邮件"、"验证码重发"、"邀请同事"、"订阅推送"，sink 语义都是"用户输入触发服务端向某目标地址发出真实通知"，属同一范围。详见同根目录 pentest/web-security-testing/SKILL.md 漏洞成因图谱 · 通知滥用行（不在本 skill 重复成因）。

关键 sink 形态：服务端在接收请求后，**未做有效的"按用户/按 IP/按目标地址多维限流"+"挑战二次校验"**就把通知投递任务下发到外部通道——攻击者可对某用户/海量用户构造大量真实通知（短信轰炸 / 邮件骚扰 / 密码找回邮件群发）。

触发线索（基线检查项）

以下是已知的常见通知滥用触发线索，作为基线起点而非必检硬清单。结合目标代码与上下文动态调整：

• 适用且已完成 → 标注 [x] done
• 明确不适用 → 标注 [-] n/a (原因)，原因要具体到代码事实
• 基线未列出但实际发现 → 新增条目并标注 [+] added (来源)

基线触发线索按"sink 语义"分类（不按业务命名）：

• 注册触发短信/邮件：注册流程中触发 OTP 或欢迎邮件下发的端点
• 密码找回 / 重置邮件：/forgot-password / /reset 等触达用户邮箱的端点
• 验证码发送 / 重发：登录 OTP / 绑定手机 OTP / 二次校验 OTP，含"重发"按钮的所有入口
• 绑定 / 解绑通知：手机号 / 邮箱绑定校验码、设备变更通知
• 邀请类：邀请同事 / 分享给好友 / 拉人入群等"向第三方目标"发通知的端点
• 订阅 / 推送偏好：订阅推送、营销邮件、通知偏好开启/关闭引发的确认通知
• 应用内 / 推送通道：IM、APP push、Webhook 等其他触达系统（不限于短信邮件）
• 跨子系统覆盖：多个子系统各自有独立通知模块——每个子系统的反滥用配置都需独立测
• 代码模式：后端代码出现 sms.Send(phone) / mailer.Send(to) / push.Send(targetUid) 直接调用、上层无 rate-limit / no challenge 校验

思考检查点

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

• 这个端点最终会触发服务端向哪个外部通道下发通知？是真实下发，还是只入队待审？
• 同一用户高频请求是否被服务端限流？限流是按 user / IP / target / session 哪个维度生效？只盖一个维度够吗？
• 如果切换目标地址（不同手机号 / 不同邮箱），原维度的限流是否还成立？
• 验证码 / 人机挑战是只在前端展示，还是服务端真正强制校验？API 直连绕过页面后是否仍校验？
• 同一类 sink（"通知下发"）的其他端点是否也同模式？跨子系统的通知模块是否独立测过？

前置条件与安全边界

• 仅对自有测试手机号、测试邮箱和授权环境执行，不对真实用户实施骚扰。
• 单目标默认最多 12 次请求；单接口总预算默认最多 30 次请求；目标数量默认不超过 3 个。
• 默认串行请求，间隔 0.5~1 秒；不能只看"业务成功响应"，至少要结合发送流水/消息 ID、额度变化、队列状态、冷却状态或自有测试目标收件结果之一验证真实发送效果。
• 禁止为了验证而扩大攻击面；一旦确认缺少有效防护，立即停止并进入证据固化。

检测步骤

Step 1：基线与成功判据确认

1. 用 1 个测试目标发送 1~2 次，确认成功业务码、失败业务码和提示字段。
2. 区分"HTTP 200 但业务失败"与"真正发送成功"（流水号 / 消息 ID / 自有测试目标收件确认）。
3. 识别目标参数：phone、mobile、email、receiver、account；业务场景参数：scene、bizType、action；反滥用相关参数：captcha、ticket、nonce、device_id、session；来源识别链：X-Forwarded-For、X-Real-IP、Forwarded。

Step 2：单目标连续发送 + 冷却 / 时间窗口

1. 对同一目标连续发送，观察是否出现"等待 N 秒"提示。
2. 若返回等待秒数，验证服务端是否真正强制该窗口（继续重放、绕过到下一秒等）。
3. 记录单目标在预算内可形成的真实发送数与每次响应特征。

Step 3：验证码 / 人机挑战 + 多维频率限制绕过

1. 阈值后是否真出现验证码/滑块/二次校验；服务端是否真校验，而不是仅前端展示。
2. 仅改变以下单一维度，观察额度是否被错误重置：
   • 来源识别链：X-Forwarded-For / X-Real-IP / Forwarded
   • 空白字符：目标参数两端的普通空格、Tab、全角空格、URL 编码空白（%20 / %09）
   • 手机号格式化：+86、0086、空格、横杠、括号等
   • 邮箱归一化：大小写差异、前后空白、业务允许范围内的别名/标签变体
   • 上下文切换：Session、设备标识、匿名/登录态、业务场景

Step 4：多目标切换 + 跨端点 / 跨子系统传播

1. 2~3 个测试目标轮换发送，验证是否存在接口级 / 账号级总量控制。
2. 若该端点确认存在通知滥用 → 按"端点矩阵传播"横扫同子系统其他通知端点 + 跨子系统的通知模块。

示例库

正例形态（代码层根因）

• sms.Send(req.Phone) 调用前无任何 rate-limit / captcha 校验，每次请求都触发真实短信下发（register-phone-sms-no-ratelimit-notify-abuse）
• /forgot-password 接收任意邮箱即调 mailer.Send(email, resetLink)，无人机挑战，可对任意目标用户群发密码找回邮件（forgot-password-email-no-captcha-notify-abuse）
• OTP "重发"按钮对应的 /resend-otp 端点只按 IP 限流，攻击者用不同 IP（或伪造 XFF）即可对同一手机号 / 不同手机号大量发送（otp-resend-target-multiuser-no-quota-notify-abuse）
• 邀请同事接口 /invite 接收邮箱列表数组，循环对每个邮箱发送邀请邮件且无总量上限（invite-coworker-email-fanout-notify-abuse）

窄化反例（必须避免）

以下是通知滥用维度的典型窄化误判：

• "页面有验证码 → 已防滥用" — 错。验证码可能可重放、API 直接调用绕过页面、验证码识别工具可自动求解；必须验证服务端是否真校验。
• "已测了注册短信 → 跳过密码找回" — 错。每个通知触达点（注册 / 找回 / 重发 / 邀请 / 订阅 / 偏好确认）都是独立 sink，必须按端点账本逐个测。
• "看起来限流到 1 分钟 1 次 → 安全" — 错。同一用户限流不能防"对不同目标用户分别请求"；需测每用户/每 IP/每目标多维度，并验证多维度间是否互通。
• "已在子系统 A 测了 → B 假定同样" — 错。跨子系统的通知模块独立配置，必须按子系统独立结账。
• "OTP 长 6 位 → 难暴破" — 错。在无速率限制的情况下，6 位 OTP 在 1 分钟内可枚举完，且可能存在重放窗口或并发竞态。

反例义务（必须遵守）

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

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

• 测过的通知触达候选端点完整清单（按 sink 语义枚举：所有"用户输入触发服务端向外部通道下发通知"的端点；含注册 OTP / 密码找回 / 重发 / 绑定校验 / 邀请 / 订阅确认 / 推送等全部触发线索类别）
• 每个端点测过的反滥用维度（单目标连续 / 冷却窗口绕过 / 验证码服务端强制 / 多维限流 / 多目标轮换 / 来源伪造 / 目标归一化变体）
• 每个端点的响应证据（基线响应 / 攻击响应 / 真实下发证据：流水号 / 自有目标收件确认）

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

特别警示：只测了"注册短信"而未覆盖"密码找回邮件 / 邀请同事 / 偏好确认"等其他触达入口，不能下"全站无通知滥用"结论。

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

通用闭环口径见同根目录 common/closure-verification.md（技能表 path 列同一抽取根下，需要时 read_file 读取）。核心：结论须形成「输入 → 处理 → 真实危害 → 可复核证据」完整证据链；仅凭接口返回 success 等中间信号最多判 suspected，证明实际触发了超额或未授权的真实通知下发才判 confirmed。

实际效果验证方向（必须说明真实发送影响）

• 服务端真实创建了发送任务、消息流水、队列记录或额度消耗
• 自有测试手机号/邮箱真实收到通知，或后台发送记录/审计日志可证明已发
• 限流/挑战绕过后，真实发送能力被恢复，而不是只有接口返回成功
• 若只能证明"接口返回成功"，但未证明真实发送、额度消耗或风控失效，不能给 confirmed

判定标准

现象	判定
在预算内对单/多目标形成真实通知下发，未触发有效冷却、挑战或多维限流；或绕过单一维度后真实发送能力恢复	confirmed
接口返回成功 / 文案变化提示限流缺口，但未取得真实下发证据（无流水/无收件）	suspected
服务端真正强制冷却 + 多维限流 + 服务端校验的挑战，且预算内难以触发真实超额下发	not vulnerable
只测了部分子系统 / 部分通知端点 / 部分维度变体	partial-coverage（不得宣称 safe）

修复建议

• 对通知触达链路接入多维风控：按 user / IP / target / session / scene 多维度同时计数并取严
• 强制服务端校验的人机挑战（验证码 / 行为风控 / 设备指纹），并对挑战凭证做防重放
• 引入"每目标地址"独立额度 + 接口级 / 账号级总量上限，避免多目标轮换耗尽通道
• 对来源识别链做可信化处理：明确网关注入字段，禁止直接信任 X-Forwarded-For 等可伪造头
• 对目标参数做标准化（手机号去格式 / 邮箱小写去空白）后再参与限流键计算
• 对外发通道接入异常发送告警与自动熔断