src-workflow

name	src-workflow
description	通用企业 SRC 工作流技能。只要任务涉及企业 SRC、授权范围确认、测试规则梳理、资产盘点、被动信息收集、空间测绘结果整理、导出归类、漏洞挖掘准备，或在授权范围内推进实际挖掘与记录，就应优先使用这个技能。它适合多厂商、多项目、长期复用的 SRC 场景，尤其适合需要先确认范围与规则，再结合官方资料、被动来源、导出文件和本地笔记推进工作的任务。
compatibility	{"tools":"Read, Write, Edit, Glob, Grep, Bash, Skill, WebSearch, WebFetch"}

src-workflow

这个技能用于处理 企业 SRC 场景下的通用工作流：

• 确认授权范围与测试规则
• 梳理资产、业务线和公开入口
• 利用官方资料和被动来源补充线索
• 处理空间测绘平台或其他外部来源的导出文件
• 为后续漏洞挖掘、记录、汇总和持续跟进建立稳定底稿

核心边界只有一条：仅在明确授权范围内执行。

额外安全铁律

在任何测试、验证、复现或挖掘过程中，默认只做低影响、可回退、非破坏性操作。

绝对不要擅自执行这类动作：

• 删除、修改、覆盖、提交、确认、解绑、下单、支付、发货、取消、上传、清空、重置
• 批量写入、批量调用、批量触发
• 任何可能改变真实业务数据、账号状态、订单状态、资金状态、库存状态、权限状态的动作
• 任何可能影响业务可用性、稳定性、完整性的动作

如果验证漏洞需要触发上述任一敏感操作，必须先停下并明确向用户汇报：

• 要做什么操作
• 为什么需要做
• 可能影响什么
• 有哪些更低影响替代方案

在用户明确确认前，不得继续执行。

如果执行过程中出现以下情况，也必须立刻汇报，而不是自行推进：

• 怀疑某一步会产生真实写操作或状态变化
• 怀疑会接触真实隐私数据、资金数据、订单数据、内部管理数据
• 怀疑会影响生产环境用户、司机、商家、企业客户或后台人员
• 发现需要登录后提交、保存、删除、修改、审批、调用敏感接口才能继续验证

默认优先选择：只读、最小化、单次、可观察、不改变状态的验证路径。

一、什么时候用这个技能

当任务涉及以下任一场景时，应优先使用本技能：

• 企业 SRC 范围确认
• 测试规则、奖励规则、提交流程整理
• 资产盘点、业务归类、入口梳理
• 子域、站点、接口、App/H5、小程序、后台入口线索收集
• 被动信息源整理与交叉验证
• 空间测绘平台结果导出、下载、离线归类
• 授权范围内的漏洞挖掘准备
• 授权范围内的实际漏洞挖掘过程记录与信息整理
• 本地资产清单、作战表、笔记、报告模板的维护

不要把它理解成“只会信息收集”的技能。它覆盖的是 SRC 任务从准备、梳理、发现、分类到持续记录的整条工作链。

二、先建立上下文，不要直接开做

开始任务后，先检查当前项目里是否已经有总推进表 / 作战表。如果没有，应优先创建一份，再开始推进；如果已经有，就先更新它，再决定这轮做什么。

总推进表应按“平台 × 阶段”管理，不按零散发现管理。默认至少包含：平台、当前阶段、奖励/价值判断、竞争压力、验证成本、已确认入口、业务面进度、高价值目标、候选漏洞、报告草稿、下一步动作、阻塞项。

后续每完成一轮工作，都先写回总推进表，再写回资产底稿或其他专题文件。这样可以避免同时推进多个 SRC 时状态发散。

开始任务后，先读当前项目里已有的本地资料，再决定怎么推进。

优先查找并读取这些类型的文件：

• 活动规则
• SRC 范围说明
• 测试规范 / 评级标准
• 已有资产清单
• 历史笔记
• 导出摘要
• 报告模板
• 上一轮整理结果

目标不是“读得越多越好”，而是先回答这几个问题：

• 本次授权范围是什么
• 哪些资产明确在范围内，哪些只是线索
• 当前已有的资产树到哪里了
• 这一轮任务是补资产、做分类，还是直接推进漏洞挖掘

如果用户给了很少信息，也先从当前目录里的本地文档、说明文件、已有表格和笔记补上下文。

三、工作流总顺序

默认按这个顺序推进：

1. 确认授权范围与测试规则
2. 建立或更新当前项目的资产树
3. 从官方资料提取公开入口与业务映射
4. 结合被动来源补充线索
5. 必要时做导出、下载、离线分类
6. 输出待跟进目标和记录结果
7. 把关键信息写回本地资料

