recon-methodology

star 72

侦察方法论 — 系统化的攻击面枚举、技术栈指纹识别和信号收集，为后续任务清单的适用性判断提供依据。

Q16G By Q16G schedule Updated 6/7/2026
play_arrow Run Skill in Manus View GitHub

name: recon-methodology description: 侦察方法论 — 系统化的攻击面枚举、技术栈指纹识别和信号收集，为后续任务清单的适用性判断提供依据。 when-to-use: 全面渗透测试的第一步，与 agent-browser 配合完成站点探索和信号收集 allowed-tools: bash,read_file,list_files,rg,list_skills user-invocable: false

侦察方法论（Recon Methodology）

目标

系统化地收集目标站点的攻击面信息和技术信号，为后续任务清单中各项的适用性判断提供依据。

与 agent-browser 的配合

agent-browser 是浏览器自动化工具，recon-methodology 指导探索什么和怎么探索：

  • agent-browser 执行具体的浏览器操作（访问页面、填写表单、点击按钮）
  • recon-methodology 提供探索清单和信号收集框架

侦察清单

1. 站点结构

  • 首页及导航结构（菜单、侧边栏、页脚链接）
  • 登录/注册入口
  • 管理后台入口（/admin、/manage、/dashboard 等常见路径）
  • API 端点（/api/、/v1/、/graphql 等）
  • 静态资源路径（推断目录结构）

2. 技术栈指纹

  • 响应头：Server、X-Powered-By、X-AspNet-Version 等
  • Cookie 名称模式：PHPSESSID（PHP）、JSESSIONID（Java）、ASP.NET_SessionId（.NET）
  • 前端框架指纹：页面源码中的 React/Vue/Angular 特征
  • 错误页面：默认错误页泄露框架信息
  • 文件扩展名：.php、.jsp、.aspx、.do 等

3. 输入点枚举

  • 所有表单（登录、搜索、评论、个人资料编辑）
  • URL 查询参数
  • 文件上传点
  • API 请求参数（观察网络流量）
  • HTTP Header 注入点（Referer、User-Agent、X-Forwarded-For）

每个新发现的输入点同时关联到一组待证实/证伪的风险假设——这是输入点登记的格式约束。

4. 认证与会话

  • 认证方式（Cookie/Session、JWT、OAuth、Basic Auth）
  • 角色模型（是否有多种角色、权限分级）
  • 会话管理（Cookie 属性、会话超时）

5. 业务流程

  • 核心业务流程（注册→登录→操作→结果）
  • 支付/积分/订单流程
  • 通知发送功能（短信、邮件）
  • 数据导入/导出功能

6. 业务场景推断（基线建议）

完成上述侦察后，加载 page-analysis skill 做页面深度分析（含业务场景维度）， 基于已观察到的页面内容和 HAR 请求推断应用业务场景。

每次登录身份切换后（匿名浏览完成后、普通用户登录后、管理员登录后）， 建议各触发一次以更新场景上下文——不同身份看到的页面差异显著， 管理后台的资源类型和越权风险与普通用户视角完全不同。

产出追加写入 shared/coverage-ledger/inventory/page-ledger.jsonl， 后续 idor-detection、race-condition、business-logic-testing 自动读取复用。

端点账本输出（侦察阶段产出格式）

侦察结束后，输出按子系统分组的端点账本——既作为后续任务清单的适用性判断依据，也作为下游 sink skill 查询、横向迁移登记、覆盖矩阵对账的共享数据源。

单子系统场景的账本骨架

## 端点账本

### 已发现端点（含方法 / 参数 / 鉴权 / 业务语义）
- GET  /api/<path>?<params>  鉴权: <none|guest|user|admin>  语义: <短描述>
- POST /api/<path>           鉴权: ...                       语义: ...

### 待递归探索的二级入口（三态标注）
- [x] visited        /admin
- [-] n/a (原因)     /console     （原因示例：诉求范围外 / 该子系统未启用 / 探测后确认 404）
- [+] added (来源)   /dashboard   （来源示例：从某页面 link 提取）

### 技术栈指纹
- ...

### 业务场景标签
- 关联到 page-analysis 产出

多子系统场景的账本骨架（按子系统独立分组）

## 端点账本

### 子系统 A（端口 / 子域 / 业务条线名）
- 已发现端点 / 待探索二级入口 / 技术栈指纹 / 业务场景标签（同上）

### 子系统 B
- ...

### 全站汇总（跨子系统模式信号）
- 跨子系统共性技术栈（如"6 个子系统都用 Go html/template"→ 高优先级横扫信号）
- 跨子系统共性参数模式（如"4 个子系统都有 keyword 搜索参数"→ SQLi 横扫候选）

是否需要按子系统独立完成侦察由 profile 层"多子系统对账"约束触发，本节给出的是输出结构契约。

二级入口基线检查项

以下是已知的常见二级入口形态，作为基线起点而非必检硬清单。结合目标实际可裁剪：

  • 适用且已访问 → 标注 [x] visited
  • 明确不适用 → 标注 [-] n/a (原因)，原因要具体到事实（"该子系统未启用 admin 后台" / "诉求范围外"），不要笼统写"不适用"
  • 基线未列出但实际发现的二级入口 → 新增条目并标注 [+] added (来源)，来源指页面 link / 导航元素等线索

