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 — Authorized web pentest: recon, proof-based exploits, report” sidebar_label: “Web Pentest” description: “Authorized web pentest: recon, proof-based exploits, report”

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

网络渗透测试

授权的网络渗透测试服务：信息收集、基于原理的漏洞利用及报告生成。

技能元数据
来源可选 — 通过 hermes skills install official/security/web-pentest 安装
路径optional-skills/security\web-pentest
版本1.0.0
开发者Teknium (teknium1)、Hermes Agent
许可协议MIT
支持平台linux、macos
标签安全, 渗透测试, Web, 信息收集

参考：完整 SKILL.md 内容

:::info 以下为当触发该技能时 Hermes 所加载的完整技能定义。技能处于激活状态时，代理程序将依据此内容执行操作。
::

Web 应用程序渗透测试

用于对 Web 应用程序进行分阶段渗透测试的工作流程。该流程参考了 Shannon 的测试框架（Keygraph、AGPL — 仅借鉴概念，未使用其代码）。 整个流程遵循以下三条原则：

  1. 无漏洞利用则无报告 — 每一项发现都必须有可复现的证据支撑。
  2. 范围受限 — 所有的请求都必须在操作员预先指定的目标范围内进行，超出范围的主机将被拒绝。
  3. 在排除误报前需尝试所有绕过方法 — 除非已尝试所有绕过方案，否则被“拦截”的攻击载荷不能被视为无风险。

⚠️ 严格约束规则 — 每次执行任务前请务必阅读

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

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

  2. 范围白名单机制。 请维护 engagement/scope.txt 文件，每行填写一个主机名或 CIDR 地址。所有通过 nmap、curl、whatweb 执行的操作、浏览器导航以及发送攻击载荷的请求，都必须在该文件列出的允许范围内进行。如果目标地址将您重定向到允许范围之外（如 3xx 状态码指向其他主机，或 HTML 页面中的链接），请立即停止操作，并在继续之前再次向用户确认。

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

  4. 默认禁用云平台元数据探测功能。 除非任务明确将“探测云平台元数据”作为目标，且目标地址处于您的控制之下，否则不得探测 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 进行扫描，未发现可利用的问题”——而非“该应用程序是安全的”。请在报告中保持一致的表述风格。

在开始任何扫描操作之前，需先创建交互目录以及授权确认文件。

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文件。

建议为这些任务分配专门的子智能体并行处理，以提高效率。

类别目标参考资料
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）以及备注。

分析阶段暂不会发送恶意载荷，仅对其进行准备；实际攻击则会在利用阶段执行这些载荷。

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

仅当分析队列中存在可采取行动的条目（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 已识别 — 匹配到相应模式，但应用行为未发生变化
    • L2 部分确认 — 已触及目标系统，但存在防护措施
    • L3 已确认 — 攻击载荷以可观察的方式改变了应用行为
    • L4 严重 — 数据已被提取，代码已执行，权限已被提升
  5. 在判定为误报之前需穷尽所有绕过方法。 对于每一个被拦截的候选漏洞，至少要尝试该风险等级对应的references/bypass-techniques.md文件中列出的绕过方案。只有在所有绕过方法都尝试过后，才能填写verdict: false_positive。
  6. 对于所有L3/L4级别的检测结果，都需要记录证据：
    • 完整的请求信息（方法、URL、请求头、请求体）
    • 响应信息（状态码、响应头、相关的响应体片段）
    • 可复现的测试命令（如curl单行命令）
    • 影响说明

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

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

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

第5阶段：报告生成

使用 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 综合扫描工具