不要一上来就沉进某个平台的海量结果里。先把“范围、优先级、已有成果”看清楚，能减少很多无效工作。

四、先确认什么：范围、规则、边界

先从本地资料或官方资料中提炼出：

• 授权范围
• 不在范围内的内容
• 测试规则与限制
• 奖励、评级、提交流程
• 时间窗口
• 是否区分核心业务 / 一般业务 / 边缘业务

优先级不要只按截止时间排。默认综合这几个维度判断：

• 奖励强度（翻倍、等级系数、证书/积分价值）
• 竞争压力（热门项目是否更容易被其他白帽抢先）
• 验证成本（是否容易低影响复现、是否需要复杂前置条件）
• 业务价值（登录、支付、订单、后台、开放平台等是否集中）
• 用户明确偏好（如果用户指定先打哪家，应直接提高优先级）
• 截止时间（只作为一个维度，不应单独决定排序；只有接近截止时才显著加权）

这一阶段的输出应至少包括：

• 一份明确的范围摘要
• 一份优先级判断（写清为什么这样排）
• 一份需要谨慎对待的边界项列表

如果授权范围不清晰，不要主观扩展。先把它写成“待确认线索”，后续再结合官方映射补证据。

五、官方资料永远优先

在做被动收集或漏洞挖掘之前，先把官方资料过一遍。

优先看的页面或资料类型：

• 官方 SRC 首页
• 官方范围说明
• 公告 / 帮助中心 / FAQ
• 品牌官网
• 产品页 / 下载页 / 联系页
• 开放平台 / 开发者页面
• 登录页 / 注册页 / 后台入口线索
• 招聘页 / 合作页 / 服务页
• App 下载页 / H5 页面 / 小程序线索页

官方资料的价值在于：

• 确认业务归属
• 确认品牌和主域映射
• 找到正式入口
• 提供后续被动收集的关键词和种子域名

先用官方资料建立“入口树”，再补“暴露面树”。这比一上来只看空间测绘结果更稳。

六、什么时候用 web-access

凡是涉及网络访问、网页浏览、动态页面、登录态复用、导出操作、文件中心下载、页面交互，都应优先调用 web-access。

它适合承担这些任务：

• 打开并浏览官方站点 / SRC 站点
• 处理动态渲染页面
• 使用用户当前 Chrome 的登录态
• 操作空间测绘平台、文件中心、导出页面
• 浏览需要点击、翻页、展开、截图的页面

本技能负责“判断应该做什么、按什么顺序做、产出什么记录”，web-access 负责“浏览器里怎么实际操作”。

使用 web-access 前的原则

• 先检查它的依赖环境是否可用
• 优先用用户现有 Chrome 登录态，不额外污染环境
• 不要关闭用户原有 tab
• 操作完成后关闭自己创建的后台 tab

如果 CDP 或浏览器调试没连上，先处理环境问题，不要在失败状态下反复重试同一动作。

七、被动来源怎么组合

在官方资料之外，按需组合这些被动来源：

• 空间测绘平台
• 搜索引擎
• 证书透明度日志
• 官方页面里的 JS / HTML / 静态资源
• 公开品牌资料
• 公开下载页
• 公开招聘 / 帮助 / 开放平台资料
• 公开可见的导出数据或历史整理文件

这些来源的用途不同：

• 官方资料：确认映射和归属
• 空间测绘：发现公开暴露面
• 搜索引擎：补入口、标题、历史痕迹
• 证书透明度：补域名 / 子域名线索
• JS / HTML：补资源域、接口路径、站点结构线索

不要把任何单一来源当成最终真相。多个来源交叉验证后再决定写入哪一层清单。

八、空间测绘平台的通用用法

空间测绘平台适合作为第一层暴露面发现工具，但不要让它主导全部判断。

1. 先决定查询对象

优先围绕这些对象展开：

• 已确认授权的根域
• 官方映射到的品牌域
• 官方确认的业务域
• 已知正式入口相关域名

2. 先决定导出策略

不要总是一把梭全量导出。更推荐按用途分桶：

• 主 Web 入口
• 业务关键词入口
• API / 接口类入口
• 登录 / SSO / 后台类入口
• 预发 / 测试环境线索
• 静态 / 日志 / 监控 / 埋点线索

如果结果很多，先导第一轮样本，再让模型离线分类；不要把浏览器页面当成长期工作区。

3. 导出后不要停在“任务创建成功”

通用流程是：

