Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

title: “Web Pentest” sidebar_label: “Web Pentest” description: “Authorized web application penetration testing — reconnaissance, vulnerability analysis, proof-based exploitation, and professional reporting”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能对应的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

网络渗透测试

提供合规的网络应用程序渗透测试服务——包括侦察、漏洞分析、基于证据的利用测试以及专业报告输出。该服务采用了 Shannon 提出的“无利用即无报告”原则，并设置了严格的限制措施，以确保测试范围、授权流程以及辅助客户端信息不会泄露。仅针对您拥有所有权或已获得明确测试授权的正在运行的应用程序进行主动测试。

技能元数据
来源可选——可通过 hermes skills install official/security/web-pentest 安装
路径optional-skills/security/web-pentest
支持平台linux、macos

参考：完整 SKILL.md 文件

:::info 以下是当触发该技能时 Hermes 会加载的完整技能定义。当技能处于激活状态时，代理程序会将此内容视为操作指令。
::

网络应用程序渗透测试

专为网络应用程序设计的分阶段渗透测试工作流程。该流程借鉴了 Shannon 的测试框架（Keygraph、AGPL——仅采用概念，未借用任何代码），并基于以下三条原则构建：

  1. 无利用即无报告——每一项发现都必须有可复现的证据支持。
  2. 范围受限——每一个主动请求都必须在操作员预先声明的目标范围内进行，超出范围的主机将被拒绝。
  3. 在排除误报前先尝试所有绕过方法——在尝试完所有绕过方案之前，无法判定被“拦截”的攻击载荷代表目标安全无虞。

⚠️ 严格限制措施——每次任务开始前请务必阅读

违反任何一项规定都将导致任务无效，甚至可能触犯法律。

  1. 授权确认环节。 在会话中的首次主动扫描之前，您必须以书面形式向用户确认，他们拥有目标的所有权或已获得明确的测试授权。请将用户的确认信息记录在 engagement/authorization.md 文件中（参见模板）。未经确认则不得进行任何主动扫描。使用 curl 浏览公开页面是允许的，但发送攻击载荷则不被允许。

  2. 范围白名单机制。 请维护 engagement/scope.txt 文件——每行填写一个主机名或 CIDR 地址。所有 nmap、curl、whatweb、浏览器导航以及携带攻击载荷的请求，都必须针对该文件中的有效条目进行。如果目标将您重定向到范围之外的地址（如 3xx 状态码跳转至其他主机，或 HTML 中的链接），请立即停止，并在继续操作前与用户确认。

  3. 未经书面确认不得测试生产环境。 如果用户未明确表示“是的，生产环境在测试范围内，且我已获得书面授权”，则视为不在测试范围内。默认的目标为测试环境、本地 Docker 容器以及专用的测试实例。

  4. 默认情况下不探测云服务元数据。 除非任务明确将 SSRF 到元数据的探测作为目标，且目标属于您可控的范围，否则请勿探测 169.254.169.254、metadata.google.internal、100.100.100.200、[fd00:ec2::254] 等地址。代理程序的浏览器工具可以从您自己的基础设施内部访问这些地址，但请勿主动进行探测。

  5. 破坏性载荷需事先获得批准。 包含 DROP/DELETE 操作的 SQLi 攻击载荷、可写入文件系统的 SSTI 攻击载荷、使用 rm/shutdown/mkfs 等命令的注入攻击载荷，以及任何会导致多行数据被修改的攻击载荷——在使用之前都必须先获得批准。approval.py 系统可以检测部分此类载荷，但请勿仅依赖它。

  6. 辅助客户端信息泄露风险（Hermes 特有）。 该技能在测试过程中会生成包含 SQLi/XSS/RCE 攻击载荷、捕获的凭证、JWT 令牌等信息的会话记录。Hermes 的压缩及标题生成机制会通过辅助客户端（通常是主模型）重新处理历史记录。因此，您在对话中输入的任何敏感信息都可能在下一次压缩时泄露。缓解措施：

    • 在将捕获的令牌/凭证记录到任何消息中之前，先将其截断为最后 6 位字符。完整内容应保存在 engagement/evidence/ 文件中，绝不能出现在聊天记录中。
    • 如果任务涉及敏感信息，请在当前会话的 ~/.hermes/config.yaml 文件中设置 auxiliary.title_generation.enabled: false。

  7. 自行控制请求频率。 对于任意单个主机，主动请求之间的默认间隔为 200 毫秒。recon-scan.sh 脚本会强制执行这一限制。未经操作员批准，不得绕过此限制。

  8. 报告的权威性说明。 该技能生成的是安全评估结果，而非“通过”判定。即便测试结果正常，也应表述为“在时间 T 内，使用方法 Y 对范围 X 进行测试，未发现任何可利用的问题”，而非“该应用程序是安全的”。请在报告中也采用类似表述方式。