基线候选：

  • /admin*、/console*、/dashboard*、/manage* 等管理 / 控制类二级入口
  • 列表页中的"详情"链接（每种资源至少打开一个详情页）
  • 详情页中的"编辑 / 合并 / 分派 / 状态切换"等按钮触达的子页
  • SPA 中懒加载路由（snapshot 后从 link 与 nav 元素枚举）

不要为了凑齐基线硬套不适用的入口；也不要因基线没列就漏掉真实发现。是否要访问每个入口由 profile 层的"探索性约束"触发，本节给出的是访问后的账本登记格式。

多子系统侦察产出基线

目标暴露多个子系统（不同端口 / 子域 / 业务条线）时，端点账本按子系统独立分组，每个子系统的 (技术栈 / 端点清单 / 业务场景标签 / unvisited 二级入口) 四元组独立呈现。

  • 是否要为每个子系统独立做一遍由 profile 层的"多子系统对账"约束触发；本节给出的是输出结构契约
  • 跨子系统共性模式（同框架 / 同参数命名 / 同 sink 形态）应在全站汇总段提取，作为横向迁移信号给类比迁移触发器消费

和 profile 层的关系

本 skill 是侦察阶段的产出格式提供方；侦察的触发时机与递归深度（何时回归侦察基线、何时访问哪些二级入口、何时为每个子系统独立做一遍）由 pentest agent profile 的"探索性约束"与"多子系统对账"章节定义（落在 sastx 源码 internal/tui/config.go 的 defaultAgentFiles["pentest.yaml"] 字面量）。两层职责互补：profile 决定何时做、做几轮；skill 决定每轮的输出应该长什么样。

端点账本产出契约（必须遵守）

为什么这里是「必须」：端点账本是产物格式契约——下游 sink skill 按 sink 语义查询端点、profile 反例义务自检按账本枚举、类比迁移按账本登记候选传播宿主，schema 不一致或字段缺失会让整条 coverage-ledger 失效。

落盘位置：shared/coverage-ledger/inventory/endpoint-ledger.jsonl（与已有 page-ledger.jsonl 同目录、同 jsonl 风格、append-only）

每行 schema：

{
  "id": "EP-{seq}",
  "subsystem": "ads | desk | mall | cms | chat | portal | ...",
  "method": "GET | POST | PUT | DELETE | ...",
  "path": "/api/ads/templates/render",
  "params": [{"name": "url", "loc": "json|query|form|header|cookie|path", "sample": "..."}],
  "auth_required": "none | guest | user | admin | custom_header_X",
  "business_semantic": "广告创意提交渲染 | 用户登录 | 文件下载 | ...",
  "discovery_source": "har | snapshot | secondary-entry-explore | propagation-candidate",
  "visit_status": "visited | unvisited (reason) | added (来源)",
  "interaction_status": "no-interaction-triggered | interaction-triggered (动作描述)",
  "pattern_ids": ["like-keyword-concat-sqli", "go-template-html-direct-render-stored", "..."],
  "coverage": {
    "sqli": "tested-vulnerable | tested-safe-with-evidence | n/a-with-reason | pending",
    "xss": "...",
    "ssrf": "..."
  },
  "ts": "{Unix 时间戳}"
}

追加规则：append-only，同一端点更新时追加新行（事件溯源），不就地修改历史。id 全局递增、跨子系统统一编号。

与现有 coverage-ledger 的关系：

  • page-ledger.jsonl（已有）→ 页面深度分析（含业务场景上下文），给 idor-detection / business-logic-testing 读取
  • endpoint-ledger.jsonl（本契约新增）→ 端点 × 漏洞维度的覆盖矩阵账本，给所有 sink skill 和 profile 反例义务自检读取
  • open_items.md（已有）→ 未闭环漏洞项与已闭环漏洞项的账本，pattern_id 在此与端点账本交叉引用
  • findings-index.md（已有，jq 派生）→ 终态产物索引

下游消费约定：

  • 任何 sink skill 在判定"该子系统某维度无漏洞"前从本账本枚举该子系统下所有可能触发该 sink 的端点（按 sink 语义而非参数名），缺失则结论降级为 partial-coverage
  • 类比迁移触发时（profile 元行为），命中端点的 pattern_id 写入本账本，同 pattern_id 的候选传播端点从本账本反向查询
  • 收敛阶段按 (subsystem, coverage.维度) 矩阵化输出，矩阵单元格的三态值来源于本账本

安全边界

  • 侦察阶段以被动观察和轻量探测为主，不发送攻击 payload
  • 目录枚举控制在常见路径范围内，不进行暴力枚举
  • 记录但不利用发现的敏感信息
Install via CLI
npx skills add https://github.com/Q16G/aster --skill recon-methodology
Repository Details
star Stars 72
call_split Forks 6
navigation Branch main
article Path SKILL.md
More from Creator
Q16G
Q16G Explore all skills →