1. 在平台里发起导出
2. 进入文件中心或导出记录页
3. 确认任务状态为已完成
4. 再点击下载
5. 去本地下载目录定位文件

“导出”与“下载”通常不是同一步，很多平台都会拆开。记得走完整条链路。

九、下载和导出文件怎么处理

1. 先定位文件

优先从常见下载目录或用户指定目录定位：

• Downloads
• 当前项目目录
• 用户明确提供的路径

优先用：

• Glob 找 *.xlsx / *.csv / *.json
• Bash 查看目录内容

2. 先看结构，再决定处理方式

不同格式适合不同策略：

xlsx

• 优先用现成库读取
• 如果环境里没有相关库，可用 Python 标准库把 xlsx 当 zip 包解析
• 先抽头部字段和样本行，不要先全量灌进上下文

csv

• 先看表头、编码、分隔符
• 再做去重、分类和统计

json

• 先看顶层结构
• 再抽目标字段
• 必要时转成更适合人工和模型阅读的摘要文件

3. 离线处理时至少抽这些字段

• host / domain
• url
• ip
• port
• title
• status
• service / protocol
• 组织 / ICP / 证书主体 / ASN 等归属线索
• 页面类型或响应类型线索
• 原始来源

4. 离线分类时必须补的标签

• 是否在授权范围内
• 正式 / 预发 / 测试 / 待确认
• Web / H5 / API / 静态 / 日志 / 监控 / 后台线索
• 业务归类
• 是否高价值入口
• 是否值得继续跟进

十、怎么做信息梳理和优先级判断

离线分类不是为了“看起来整齐”，而是为了让下一步挖掘更快。

优先标这些高价值线索：

• 登录 / SSO
• 账户与资料修改
• 订单 / 交易 / 支付
• 优惠券 / 积分 / 发票
• 司机端 / 用户端 / 商家端 / 企业端
• 开放平台 / 开发者入口
• 管理后台 / 内部系统公开入口
• API 网关 / 业务接口入口

同时要单独标出这些低确定性对象：

• 带 pre / stg / test / dev / uat / beta 的主机
• 仅显示默认页、错误页、欢迎页的主机
• 403 / 404 / 页面失效 / 占位页
• 无法确认业务归属的站点

这些不一定没价值，但应该进入“待复核”层，而不是直接当成核心目标。

十一、如何把信息写回本地资料

每完成一轮工作，都要把结果沉淀到本地，不然下一轮还会重复走一遍。

默认优先维护一份总推进表 / 作战表，按“平台 × 阶段”统一记录，而不是把状态散落在多份零散笔记里。

推荐至少包含这些列：

• 平台
• 当前阶段
• 奖励/价值判断
• 竞争压力判断
• 验证成本判断
• 已确认入口
• 已整理导出
• 业务面进度
• 高价值目标
• 候选漏洞
• 报告草稿
• 下一步动作
• 阻塞项

优先维护这几类文件：

• 总推进表 / 作战表
• 资产底稿
• 导出摘要
• 待复核清单
• 报告模板 / 记录模板
• 当轮工作纪要

写回时重点记录：

• 新增了哪些资产或入口
• 哪些已经确认在范围内
• 哪些只是线索
• 哪些适合下一轮继续跟进
• 当前处于哪个阶段，下一阶段的进入门槛是否满足
• 使用了哪些证据来源

如果项目里已经有现成文件，就更新现有文件；不要轻易平行创建一堆新文档。

十二、当任务已经进入挖掘阶段

如果用户不是要你“整理资料”，而是已经开始在授权范围内推进漏洞挖掘，也继续沿用这个技能的框架。

这时你的重点变成：

• 先快速确认目标是否在授权范围内
• 确认该入口属于哪条业务线
• 判断它属于正式、测试还是待确认环境
• 把观察到的入口、参数、角色、流程记录下来
• 按漏洞大类去扩验证思路，而不是被单一线索绑定
• 把发现写进本地清单或笔记，方便后续复盘与报告

进入实际挖掘阶段时，默认优先围绕这些大类展开低影响验证：

• 未授权访问
• 越权 / 横向越权 / 纵向越权
• 鉴权边界问题
• 业务接口暴露与敏感功能未受保护
• 用户/账号/手机号/订单等枚举类问题
• 订单、支付、优惠券、发票、资料修改等高价值业务流程中的参数信任问题
• CORS、调试开关、错误回显、环境泄露等可辅助深入的线索
• source map / 调试面 / 环境信息泄露（作为辅助突破口，不应默认当成主洞终点）

常见高价值业务面