第 0 阶段：任务准备

在开始任何扫描之前，请先创建任务目录并获取用户的授权确认。

ENGAGEMENT=engagement-$(date +%Y%m%d-%H%M%S)
mkdir -p "$ENGAGEMENT"/{evidence,findings,reports}
cd "$ENGAGEMENT"

  1. 原样询问用户：

    “请确认：(a) 目标网址为 [X]，(b) 您是该应用程序的所有者 或已获得书面授权可对其进行测试，(c) 从现在开始，本次操作可能持续 长达 [N] 小时。如同意继续，请回复‘authorized’。”

  2. 等待用户明确回复‘authorized’。 任何其他回复均表示立即停止。

  3. 按照 templates/authorization.md 中的模板，将授权信息记录到 engagement/authorization.md` 文件中。需包含以下内容：

    • 目标网址及 IP 地址
    • 授权依据（所有权 / 来自 $name 的书面授权）
    • 操作时间范围
    • 不在操作范围内的项目（生产环境、第三方服务等）
    • 操作员姓名（即发起此次操作的用户）

  4. 生成 scope.txt 文件：

    localhost
127.0.0.1
staging.example.com
192.168.1.0/24    # internal lab only, with operator OK

  5. 在发起第一个实际请求之前，请先阅读 references/scope-enforcement.md —— 该文档列出了在每个命令或 URL 发送之前需应用的主机提取规则。

第一阶段：预侦察（代码分析，可选）

若无法访问源代码（即黑盒式操作），则可跳过此步骤。

如果您有权限读取应用程序的源代码：

  1. 梳理架构 —— 框架、路由机制及中间件堆栈
  2. 统计数据接收点 —— 所有的 execute()、os.system()、eval() 调用，模板渲染逻辑，文件读写操作以及重定向目标
  3. 分析认证机制 —— 会话 Cookie 与 JWT 的区别，OAuth 认证流程，密码重置功能，以及高权限接口
  4. 确定信任边界 —— 哪些部分经过认证，哪些没有，以及 request.* 中的数据来源
  5. 追踪每个数据接收点对请求源的潜在影响路径。一旦发现有效的防护措施（如参数化查询、允许列表、shlex.quote 函数以及常见的转义机制），即可立即终止侦察。

输出文件为 evidence/pre-recon.md —— 包含架构图、数据接收点清单以及疑似存在漏洞的代码路径。

此阶段为离线操作，不会向目标系统发送任何请求。

第二阶段：侦察（实时进行，仅读模式）

用于绘制攻击面地图。所有请求均为对公开页面的 GET 请求，暂不包含任何载荷，且仍在范围限制之内。

  1. 验证范围。将每个目标主机名解析为 IP 地址，并确认这些 IP 属于预定的侦察范围（以避免“DNS 解析指向意外地址”的情况）。

  2. 网络层面分析（仅当范围允许进行端口扫描时才执行）：

    nmap -sT -T3 --top-ports 100 -oN evidence/nmap.txt $TARGET

请使用默认值 -T3，而非 -T4/-T5。这样能降低存在感，避免在共享环境中触发 IDS/IPS 的检测。

  1. 技术指纹：

    whatweb -v $TARGET_URL > evidence/whatweb.txt
curl -sIk $TARGET_URL > evidence/headers.txt

  2. 端点发现：

    • 使用浏览器工具爬取应用（如 browser_navigate、browser_get_images 以及链接跟随功能）。
    • 检查 robots.txt、sitemap.xml 以及 .well-known/* 目录下的文件。
    • 通过浏览器工具的开发者工具网络面板，捕获 XHR/fetch 请求。

  3. 认证信息收集： 识别登录、注册、密码重置功能，以及会话 Cookie 的名称和令牌格式。此时不要发送任何凭证，仅需进行观察。

  4. 与前期侦察结果关联（若有相关资料）。针对每个 evidence/pre-recon.md 中记录的发现，标记实际目标环境是否确认该路径可访问。

输出文件：evidence/recon.md — 包含端点信息、使用技术、认证模型以及攻击向量。

第三阶段：漏洞分析

每个漏洞类别对应一个 delegate_task。每个智能体将读取 evidence/recon.md 文件（如有 evidence/pre-recon.md 也会一并读取），并依据 templates/exploitation-queue.json 模板生成 findings/<class>-queue.json 文件。

建议使用以下专注型子智能体来执行 delegate_task，尽可能实现并行处理：

漏洞类别目标参考资料
injectionSQL注入、命令注入、路径遍历、SSTI、LFI/RFI、反序列化漏洞references/vuln-taxonomy.md（槽位类型）
xss反射型XSS、存储型XSS、基于DOM的XSSreferences/vuln-taxonomy.md（渲染上下文）
auth登录绕过、JWT混淆、会话固定、OAuth漏洞references/exploitation-techniques.md
authzIDOR攻击、垂直/水平权限提升、业务逻辑漏洞references/exploitation-techniques.md
ssrf内部资源可访问性、元数据泄露、协议欺骗除非获得明确授权，否则无需检测元数据
infra配置错误、信息泄露、默认凭证、管理界面暴露references/exploitation-techniques.md

每个队列条目包含以下字段：id、漏洞类别、来源（已知的话则为文件名和行号）、端点地址、参数、槽位类型、疑似防御措施、判定结果（identified/partial/confirmed/critical）、用于验证的载荷、置信度（0-1）以及备注。

分析阶段暂不发送恶意载荷，仅进行准备；真正的攻击载荷则会在利用阶段发送。

第四阶段：漏洞利用（基于证据、条件触发）

仅当分析队列中存在可操作的条目（即判定为 identified 或 partial）时，才为每个类别启动一个子智能体。

针对每个候选漏洞，执行以下步骤：

  1. 发送前检查 — 目标主机是否在检测范围内？认证关卡是否通过？若载荷具有破坏性，是否已获得批准？
  2. 发送验证载荷 — 用于提供最基本的证明。例如SQL注入可使用 ' AND 1=1--，再尝试 ' AND 1=2--；XSS则可使用类似 <svg/onload=console.log("HERMES-PENTEST-XSS")> 的良性标记。在存储型XSS中绝不能使用 alert(1)，因为这会在共享环境中影响其他用户。
  3. 验证载荷是否生效 — 对于无法直接观察反馈的注入漏洞，可使用 SLEEP(5) 这类延时探测来测量响应时间。对于SSRF漏洞，则应使用由测试人员控制的、自己拥有的回调主机（切勿在敏感测试中使用 webhook.site 等公共服务作为数据外传通道）。
  4. 提升漏洞等级：
    • L1 Identified — 匹配到攻击模式，但应用行为未发生改变
    • L2 Partial — 已能接触到目标，但存在防御措施
    • L3 Confirmed — 载荷已导致应用行为出现可观察的变化
    • L4 Critical — 数据已被窃取、代码被执行或权限已被提升
  5. 在判定为误报之前，先尝试所有绕过方法。 对于每个被拦截的候选漏洞，至少尝试 references/bypass-techniques.md 中列出的该类别的绕过技巧。只有在所有绕过方法都试过仍无法利用时，才能将判定结果设为 verdict: false_positive。
  6. 为所有 L3/L4 级别的漏洞记录证据：
    • 完整的请求信息（方法、URL、请求头、请求体）
    • 响应信息（状态码、响应头、相关的响应体片段）
    • 可复现的命令（如 curl 一键命令）
    • 漏洞影响说明

输出文件：findings/exploitation-evidence.md

在证据文件中需进行脱敏处理：

  • 任何捕获到的凭证或令牌 → 在聊天记录中仅显示最后6位字符；完整内容需存入 findings/secrets-vault.md 文件（该文件应添加到 .gitignore 中）。
  • 其他用户的个人身份信息 → 需进行脱敏处理。
  • 自己的测试凭证 → 可以保留。

第五阶段：报告生成

使用 templates/pentest-report.md 模板生成最终报告。报告包含以下部分：

  1. 执行摘要
  2. 检测范围（来自 engagement/scope.txt）
  3. 授权信息（来自 engagement/authorization.md）
  4. 漏洞发现结果（仅列出 L3/L4 级别，且需附上证明）。每个漏洞条目包括：
    • 标题、严重程度（CVSS 3.1标准）、CWE编号
    • 受影响的端点
    • 证明材料（请求和响应的片段）
    • 复现步骤
    • 漏洞影响
    • 补救措施
  5. 未成功利用的候选漏洞（L1/L2级别），并说明导致无法利用的原因
  6. 超出检测范围的观察结果
  7. 使用的方法和工具
  8. 测试的局限性以及未测试的内容

严重程度判定规则： 仅对 L3/L4 级别的漏洞使用 CVSS 评分。L1/L2 级别的漏洞属于“待验证候选项”，不得为其分配 CVSS 评分。

何时停止测试

  • 用户撤销了授权。
  • 某个候选漏洞明显会导致生产数据泄露，而您又没有获得进行破坏性测试的批准 —— 应立即停止并征求用户意见。
  • 目标系统开始频繁返回 503/429 错误 —— 应暂停测试，与操作人员重新商议。
  • 您发现了超出合同约定范围的漏洞（例如在测试无关端点时发现了暴露的客户数据库） —— 应立即停止、记录情况并向操作人员汇报。未经明确批准不得改变测试方向，因为这种行为属于非法渗透测试。

本技能的覆盖范围之外

  • 超出端口扫描范围的网络层渗透测试（不支持 Metasploit、Cobalt Strike、AD攻击以及网络协议模糊测试）。
  • 反向工程/二进制分析（参见问题 #383）。
  • 仅基于源代码的静态分析（参见问题 #382）。
  • 主动的社会工程学攻击/网络钓鱼。
  • 任何未经操作人员预先授权的对系统的操作。

如果检测任务需要上述任何技术，应转交给专业渗透测试人员处理。本技能旨在辅助专业渗透测试，而非替代专业服务。

进一步阅读资料

  • references/scope-enforcement.md — 如何限制每个活跃请求的访问范围
  • references/vuln-taxonomy.md — 槽位类型、渲染上下文以及 OWASP 对应关系
  • references/exploitation-techniques.md — 各类别对应的载荷模式
  • references/bypass-techniques.md — 常见的 WAF/过滤器绕过方法
  • templates/authorization.md — 检测任务授权模板
  • templates/pentest-report.md — 最终报告模板
  • templates/exploitation-queue.json — 各类别漏洞发现队列的架构定义
  • scripts/recon-scan.sh — 带速率限制的 nmap+whatweb+headers 综合扫描工具封装脚本