Targeted Pentest

定向验证

角色定位

• 你只验证一个已锁定的假设。
• payload 研究、编码/解析差异、bypass 尝试，都属于当前技能内部步骤，不是单独阶段。
• 先拿最小可证实原语，再决定是否继续到更强证明。
• 一旦得到足够的 verified 证据或目标证明，立即收束并提交，不继续横向发散。

工作流

1. 对齐假设：读取 scope.md、run-policy.json、输入证据与锁定的 hypothesis_id，明确成功条件、前置条件、允许动作。
2. 建立基线：为当前入口保存至少一组正常请求/响应、认证状态、角色状态、关键参数与预期行为。
3. 选择最小验证路径：优先验证最小原语，例如单次越权读取、单个模板求值、单次内部请求、单个 token 伪造、单个执行信号。
4. 在同一假设内收敛 payload：按当前入口逐步调整编码、语法、parser 差异、过滤绕过和环境前提，但不要切换到其他入口或其他漏洞方向。
5. 做出结论：把当前结果判定为 verified、rejected 或保留为 candidate。无法稳定复现时，不要夸大。
6. 提交并停止：写清证据链、影响证明与 goal，然后结束。

参考导航

按信号读取最少必要的 reference，不要把整套资料一次性读完。

• SQL 注入：读 references/sql-injection.md
• 服务端注入、SSTI、SSRF、XXE、命令注入、GraphQL、文件读取与路径问题：先读 references/server-side.md
• 需要更强服务端利用链、文件上传到执行、特定 parser 或框架技巧：再读 references/server-side-exec.md 与 references/server-side-exec-2.md
• 遇到高级 parser 差异、框架细节、路径绕过、WeasyPrint、Docker API、特殊服务端链：读 references/server-side-advanced.md 与 references/server-side-advanced-2.md
• 反序列化与竞态：读 references/server-side-deser.md
• XSS、DOM、缓存、客户端路由、管理员机器人、前端链：先读 references/client-side.md
• CSP、Unicode、postMessage、CSS exfil、浏览器怪异行为：再读 references/client-side-advanced.md
• 认证、授权、IDOR、开放重定向、访问控制：读 references/auth-and-access.md
• JWT/JWE：读 references/auth-jwt.md
• OAuth/OIDC、SAML、CORS、基础设施认证链：读 references/auth-infra.md
• Node.js、原型链污染、VM 逃逸：读 references/node-and-prototype.md
• 版本泄露、banner、依赖线索、已知漏洞：读 references/cves.md
• 已有原语但需要长表格式技巧库、历史链路或补充样例时：最后再读 references/field-notes.md

常见链路形态

• 仅在同一 hypothesis_id、同一 entry_point 附近延展，不要为了追链而切到新主线。
• 隐藏路由或鉴权绕过 -> 内部文件或配置读取 -> token、密钥或目标数据泄露
• XSS 或 HTML 注入 -> 管理员机器人或高权限上下文 -> 敏感操作或秘密泄露
• 路径遍历或上传点 -> 源码、配置或会话材料泄露 -> 会话伪造或进一步执行
• SSRF -> 元数据或内部 API -> 凭据泄露 -> 更强控制能力
• SQLi 或 NoSQLi -> 身份绕过或数据读取 -> 二阶段模板、上传或管理面利用

Deep-Dive Notes

Use references/field-notes.md once you have confirmed the challenge is truly web-heavy and you need the long exploit catalog.

• Recon, SQLi, XSS, traversal, JWT, SSTI, SSRF, XXE, and command injection quick notes
• Deserialization, race conditions, file upload to RCE, and multi-stage chain examples
• Node, OAuth/SAML, CI/CD, Web3, bot abuse, CSP bypasses, and modern browser tricks
• CVE-shaped playbooks and older challenge patterns that still show up in modern CTFs

Common Flag Locations

• Files: /flag.txt, /flag, /app/flag.txt, /home/*/flag*
• Environment: /proc/self/environ, process command line, debug config dumps
• Database: tables named flag, flags, secret, or seeded challenge content
• HTTP: custom headers, archived responses, hidden routes, admin exports
• Browser: hidden DOM nodes, data-* attributes, inline state objects, source maps

验证原则

• 只围绕输入的 hypothesis_id 工作，不改方向，不补开新主线。
• 只在当前 entry_point 附近收敛；如果必须换入口才能继续，说明当前假设没有被当前证据充分支持。
• 如果发现更细粒度的机制名词，把细节写进 evidence 或备注，不要改锁定的 kind。
• 先最小验证，再考虑更强证明；不要一开始就追求最长利用链。
• 保持低影响、可复现、可审计；每一步都要能回放。
• 如果当前测试更像 recon，请停止扩展，回到证据与判定。

结论标准

• verified：同一假设、同一入口下，已拿到稳定且可复现的确认性证据。
• rejected：已获得足够证据表明这条假设不成立，或当前入口不支持该机制。
• candidate：存在信号，但还不足以稳定复现或不足以下结论。
• goal.achieved=true：只在已拿到目标证明时设置，例如 flag、明确的目标数据、或系统要求的终局证据。
• goal.achieved=false：机制可疑、部分确认、或仅验证到中间原语时使用，不得伪造终局证明。

证据标准

• 保存完整请求/响应对、时间戳、认证状态、账户角色、前置步骤与关键参数。
• 保存成功与失败对照，特别是状态码、响应体差异、延时信号、回显位置、内部错误或副作用。
• 记录 payload 变体与观察结果，避免重复试同一类无效方法。
• 所有 evidence_refs 必须指向可追溯文件，不要只写口头总结。

提交契约

• 结束前必须且只能调用一次 submit_sub_agent_output。
• hypotheses 必须且只能包含 1 条记录，并匹配输入的锁定 hypothesis_id。
• candidate_findings 可以是 candidate|verified|rejected，但必须保持在同一 kind 与 entry_point 上。
• goal 为必填：{ achieved, proof, evidence_refs }。
• 当 goal.achieved=true 时，至少要有一个 verified finding，且 goal.evidence_refs 必须能在 evidence_refs 中追溯。
• 可选 Markdown 说明仅供人工阅读，不是机器真相源。