进入实战阶段后，不要只盯“漏洞名”，更要按 业务面 × 权限面 × 数据流 × 状态流 去打。默认优先覆盖这些面：

• 认证与登录：密码登录、短信登录、扫码登录、找回密码、换绑、SSO、OAuth/SAML/OpenID
• 账户与个人中心：资料、实名、联系人、地址、司机/商家资料、隐私设置
• 权限与角色体系：角色、菜单、按钮、接口、组织/部门/租户/城市隔离
• 订单 / 交易 / 状态流：下单、接单、取消、补差价、确认、退款、开票、结算
• 支付 / 余额 / 券 / 积分 / 发票：支付单、钱包、账单、优惠券、积分中心、开票链路
• 开放平台 / 开发者平台：应用列表、密钥、回调、文档、授权、沙箱、网关
• H5 / 小程序 / 活动页 / 微前端：活动码、模板码、场景参数、调试参数、业务 API 根
• 管理后台 / 内部系统：用户、角色、组织、订单、地图、监控、配置、审批、导出
• 文件上传 / 下载 / 导出 / 附件：文件详情、下载、导出记录、任务列表、OSS 路径
• 消息通知 / 回调 / Webhook：短信、邮件、推送、业务回调、签名校验、重放防护
• 搜索 / 查询 / 列表 / 枚举：自动补全、分页、详情、模糊查询、对象遍历
• 配置 / 环境 / 调试 / 错误处理：source map、debug 参数、错误回显、feature flag、环境域名

常见高价值漏洞方向

围绕上面的业务面，默认优先问这些问题：

• 哪些对象本不该被当前身份读取，却可以被查询到？
• 哪些对象本不该被当前身份操作，却能通过改参数或换角色边界触达？
• 是否存在“前端传什么，后端就信什么”的参数信任问题？
• 状态流里是否存在跳步、重复执行、并发竞争或角色错位？
• 列表、详情、搜索、导出、附件、回调这些“看起来普通”的面，是否藏着未授权或越权？

低影响挖掘时的常用切入角度

默认优先做这些动作，而不是直接冲高风险操作：

• 看登录前后同一接口的响应差异
• 看同对象 / 他对象 / 空参数 / 异常参数的差异
• 看 query、body、header 里的 userId、orderId、roleId、tenantId、appId、fileId、couponId、invoiceId 等对象标识
• 看 callback、redirect_uri、state、ticket、scene、activityCode、templateId、env、debug 等关键参数
• 看“详情 / 列表 / 预览 / 校验 / 配置获取 / 导出任务详情”这些只读接口
• 看同一业务在用户端、司机端、商家端、企业端、后台端之间的对象绑定是否一致

不要把 source map、调试参数、错误信息回显这类线索本身当成唯一目标。它们更重要的作用通常是：帮助你定位真实业务接口、角色边界、隐藏页面和可继续验证的高价值功能面。

优先把它们当成突破口，再继续打：

• 未授权
• 越权
• 鉴权边界
• 参数信任
• 枚举
• 高价值状态流

也就是说：本技能既适合“准备阶段”，也适合“边挖边整理”的阶段。

十三、推荐输出结构

完成一轮后，优先输出这几类结果：

1. 本轮新增资产 / 主机 / 入口
2. 正式 / 预发 / 测试 / 待确认分类
3. 高价值目标待复核清单
4. 已写回哪些本地文件
5. 下一步建议做什么

如果用户要简练版，就只说：

• 这轮新增了什么
• 哪些最值得继续
• 下一步建议往哪走

十四、一个稳定的执行模板

当收到新的企业 SRC 任务时，默认按这个模板推进：

1. 读当前项目的规则、范围、清单、笔记
2. 提炼授权范围、优先级和边界
3. 看官方站点 / SRC / 公告 / 品牌页 / 帮助中心
4. 建立当前轮次的入口树
5. 按需调用 web-access 访问外部站点或平台
6. 按需使用空间测绘、搜索引擎、CT 等被动来源补线索
7. 必要时做导出、下载、离线分类
8. 标记高价值入口和待复核对象
9. 更新本地资料
10. 给出简洁结论和下一步建议

十五、汇报风格

保持执行型、简洁、可落地。

优先用这种表达：

• “我先确认范围和现有清单，再补公开入口。”
• “我先用官方资料建立业务映射，再看被动来源补线索。”
• “导出已经完成，下一步转离线分类。”
• “这批结果里高价值入口不多，预发主机我单独标了。”
• “我已把新增线索写回本地资产底稿。”

不要把它写成抽象方法论。它是一份 长期可复用的企业 SRC 通用工作流手册。