网站测试安全规则
定位：一套通用、负责任、最小影响的网站 / Web 应用安全测试（授权渗透测试）规则与检查清单。 适用范围：任何已获得明确授权的目标。本规则不绑定任何具体站点、账号或密钥。 核心精神：在授权范围内尽可能全面地发现问题，同时绝不破坏目标、最小化痕迹、测完必还原、规范留痕。
🌐 多语言 / Localization：本文件是默认语言 中文（
zh-CN）。其他语言版本见locales/<语言代码>/（如英文locales/en/SKILL.md）。切换语言：设置环境变量MOWEN_LANG=en或在项目 / skill 目录放lang文件（内容en）后读取对应语言文件。结构说明见locales/README.md。
何时使用（When to Use）
🔒 授权门禁（默认开启、可验证）：加载本 skill 后、发起任何测试前，必须先验证授权（默认要求项目提供
AUTHORIZATION.json授权证据，校验目标白名单 + 有效期；无证据则要求一次性交互确认）。仅在项目显式放置mowenfalse标记时才可跳过验证（见「零、前置条件」）。对未授权目标一律禁止测试。
符合以下任一场景时加载本 skill：
- 用户明确要求"对某某网站做安全测试 / 渗透测试 / 漏洞扫描 / 安全评估"
- 用户提到"安全测试规则""最小影响测试""隐蔽测试""漏洞复查""去重反馈"等关键词
- 用户希望对某个 Web 目标做授权范围内的漏洞验证（注入、XSS、越权、逻辑漏洞等）
何时不使用（When NOT to Use）
- 目标未经授权：没有授权就要求测试某网站 → 必须拒绝，先确认授权
- 用户只是想"看看网站功能 / 爬取公开数据 / 做正常业务操作"，不涉及安全测试
- 用户要求对他人账号做未授权的越权操作、或要求真正破坏 / 拖库 / 留后门
零、前置条件：授权确认（最高优先级）
任何测试动作开始前，必须先确认授权。没有授权，一切免谈。
授权门禁（默认开启：主用签名验证，其余为备选）
门禁不是"嘴上说说"。默认走主路径：非对称签名授权令牌（最强防冒用）。其余机制（清单文件 / 交互确认 / mowenfalse）作为备选降级路径。任何路径不通过都阻断；对未授权目标一律禁止。
主路径（推荐）：签名授权令牌
授权方用私钥对"授权声明"签名，项目放置带签名与公钥标识的 AUTHORIZATION.json；skill 在测试前用对应公钥验签。防冒用、防篡改最强。
AUTHORIZATION.json（模板见 references/authorization_template.json）含：
- 声明字段：
authorized_by/issued_at/valid_from/valid_until/targets[]/allowed_methods[]/scope_note/scope{}/key_id/nonce scope{}：明确测试范围，含in_scope[]（显式目标 / 路径前缀）、internal_ranges[]（内网 CIDR / 主机，如10.0.0.0/8、http://10.0.0.5:8080）、include_internal（是否含内网）、out_of_scope[]（显式排除项）、accounts[]（授权测试账号）signed_payload：被签名的规范化字符串（由scripts/sign_auth.sh生成，验签时直接拿来验）signature：对signed_payload的 RSA-SHA256 签名（base64）
放行前逐项校验：
| 校验项 | 做法 | 不通过时 |
|---|---|---|
| 公钥可信 | 按 key_id 在受信公钥目录（references/authorized_pubkeys/ 或 auth.pubkeys）找到对应公钥 |
阻断，未知 key_id |
| 验签通过 | openssl dgst -sha256 -verify <pub> -signature <sig> <(printf '%s' signed_payload) 须 Verified OK |
阻断，签名无效 / 被篡改 |
| 目标在授权范围内 | 本次目标满足以下任一：① 域名 ∈ targets（支持子域匹配）；② 命中 scope.in_scope（含路径前缀）；③ scope.include_internal=true 且主机 IP / 域名落在 scope.internal_ranges（支持 CIDR / 主机 / URL 匹配） |
阻断，越界目标 |
| 不在排除项 | 本次目标不命中 scope.out_of_scope（若填写） |
阻断，落在显式排除范围 |
| 时间窗有效 | 当前时间在 [valid_from, valid_until] 内 |
阻断，授权已过期 |
| 方法在许可内 | 本次方法 ∈ allowed_methods（若填写） |
阻断，越权方法 |
| 账号在许可内 | 使用账号 ∈ scope.accounts（若填写） |
阻断，未授权账号 |
| 破坏性操作授权 | 若动作属破坏性（DELETE / DROP / 覆盖写 / 批量修改 / 重置等），须 scope.destructive.allowed=true 且目标命中 scope.destructive.items；否则阻断 |
阻断，破坏性操作未显式授权 |
全部通过 → 放行，报告中记录"签名授权 / 授权人 / 有效期 / key_id / 范围摘要（含是否含内网）"。
内网测试：只要
scope.include_internal=true且目标落在scope.internal_ranges内，即视为已授权内网测试；未显式声明内网范围时，默认只允许外网授权域名，内网一律阻断。内网测试同样遵守最小影响、禁测项（A1）、数据最小化（A2）等全部规则。
生成密钥与签名见
scripts/sign_auth.sh；受信公钥管理见references/authorized_pubkeys/README.md。
备选 A：授权清单文件（无签名，弱一级）
不强制签名时，可仅用 AUTHORIZATION.json 的声明字段做白名单 + 有效期校验（不含验签）。仍比无证据强，但无法防冒用 / 篡改，仅作降级备选。
备选 B：交互式一次性确认（无清单时）
若项目未放授权清单，门禁不会静默放行，而是要求一次性交互确认：agent 展示即将测试的 target + 方法 + 拟测试时间窗，待用户显式输入确认短语（如 我确认已获授权）后才放行。确认仅本次会话有效、不持久化。
备选 C：项目级逃生口（关闭验证，分两级）
逃生口是"已知风险、主动关闭校验"的开关，不是授权本身。
- 非破坏性逃生口
mowenfalse：若项目已明确授权、希望跳过授权验证（仅用于非破坏性测试），在本项目该 skill 目录创建auth.disable，内容写入mowenfalse（或设环境变量MOWEN_AUTH_OVERRIDE=mowenfalse）。检测到即跳过授权验证；仍须遵守范围约束（不得跳出授权范围，见规则 23）。 - 破坏性逃生口
mowenbrokentrue：破坏性操作（规则 22）默认须显式授权 + 先备份。auth.disable写入mowenbrokentrue（或环境变量MOWEN_AUTH_OVERRIDE=mowenbrokentrue）可跳过破坏性操作的显式授权要求（不用scope.destructive.allowed=true也能放行破坏性动作）。注意：mowenbrokentrue只能跳过授权、不能跳过备份——无论是否开启，破坏性动作执行前都必须先做可恢复备份（见规则 22、A5），备份不得豁免。注意：mowenbrokentrue不等同于mowenfalse——它不关闭授权验证；若同时想关闭授权验证，需另置mowenfalse（两者可并存于文件，一行一个）。 - 关闭后仍需留痕：报告中标注"授权门禁已关闭（mowenfalse / mowenbrokentrue）"，并重申"仅用于已授权目标"。
- ⚠️ 逃生口仅为流程便利，不代表可以测试未授权目标、也不等于可无备份乱破坏。无论是否开启，对未授权目标的测试一律禁止；破坏性操作即便开了
mowenbrokentrue，必须先备份（备份不可跳过），仍受范围约束（见规则 22、规则 23）。
备选 D（可选增强）：多层组合
将主路径与备选叠加：签名令牌 + 清单白名单 + 文件 SHA256 完整性 + 随仓库提交审计（A3）。最严格、可审计，但配置与维护成本最高，按团队需要启用。
- 明确授权：确认本次测试已获得目标所有者 / 授权方的允许，且范围（域名、账号、方法）清晰。
- 不破坏：测试以"发现问题"为目的，不破坏目标系统本身（不删库、不拖库、不植入后门、不造成不可用）。
- 凭据不硬编码：测试用的 token / 账号 / API Key 由授权方提供，存于环境变量或本地配置，绝不写死在本 skill 内，也绝不提交到版本库（详见
references/auth_notes.md）。 - 范围受控：只测授权域名及其直接 API 端点，不主动扫描、攻击第三方或外部服务器。
一、核心规则（19 条，通用化）
1. 授权
测试必须获得明确授权；不破坏目标系统本身；禁止对未授权目标测试。
2. 账号
仅使用授权方指定的测试账号；不冒用、不测试他人真实账号；记录所用账号标识。
3. 方法
在授权与最小影响前提下，各类测试手法（注入、XSS、越权、逻辑漏洞等）均可使用。
4. 工具 / Skill
允许按需引入新工具或 skill，但引入后需先做安全与行为检测（确认无恶意、无破坏性脚本再使用）。
5. 还原
每次测试后记录并还原所有改动（数据、配置、文件）。
6. 无法还原
无法还原的改动必须标记并明确告知授权方。
7. 验证
每次修改后，用"无认证 / 无特权"的裸请求验证是否真实生效（排除缓存与前端假象）。
8. 去重
7 天内相同问题不重复反馈（先看历史报告，见规则 14）。
9. 报告
只报告新问题；文件名带时间；保存到约定的报告目录（见规则 13）。
10. 密钥
先验证密钥（API Key / Token）可用性：可用则保留，不可用则替换或提示授权方。
11. 基线记录
测试前先记录目标数据的原始值，测试后对比确认是否真有变化。
12. 隐蔽测试（最小化痕迹）
测试必须最小化痕迹：
- 禁止批量触发外部副作用（邮件 / 短信 / 推送），单次最多调 1–2 次
- 不修改生产数据，用临时值，测完立即还原
- 不留测试痕迹，如必须创建则测完删除
- 不触发告警 / 频率限制 / 异常通知
- 请求频率合理，不刷接口
- 不可逆操作（已发出的邮件 / 通知）仅在确认必要时调用 1 次，并在报告中记录
- 测试范围限于授权目标域名及其直接 API 端点，不主动扫描 / 攻击第三方或外部服务器
13. 完成后总结报告
- 保存到可自定义的报告目录（默认
reports/security/，可被项目配置report.path/report_dir或调用参数覆盖，见规则 20） - 文件名格式：
YYYY-MM-DD_findings.md - 内容含：测试时间、目标、漏洞详情（编号 + 名称 + 等级 + 描述 + PoC + 修复建议）、后续方向
- 同一天多次测试追加到同一文件
- 生成后通过文件分享 / 发送工具发给授权方
- 可上传到约定的归档位置（如授权的内部存储），只保留最新一份
14. 方法不重样
同一目标 7 天内不重复已用攻击向量：
- 测试前先读最近报告，跳过已用方法
- 已用过的向量（SQL 注入 / XSS / 越权绕过等）7 天内不再重复
- 优先尝试上次报告"后续方向"中提到的新方法
- 不同目标的方法记录不共享，各建子文件夹
15. 前端资源变更跟踪
每次测试前比对前端 JS 资源名；若变更，则提取新 chunk 分析其中暴露的新端点。
16. 认证回退检测
每次测试重新验证已知端点的认证状态是否变化（需认证 → 无需认证 = 认证回退，必须报告）。
17. 用户资源上传测试先备份
涉及头像 / 封面 / 附件等用户资源的上传测试，先获取原值保存，测完恢复；无恢复机制的控制调用量 ≤ 3 次。
18. 不可逆写入端点控制
无认证即可写入数据的端点，测试调用 ≤ 3 次，只写无害数据，并在报告中记录。
19. 漏洞复查周期
- 7 天后首次复查 → 1 个月后 → 半年后 → 1 年后 → 不再复查
- 复查只验证是否修复，不做新攻击
- 复查结果追加到报告，注明复查日期与结果
20. 操作全程留痕 + 报告位置可自定义
- 每次测试操作都必须记录：在报告内维护一份「操作日志」，逐条记录每一次测试动作的时间戳、目标/端点、方法、请求摘要、响应关键结果、是否符合预期、是否产生副作用。不得只在脑子里记、事后凭记忆补写。
- 记录粒度：一个独立测试动作（一次请求 / 一组关联请求 / 一次状态变更尝试）对应一条日志；批量或循环动作按「一次动作 + 次数 + 结果汇总」记录，避免刷屏。
- 报告位置可自定义：报告保存目录不写死，由用户 / 项目配置指定（覆盖默认
reports/security/）。配置优先级：命令行 / 调用参数指定 > 项目内report.path配置 > 默认reports/security/<目标名>/。AUTHORIZATION.json或项目配置里的report_dir也可作为来源。自定义位置必须是授权方可控的存储（不落第三方公开位置）。 - 归档联动：按规则 13 生成的报告，可上传到自定义报告位置或约定归档处；自定义位置存在时优先用自定义位置。
21. 授权须明确范围（含内网须显式授权）
- 范围必须写清楚：授权证据（
AUTHORIZATION.json）须通过scope字段显式声明测试范围——in_scope（目标 / 路径前缀）、out_of_scope（排除项）、accounts（授权账号）。范围模糊或缺失时，门禁应要求补充，不默认放行。 - 内网测试须显式授权：内网 / 非公网目标（内网 IP、CIDR、内网域名 / 端口）只有在
scope.include_internal=true且其落在scope.internal_ranges内时才允许测试；未声明内网范围则只允许外网授权域名，内网一律阻断。 - 内网测试同样遵守全部规则：最小影响（规则 12）、禁测项（A1）、数据最小化与脱敏（A2）、操作留痕（规则 20）、测后还原（规则 5）。
22. 破坏性操作：须显式授权 + 测试前先备份 + 提前警告
- 破坏性操作须显式授权：DELETE / DROP / 覆盖写 / 批量修改 / 重置 / 大批量状态变更等可能造成不可逆后果的动作，默认禁止。只有在
AUTHORIZATION.json的scope.destructive.allowed=true且其逐项列出本次目标（命中scope.destructive.items）时才允许，不能靠笼统授权蒙混过关。 - 执行前先备份（任何开关均不可豁免）：对任何将被破坏性动作触及的资源（数据行、文件、配置、记录），必须先做备份并确认可恢复，把备份位置写入报告；
scope.destructive.backup_required=true（默认）时未备份不得执行。注意：此备份要求不受mowenbrokentrue影响——mowenbrokentrue只跳过破坏性显式授权，绝不豁免备份，未备份一律不得执行。 - 提前警告：在测试前检查清单与报告中明确标注「本次含破坏性操作、影响范围、不可逆风险」，并确认授权方已知晓；误触或范围超出时立即按 B3 停止并通知。
- 破坏性操作的备份与恢复流程见
references/backup_notes.md。 - 破坏性逃生口
mowenbrokentrue：若auth.disable含mowenbrokentrue（或环境变量MOWEN_AUTH_OVERRIDE=mowenbrokentrue），可跳过本规则的"显式授权 + 先备份"强制要求（破坏性测试一键通）。注意：① 仅关闭破坏性格闸，不关闭授权验证（mowenfalse另管）；② 仍须遵守范围约束（规则 23，不跳出授权范围）；③ 报告中标注"破坏性门禁已关闭（mowenbrokentrue）"，并重申强烈建议先备份。
23. 禁止越界 / 跳出授权范围
- 出站目标必须命中授权范围：任何测试请求的目标（域名 / IP / 端口 / 路径）须命中
targets/scope.in_scope/ 内网internal_ranges，不得向授权范围外主动发起测试请求（见规则 96、门禁校验）。 - SSRF 不得借目标打第三方：SSRF 类 PoC 仅用于验证目标服务器自身的越权访问 / 内网探测漏洞，不得将目标服务器当作跳板去访问、攻击授权范围外的外部第三方或真实内网系统；只验证漏洞本身，不拿第三方当靶子（见 D6）。
- 不跟随跨域重定向出站：测试工具不得自动跟随跨域 302 / 307 重定向跳转到授权范围外的站点并发起测试；跨域跳转须先确认在授权范围内。
- 资产收集不越界：子域枚举 / 端口探测 / 资产收集（如 amass / subfinder / httpx）产出的、超出授权范围的目标，不对其发起测试。
- 与测试目标相关的外站尝试也须授权：目标所集成的第三方（OAuth / SSO 提供方、支付 / 短信 / 邮件服务商、外部 API、Webhook / 回调接收方、CDN 等）虽"与测试网站有关"，但仍是独立的站外系统。对其发起任何测试请求，须取得该外站自身的授权；若无法取得，须在
auth.disable放置mowenwaitrue（或环境变量MOWEN_AUTH_OVERRIDE=mowenwaitrue）显式确认"已具备 / 已等待对应外站授权"后方可尝试。未获该外站授权且未置mowenwaitrue的外站关联尝试一律禁止。 - 备选路径下同样适用：即便门禁走备选 B（交互确认）或备选 C（
mowenfalse关闭验证），仍须逐目标确认在授权范围内，否则禁止（见门禁校验与本条）。
二、补充规则
- 每次开始测试前先确认最新凭据：不用旧凭据直接尝试登录。
- 登录失败 1 次就停：先确认凭据是否变更，不连续尝试。
- 默认目标：用户未指定其他目标时，使用约定的默认目标（若已配置）；否则必须先与目标授权方确认。
- IDOR 删除类测试安全流程：
- 先测不存在的 ID，看返回格式（404 vs 403 vs 200）
- 再决定是否测真实他人 ID
- 优先测 GET / HEAD 的 403 响应确认权限拒绝，不实际执行 DELETE 到成功
- 模块覆盖要全面：不同模块同类端点防护可能不一致，不能假设防护一致。
- 业务判断原则：无付费 / 无敏感资产的端点不算漏洞，公开内容无访问限制可能是设计决策。报告区分 "技术漏洞" 与 "业务可接受"。
- 规则 24 · 定级前核对前端界面：API 返回敏感字段 ≠ 漏洞。发现"无认证返回 X"类问题，先找前端对应页面确认 X 是否本就公开展示（打赏榜金额 / 排行榜数值 / 社区公开内容等）——展示中即属设计映射，改判"业务可接受"，未展示才进入定级。只测 API 不看界面，会把产品刻意公开的数据误报为漏洞。
- 规则 25 · 锁定 / 风控响应先想 IP 维度："账号被锁"是错误表述——登录锁定多为 IP + 账号绑定计数。触发锁定响应时先确认维度，再评估影响面（本人 IP 登录是否受影响、token 是否可用），仅账号级全局锁定才升级事件。IP 维度锁定天然免疫"账号 DoS"（攻击者只锁自己的组合），勿误报。故意失败类测试（错密码 / 错验证码）前必须确认该 IP 组合的计数存量，单次试探即停。
- 规则 26 · 无认证泄露"公开性三问"：发现无认证返回数据 X 时依次问：① X 在公开页面 / 接口是否已有？② 返回字段是否超出公开集（多了用户名 / 认证状态 / IP 等）？③ 是否把单查变批量枚举（聚合放大）？三问无增量 → 业务可接受；②有增量字段 → 定级；③批量枚举 → 至少 LOW（可附速率限制建议）。
- 规则 27 · 存储型 XSS 测试残留物管理：注入测试前先确认目标模块有无删除端点（无删除功能的产品，测试数据将永久残留）；优先选"待审核 / 不可见"状态的创建路径（status=0 不进公开列表）；测完立即删可删部分，不可删部分书面记录（路径 / ID）移交目标方清理。
- 规则 28 · 上传内容校验三档判定：无校验（任意内容入库）/ 浅校验（仅格式头魔数如 ID3、PNG 头）/ 真校验（重编码 / 完整解析）。判定法：a) 纯文本+正确格式头，b) 真实格式头+注入代码——a 过即浅校验（可绕），b 拒 a 过也是浅校验。定级必做执行面验证：
文件.png/x.php（pathinfo 解析）、直接改.php后缀访问——执行面为零时维持"材料入库"级（MEDIUM~LOW），有执行面升 HIGH。修复建议：服务端重编码（GD/Imagick 重画图像、ffmpeg 转码音频）可连带清除注入内容。 - 规则 29 · 滑块 / 行为验证码五层测试矩阵：L1 固定值+无轨迹（测位置校验）→ L2 正确位置+无轨迹 → L3 正确位置+极简轨迹（测轨迹校验）→ L4 正确位置+机器伪造渐进轨迹（10-12 点、Y 轴抖动、总时长 >800ms）→ L5 答案获取方式审查。L5 是一票否决项：响应中下发正确位置（如明文 target_position）时，无论轨迹校验多强，纯脚本 100% 绕过必然成立，定 HIGH；修复 = 删除该响应字段（前端需要则改加密 / 切片下发）。配套检查：captcha token 重放应被拒（单次消费）、verify_token 跨端点复用应被拒。
- 规则 30 · 编辑端点归属校验顺序盲区：
edit类端点字段校验先于归属校验时，缺字段返回 400，无法无害确认归属检查是否存在——用只读旁证（detail-for-edit 类 403）佐证，edit 本体标"待确认"建议目标方代码自查；绝不通过"补全字段试探他人资源"来验证（有改坏他人数据风险）。原则："验证完整性"永远让位于"不破坏他人数据"。 - 横向对照法：同类数据跨模块对照（如评论 vs 帖子的 ip 字段），单模块过度返回 = 防护不一致实锤，修复 = 对齐最严标准；不一致本身即强证据。
- 报告称呼规范：授权人身份称呼要准确（站长 / 管理员 / 安全负责人因站点而异），报告发出前核对，身份错误会显得不专业且易混淆权责。
三、认证与登录流程（通用说明）
详见 references/auth_notes.md。要点：
- 凭据由授权方提供，建议存于环境变量 / 本地配置，绝不硬编码。
- 测试前先梳理目标的登录 / 验证码 / 认证流程，记录关键端点与参数名差异（例如：A 端点用
token，B 端点用captcha_token，务必区分）。 - 频率限制多为 IP + 账号 维度，非全局；测试 IP 被限不代表目标有漏洞。
四、记录时间戳规则
- 每次记录必须带"当前"时间戳：日常笔记、报告、错误记录、长期记忆、测试结果等所有记录。
- 记录前必须先获取真实当前时间（用时间工具 / 系统命令取当前时间，精确到秒），禁止凭记忆只填日期或估算时间。
- 格式（强制）：
YYYY-MM-DD HH:MM:SS（秒级，便于同一天内多条记录排序与追溯）。 - 不仅每日总结带时间，每条记录、每个发现、每次测试结果都要有具体的当前时间。
- 原因：方便追溯真实发现时间，避免把历史状态误当持续状态、避免同日多条记录无法排序。
五、错误记录机制
- 出错必记录：在约定错误记录目录（默认
errors/）新建记录文件。 - 命名格式：
YYYY-MM-DD_简短描述.md。 - 记录内容：错误描述、场景、原因、解决方案、预防措施。
- 遇事先翻记录：遇到类似问题先查错误记录目录。
六、报告格式（详见 references/report_template.md）
报告至少包含：
| 字段 | 说明 |
|---|---|
| 测试时间 | 带当前时间戳，精确到秒（规则 4） |
| 目标 | 域名 / 端点范围 |
| 操作日志 | 每次测试动作的逐条记录：时间 / 端点 / 方法 / 请求摘要 / 响应结果 / 副作用（规则 20，强制） |
| 漏洞详情 | 编号 + 名称 + 等级 + 描述 + PoC + 修复建议 |
| 后续方向 | 下次可尝试的新方法（供规则 14 使用） |
- 报告保存路径可自定义：默认
reports/security/<目标名>/，可通过项目配置report.path/report_dir或调用参数覆盖（见规则 20）。文件名仍为YYYY-MM-DD_findings.md，同目标同日追加到同一文件。 - 报告模板见
references/report_template.md，其中已包含「操作日志」与「报告位置配置」段。
漏洞等级建议（可调整）：
| 等级 | 含义 |
|---|---|
| 严重 / Critical | 可直接接管、拖库、远程代码执行 |
| 高危 / High | 越权读写、敏感信息泄露 |
| 中危 / Medium | 需配合条件的利用、部分防护绕过 |
| 低危 / Low | 信息泄露、配置瑕疵 |
| 信息 / Info | 加固建议、非漏洞 |
七、通用原则
- 一个工具不行就换，不要死磕：反复出错时果断切换替代方案。
- 时间校准（取真实当前时间）：每次开始记录 / 生成报告 / 写错误前，先用时间工具获取当前时间戳（精确到秒），再写入，遵守规则 4。禁止凭记忆填时间。
八、快速参考（检查清单）
测试前
- 🔒 授权门禁已验证：签名令牌验签通过（或走备选：清单白名单 / 交互确认 / mowenfalse），目标在白名单且未过期（零）
- 确认禁测项边界：禁 DoS / 社工 / 高峰压测（A1）
- 🔒 含破坏性操作？须
scope.destructive.allowed=true且目标逐项列出，否则禁止（A5、规则 22） - 破坏性操作前已完成相关资源备份并记录备份位置（规则 22、A5）
- 确认测试时段 / 变更窗口（A4）；确认合规边界（A3）
- 确认最新凭据（不沿用旧凭据）
- 故意失败类测试（错密码 / 错验证码）先确认该 IP 组合的计数存量，单次试探即停（规则 25）
- 读取该目标最近报告，识别 7 天内已用向量（规则 8、14）
- 记录目标数据原始值（规则 11、基线）
- 比对前端 JS 资源，识别新端点（规则 15）
- 获取当前时间戳（精确到秒）并记录，作为本次测试基线时间（规则 4）
- 确定报告保存路径（默认 / 自定义
report.path/report_dir，规则 20）
测试中
- 仅用授权测试账号（规则 2）
- 控制频率（≤ 2 req/s），不刷接口、不触发告警（规则 12、C4）
- 外部副作用单次 ≤ 1–2 次（规则 12）
- 用临时值，不污染生产数据；敏感数据不导出、报告中脱敏（规则 12、A2）
- 已用向量 7 天内不重复（规则 14）
- 认证回退检测（规则 16）
- 用户资源先备份（规则 17）；不可逆写入 ≤ 3 次（规则 18）
- 破坏性操作前再确认备份可用，执行时单步进行并即时记录（规则 22、A5）
- 留存请求 / 响应证据（B1）；非幂等请求谨慎（C2）；CSRF / CORS 专项（C3）
- 每次操作即时写入「操作日志」（时间 / 端点 / 方法 / 摘要 / 结果 / 副作用）（规则 20）
- 全部出站目标均在授权范围内，不跟随跨域重定向到站外（规则 23）
测试后
- 还原所有改动（规则 5）；破坏性操作须从备份恢复并验证（规则 22）
- 无法还原则标记告知（规则 6）
- 裸请求验证真实生效（规则 7）
- 只报告新问题，去重（规则 8、9）
- 每项定级前已核对前端界面是否公开展示同款数据（规则 24）；无认证泄露已过"公开性三问"（规则 26）
- 存储型注入测试数据已清理；无删除端点的残留物已书面记录移交（规则 27）
- 生成
YYYY-MM-DD_findings.md并追加，「操作日志」完整（规则 13、20） - 🔒 高危（Critical / High）即时上报（B2）；误触 outage / 大量真实数据立即停止并通知（B3）
- 报告仅发给授权接收人（B4）；区分自研 / 供应链漏洞（C1）
- 出错已记录到 errors/（规则 5）
九、扩展规则（A–C 共 12 条）
🔒 标记 = 与"授权 / 合规边界"直接相关，测试前必须向授权方确认范围。
A 类 · 合规与边界
- A1 禁测项 / 范围边界 🔒：明确禁止 DoS / 资源耗尽测试、对真实员工的社工、生产高峰时段压测，除非授权方单独授权。破坏性操作见 A5。
- A2 敏感数据最小化与脱敏：证明漏洞所需之外的用户 PII / 业务数据不导出、不留存；报告中的 PII 必须脱敏。
- A3 合规与法律边界 🔒：测试须遵守适用法律法规（如网络安全法），并保留书面授权证据。
- A4 测试时段 / 变更窗口：在授权方约定的低峰期 / 维护窗测试，避免影响业务。
- A5 破坏性操作须显式授权并先备份 🔒：DELETE / DROP / 覆盖写 / 批量修改 / 重置等破坏性动作，默认禁止；须
scope.destructive.allowed=true且逐项列出目标，执行前必须对相关资源做可恢复备份并写报告，且提前向授权方标注不可逆风险（详见规则 22、参考文献references/backup_notes.md）。
B 类 · 证据与上报
- B1 证据留存：每个发现保留可复现的 HTTP 请求 / 响应证据（curl / 抓包），不只写结论。
- B2 高危即时上报：Critical / High 不积压到日报，发现即通知授权方。
- B3 停止 / 熔断条件：一旦误触 outage、或无意访问到大量真实用户数据，立即停止并通知授权方。
- B4 报告分发最小化：报告只发给授权接收人，不外传。
C 类 · 技术补充
- C1 依赖 / 供应链标注：区分"自研代码漏洞"与"第三方库版本漏洞"，后者给出 CVE / 升级建议。
- C2 非幂等请求谨慎：POST / PUT / DELETE 不在循环 / 重试里乱发，避免重复副作用。
- C3 CSRF / CORS / 同源专项：把这类常见遗漏项列入必测清单。
- C4 速率 / 并发具体上限：给出默认上限（如 ≤ 2 req/s），把"频率合理"量化。
十、专项测试清单（新增推荐规则，D 类）
在核心 19 条 + 扩展 12 条之外，补充以下常见专项。均受"授权 / 最小影响 / 隐蔽"约束。
D 类 · 专项技术
- D1 令牌与 JWT 弱点：none 算法、弱密钥 / 可爆破密钥、过期不校验、刷新令牌未绑定会话、密钥硬编码。
- D2 会话与认证：会话固定、并发登录无限制、登出后令牌仍有效、Remember-me 长期有效、密码重置令牌可预测 / 可复用。
- D3 业务逻辑 / 并发：竞态条件（Race Condition，如并发领券 / 转账 / 下单）、负数 / 超额、重复提交、流程绕过（跳过校验步骤）。
- D4 越权组合：垂直 + 水平越权组合、IDOR 批量遍历、UUID / 序号可枚举、功能级越权（改角色参数）。
- D5 注入扩展：命令注入、XXE、SSTI、反序列化、LDAP / NoSQL 注入（不限于 SQL / XSS）。
- D6 SSRF：内网 / 元数据探测（如
169.254.169.254）、DNS rebinding、协议穿透（gopher / file）；仅探测，不读取大量敏感数据。SSRF PoC 不得指向授权范围外的外部第三方系统——不得借目标服务器作为攻击跳板去打站外 / 真实内网第三方。 - D7 文件上传：类型 / 内容绕过（webshell）、路径遍历、解压炸弹、覆盖已存在文件；用无害样本，测完删。
- D8 信息泄露：
.git/.env/ 备份暴露、Swagger / Docs 未授权、详细报错 / 堆栈、目录列举。 - D9 配置与传输：安全响应头缺失（CSP / HSTS / X-Frame-Options）、Cookie 属性（Secure / HttpOnly / SameSite）、TLS 弱配置、CORS 误配。
- D10 供应链 / 组件：组件指纹识别 + 已知 CVE、调试端点暴露（actuator / phpinfo）、依赖漏洞。
十一、推荐工具与方法（仅记名称）
仅记录名称；工具落地前仍须遵守本 skill 全部规则与授权门禁。优先"下载后在本地分析 / 被动扫描"类工具，避免对目标直接发起破坏性请求。
已检查安全的本地 Skill（可用于测试流程，无破坏性 / 外泄行为）
browser-automation—— 浏览器自动化（查看 / 截图 / 表单），被动为主。playwright-cli—— 浏览器自动化（更强交互 / 网络 mock）。github-connector—— 仅用于克隆 / 扫描自有或已授权仓库（含 Token 安全规范，禁止打印凭据）。
推荐的安全开源工具（名称）
- OWASP ZAP、Nuclei、wapiti、Nikto、testssl.sh
- amass、subfinder、httpx（资产收集，被动优先）
- ffuf、Arjun（参数发现 / Fuzz，需授权且限速）
- sqlmap（仅授权、谨慎，禁止拖库）
- Gitleaks、trufflehog（密钥泄露扫描，对自身代码）
- Trivy、dependency-check（依赖 / CVE 扫描）
推荐方法（名称）
- 被动信息收集、主动探测、模糊测试（Fuzzing）、代码审计、威胁建模、业务逻辑测试、配置合规审计、依赖 / 组件扫描（CVE）、手动验证（PoC）、竞态测试、权限矩阵测试、资产收集与指纹识别。
参考文件
README.md—— 项目说明、安装、用法、授权门禁（三级开关速查）、规则索引与开源相关（详细门禁与规则见正文）references/report_template.md—— 完整报告模板（含时间戳、漏洞字段、后续方向）references/auth_notes.md—— 通用认证 / 凭据管理 / 登录流程说明references/authorization_template.json—— 授权证据文件模板（目标白名单 + 有效期 + 签名令牌字段 +scope.destructive）references/backup_notes.md—— 破坏性操作备份流程、提前警告与备份记录模板（规则 22、A5）references/authorized_pubkeys/README.md—— 受信公钥管理说明scripts/sign_auth.sh—— 授权声明非对称签名工具（RSA-SHA256）