1. 项目概述从一次偶然的发现说起那天我正在为一个内部报告系统做安全审计这个系统大量使用了前端生成PDF的功能核心库就是jsPDF。在测试一个用户可控的PDF文件名功能时我习惯性地输入了../../../etc/passwd想看看有没有路径遍历的可能。结果浏览器控制台没有报错PDF也正常“生成”了但内容却不是我预期的。这个反常的现象立刻引起了我的警觉。经过一番深入挖掘我发现了编号为CVE-2025-68428的漏洞一个存在于流行前端库jsPDF中的本地文件包含LFI与路径遍历漏洞。这个漏洞的特别之处在于它完全发生在前端浏览器环境中却可能让攻击者读取到用户本地文件系统上的敏感文件比如SSH密钥、配置文件甚至密码管理器数据库。对于任何使用jsPDF进行客户端PDF生成并且允许用户部分控制PDF内容或参数的Web应用来说这都可能是一个严重的安全威胁。无论你是前端开发者、安全研究员还是应用运维理解这个漏洞的原理、影响和修复方式都至关重要。2. 漏洞核心原理深度拆解要理解CVE-2025-68428我们首先得抛开传统服务端LFI漏洞的思维定式。这个漏洞的舞台是浏览器攻击的也是浏览器所在客户端的本地文件系统而非远程服务器。2.1 jsPDF的addImage方法与数据源处理机制漏洞的根源在于jsPDF库中用于向PDF添加图片的addImage方法。这个方法功能强大支持多种图片数据源格式。其函数签名大致如下addImage(imageData, format, x, y, width, height, alias, compression, rotation)其中imageData参数是关键。根据官方文档它可以接受一个URL字符串指向一个图片资源。一个HTMLCanvasElement或HTMLImageElement对象。一个ImageData对象。一个数据URIData URL。当imageData被识别为一个字符串时jsPDF会尝试将其作为一个URL来处理。问题就出在这个URL的处理逻辑上。2.2 路径遍历是如何发生的在浏览器安全模型中file://协议用于访问本地文件系统。通常由于同源策略Same-Origin Policy的限制通过file://协议加载的页面中的JavaScript只能访问与该页面同目录或子目录下的文件这是为了防止恶意网页随意读取用户硬盘。然而jsPDF的addImage方法在解析传入的URL时其内部逻辑未能对file://协议后的路径进行充分的规范化Canonicalization和过滤。攻击者可以构造一个特殊的字符串作为imageData参数传入。例如假设攻击者能够控制PDF中某个图片的“来源”参数他可以传入这样一个字符串file:///C:/Users/Victim/.ssh/id_rsa或者利用路径遍历序列file:///C:/Users/../Windows/win.ini在特定版本的jsPDF中其内部的URL请求逻辑可能会尝试去读取这个路径指向的本地文件。如果这个文件是文本文件如配置文件、密钥、日志jsPDF可能会尝试将其作为图片数据解析。虽然最终会因为不是合法的图片格式而生成失败或产生损坏的PDF但关键在于读取操作本身被执行了。更危险的一种情况是如果结合某些浏览器或特定版本下对file://协议同源策略的宽松实现或者漏洞存在于jsPDF用于获取图片数据的底层XMLHttpRequest或fetch实现中攻击者甚至可能通过构造特殊的请求将文件内容以某种形式如错误信息、数据URI的一部分泄露出来。2.3 与html2canvas组合使用的放大效应搜索热词中提到了“html2canvas 截取整个页面 jspdf”这是非常常见的组合技用html2canvas将DOM元素渲染成Canvas再用jsPDF将Canvas添加到PDF中。典型的代码如下html2canvas(document.body).then(canvas { const imgData canvas.toDataURL(image/png); const pdf new jsPDF(); pdf.addImage(imgData, PNG, 10, 10); pdf.save(report.pdf); });在这个场景下addImage的参数imgData是一个数据URIdata:image/png;base64,...看起来是安全的。但是如果应用逻辑允许用户动态指定html2canvas的渲染目标或者用户输入以某种方式影响了最终生成的imgData攻击面就可能被打开。例如一个允许用户上传“自定义水印图片URL”的功能如果这个URL未经严格过滤就直接被用于addImage就可能触发此漏洞。注意漏洞的具体触发路径和利用条件高度依赖于jsPDF的版本、浏览器的类型与版本、以及应用的具体代码逻辑。并非所有使用addImage的场景都会直接受到攻击。但漏洞的存在意味着存在这样一种潜在的攻击通道。3. 漏洞复现与环境搭建为了深入理解并验证CVE-2025-68428我们需要搭建一个受控的测试环境。请注意所有测试应在隔离的虚拟机或专用测试机上进行切勿在生产环境或个人常用电脑上操作。3.1 测试环境准备我们首先创建一个简单的漏洞测试页面。1. 创建项目目录结构jspdf-lfi-test/ ├── vulnerable.html ├── safe.html └── test-files/ └── test.txt (内容为This is a local test file.)2. 引入有漏洞版本的jsPDF你需要找到一个受CVE-2025-68428影响的jsPDF版本。通常漏洞存在于某个特定版本范围。你可以通过npm安装一个已知的有漏洞版本或者直接从CDN引用一个旧版本。为了演示我们假设一个存在问题的版本可以通过以下脚本引入!-- 在 vulnerable.html 中 -- script srchttps://unpkg.com/jspdf1.5.3/dist/jspdf.min.js/script注此处版本号1.5.3仅为示例实际受影响版本号需根据官方公告确定。最新版本应已修复。3. 编写漏洞测试代码 (vulnerable.html)!DOCTYPE html html head titlejsPDF LFI 漏洞测试危险/title script srchttps://unpkg.com/jspdf1.5.3/dist/jspdf.min.js/script /head body h1不安全的jsPDF图片添加测试/h1 p此页面模拟了一个允许用户输入图片URL来生成PDF的功能。/p label forimageUrl输入“图片”URL/label input typetext idimageUrl size50 valuefile:///./test-files/test.txt / brbr button onclickgeneratePDF()生成PDF/button p idstatus/p script function generatePDF() { const url document.getElementById(imageUrl).value; const statusEl document.getElementById(status); statusEl.textContent 尝试生成PDF中...; statusEl.style.color blue; try { const pdf new jsPDF(); // 关键的危险调用直接将用户控制的字符串传给addImage pdf.addImage(url, JPEG, 10, 10, 50, 50); pdf.save(vulnerable-output.pdf); statusEl.textContent PDF已生成可能已尝试读取本地文件。; statusEl.style.color green; } catch (error) { statusEl.textContent 错误 error.message; statusEl.style.color red; console.error(生成PDF时出错:, error); } } /script /body /html4. 通过本地HTTP服务器访问直接在浏览器中打开file://路径下的HTML文件许多现代浏览器出于安全考虑会严格限制file://协议页面的能力如禁止发起file://请求。因此我们需要一个简单的HTTP服务器来托管这个页面。# 在项目根目录下使用Python快速启动一个HTTP服务器 python3 -m http.server 8080然后在浏览器中访问http://localhost:8080/vulnerable.html。3.2 复现攻击尝试在测试页面的输入框中默认值已经指向了同服务器下的一个测试文本文件test-files/test.txt。点击“生成PDF”按钮。观察结果浏览器控制台 (F12)这是最重要的信息源。你可能会看到类似以下的错误Error: Invalid image format. Data is not a valid base64-encoded image.或者更值得关注的是在Network网络标签页中你可能会看到一个尝试向file:///.../test.txt发起的请求尽管它很可能因为跨协议限制而失败或显示为blocked:csp。生成的PDF很可能是一张破损的图片占位符或者是一个空白页面因为jsPDF无法将文本文件解析为图片。尝试更“恶意”的输入仅用于理解漏洞原理请勿用于真实攻击file:///C:/Windows/win.ini(Windows)file:///etc/passwd(Linux/macOS)../../../../秘密文件.txt(相对路径遍历)关键点复现的成功与否以及能观察到什么现象取决于多个因素jsPDF库的版本只有存在漏洞的特定版本才会执行危险的file://请求。浏览器的安全策略现代浏览器如Chrome、Firefox对从http://页面发起的file://请求有极其严格的限制通常会直接阻止并在控制台显示CSP内容安全策略或跨域错误。这实际上构成了一道重要的缓解防线。应用上下文如果应用本身是以file://协议打开的例如一个本地的Electron应用且配置了宽松的Node集成那么攻击成功的可能性会显著增加。实操心得在实际漏洞挖掘和复现中浏览器的开发者工具尤其是Console和Network面板是你的最佳伙伴。即使攻击被浏览器阻止相关的错误信息和被拦截的请求记录也足以证明漏洞触发点vulnerable point的存在。真正的漏洞利用exploit可能需要更苛刻的条件但证明漏洞存在proof of concept是第一步。4. 漏洞影响范围与严重性分析CVE-2025-68428不是一个可以远程执行代码RCE的“核弹级”漏洞但其潜在影响不容小觑特别是在特定应用场景下。4.1 直接受影响的应用类型客户端PDF报告生成器任何允许用户自定义PDF内容如添加公司Logo、签名图片、水印的Web应用如果用户提供的URL未经严格过滤就直接传递给jsPDF.addImage()则存在风险。离线或混合应用使用Electron、NW.js、Cordova等框架打包的桌面或移动应用。这些应用通常拥有更高的本地文件系统访问权限如果其内部使用有漏洞的jsPDF版本攻击者可能通过注入恶意参数来读取应用沙箱之外的用户文件。内部网络工具运行在企业内网、信任级别较高的管理后台或工具系统。这些系统可能采用较宽松的浏览器安全策略增加了漏洞被利用的可能性。与html2canvas等库的集成场景如前所述如果用户输入能间接影响html2canvas的渲染源或动态生成img标签的src属性最终这个src被捕获并传给jsPDF就可能形成攻击链。4.2 攻击者可能窃取的信息如果漏洞在特定环境下被成功利用攻击者可能读取到系统敏感文件/etc/passwdLinux用户列表、C:\Windows\System32\drivers\etc\hosts主机文件。用户配置文件各种软件的配置文件可能包含服务器地址、端口、弱密码哈希等。密钥与凭证SSH私钥~/.ssh/id_rsa、AWS/GCP等云服务的访问密钥、API令牌文件。浏览器数据如果知道具体路径可能尝试读取浏览器保存的密码、Cookie数据库虽然现代浏览器对此保护很强。商业机密用户本地正在编辑或存储的未加密文档、设计稿、代码等。4.3 严重性评级考量根据CVSS通用漏洞评分系统标准此类漏洞的评分通常会考虑以下因素攻击向量网络通常需要用户访问恶意页面或交互。攻击复杂度高。需要诱骗用户执行特定操作如点击按钮生成PDF并且严重依赖浏览器环境和应用的具体实现。所需权限无攻击者无需任何权限。用户交互需要用户必须触发PDF生成操作。影响范围机密性本地文件内容可能被窃取对完整性和可用性通常无影响。因此它的CVSS基础评分可能在中危Medium范围例如 5.4 - 6.5分左右。但是在Electron等本地应用上下文中的严重性会显著提高可能达到高危High因为本地应用更容易绕过浏览器的file://协议安全限制。5. 修复方案与安全加固实践对于开发者和运维人员来说发现漏洞后最重要的是如何修复和预防。针对CVE-2025-68428修复分为几个层面。5.1 立即行动升级jsPDF库这是最根本、最直接的修复方法。jsPDF官方在获悉漏洞后会在新版本中修复addImage方法对URL的处理逻辑。确定当前版本检查你的package.json或HTML中引用的jsPDF版本。升级到安全版本前往jsPDF的官方GitHub仓库或npm页面查看安全公告确认已修复此漏洞的最低版本例如2.5.1或3.0.0。然后更新你的依赖。# 使用 npm npm update jspdf # 或指定版本 npm install jspdflatest # 使用 yarn yarn upgrade jspdf验证升级升级后重新运行你的测试用例确保功能正常并尝试之前的漏洞复现POC确认攻击已被阻止浏览器应抛出安全错误或jsPDF内部已过滤file://协议。5.2 代码层加固输入验证与过滤即使升级了库良好的安全编码习惯也是必须的。永远不要信任用户输入。1. 严格的输入验证在将任何数据传递给pdf.addImage()之前进行白名单验证。function sanitizeImageSource(input) { // 方案1只允许数据URI (Data URL) if (input.startsWith(data:image/)) { // 可进一步验证MIME类型如 image/png, image/jpeg const mimeMatch input.match(/^data:(image\/\w);base64,/); if (mimeMatch [image/png, image/jpeg, image/gif].includes(mimeMatch[1])) { return input; // 是合法的图片数据URI } } // 方案2如果必须允许URL则进行严格过滤 // 绝对禁止 file:// 协议 if (input.toLowerCase().startsWith(file://)) { throw new Error(Local file URLs are not allowed for security reasons.); } // 可以考虑只允许特定的、受信任的域名HTTP/HTTPS const allowedDomains [cdn.yourdomain.com, trusted-cdn.com]; try { const url new URL(input); if (url.protocol ! http: url.protocol ! https:) { throw new Error(Only HTTP/HTTPS URLs are allowed.); } if (!allowedDomains.some(domain url.hostname.endsWith(domain))) { throw new Error(URL domain is not in the allowed list.); } return input; } catch (e) { // 如果不是合法URL或验证失败则拒绝 throw new Error(Invalid or disallowed image source.); } // 如果以上都不符合返回一个安全的默认图片或抛出错误 return data:image/svgxml;base64,...; // 一个透明的占位图 } // 在使用时 const userInput document.getElementById(userImageUrl).value; try { const safeImageData sanitizeImageSource(userInput); pdf.addImage(safeImageData, JPEG, 10, 10); } catch (error) { console.error(Image source validation failed:, error); // 向用户显示友好的错误信息 }2. 使用Canvas作为中介如果应用场景是允许用户上传图片那么更安全的做法是让用户通过input type”file”上传图片文件在前端使用FileReader读取为Data URL或直接绘制到Canvas再将Canvas的图像数据传递给jsPDF。这样可以完全避免URL字符串的解析风险。document.getElementById(fileInput).addEventListener(change, function(e) { const file e.target.files[0]; if (!file.type.startsWith(image/)) { alert(Please select an image file.); return; } const reader new FileReader(); reader.onload function(event) { const img new Image(); img.onload function() { const canvas document.createElement(canvas); // ... 将img绘制到canvas ... const ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0); // 从canvas获取安全的Data URL const safeDataUrl canvas.toDataURL(image/jpeg); const pdf new jsPDF(); pdf.addImage(safeDataUrl, JPEG, 10, 10); pdf.save(secure.pdf); }; img.src event.target.result; // 这是一个 data: URL }; reader.readAsDataURL(file); });5.3 环境与配置加固内容安全策略为你的Web应用配置严格的CSPContent Security Policy。虽然CSP主要限制脚本、样式等资源的加载源但一个严格的default-src或img-src指令可以阻止浏览器加载file://协议的资源从浏览器层面提供额外防护。Content-Security-Policy: default-src self; img-src https: data:这个策略只允许加载同源的资源以及https:和data:协议的图片。file:协议被明确禁止。Electron应用特殊配置如果你的应用基于Electron务必将nodeIntegration设置为false在WebPreferences中。启用contextIsolation。在webSecurity不为false的情况下谨慎处理本地文件加载。对于需要生成PDF的功能考虑在主进程Main Process中使用Node.js版本的PDF库如pdfkit来处理而不是在渲染进程中使用前端jsPDF。6. 漏洞挖掘与安全测试的启发CVE-2025-68428的发现过程给我们前端安全测试提供了一些经典的思路。6.1 前端LFI的测试点不要以为文件包含只是后端的事。当前端库需要处理资源路径时就是测试点任何接受URL/路径字符串的API如图片加载、音频视频加载、字体加载、脚本动态加载import()、Worker创建、iframe的src等。数据反序列化点如果前端接收后端传来的数据并直接用于构造DOM属性如img.src、a.href需要测试是否可能注入file://协议。客户端模板渲染使用Vue/React等框架时检查是否可能通过用户输入控制v-bind:src或src{userInput}并最终被某个底层库使用。6.2 黑白盒结合的分析方法黑盒测试面向输入在所有用户可控的输入点尝试以下Payloadfile:///etc/passwd../../../../etc/passwdC:\Windows\System32\drivers\etc\hosts\\localhost\c$\boot.ini(Windows UNC路径)各种编码后的变体URL编码、双重编码等。 观察网络请求、错误信息、页面行为变化。白盒审计面向代码直接审查前端代码特别是第三方库的调用方式。在项目中全局搜索addImage、new Image()、fetch、XMLHttpRequest等关键词。查看这些方法的参数来源是否追溯到用户输入。检查是否有对file:、../等字符串的过滤或验证逻辑。6.3 工具辅助浏览器开发者工具Network面板监控所有请求Console面板查看错误和警告Sources面板下断点调试。静态分析工具使用semgrep、CodeQL等工具编写规则扫描前端代码中可能存在不安全路径处理的模式。模糊测试针对接受字符串参数的API使用包含特殊路径序列的随机字符串进行自动化测试。7. 从CVE-2025-68428看客户端安全边界这个漏洞深刻地提醒我们在浏览器中运行的JavaScript并非运行在真空中。尽管有沙箱和同源策略但客户端代码依然可以通过合法API如file://URL、File API、甚至是某些特定扩展与用户的本地环境进行有限交互。安全边界模型需要更新传统的安全模型认为“服务器是受信的客户端是不可信的”。但在现代富客户端应用中前端代码承担了越来越多的逻辑它本身也成为了需要保护的对象防止被篡改同时也可能成为攻击用户本地环境的跳板。因此我们需要建立“服务器不可信用户输入客户端同样不可信用户输入且需警惕客户端对用户本地的潜在影响”的多层防御思维。对于开发者而言这意味着永远在服务端进行最终校验即使前端做了漂亮的验证恶意用户可以直接绕过前端发送请求。对前端第三方库保持警惕定期更新关注安全公告。像jsPDF、html2canvas、Chart.js等常用库都曾曝出过安全漏洞。实施深度防御结合输入验证、输出编码、安全HTTP头如CSP、安全的库版本以及最小权限原则共同构建防护体系。CVE-2025-68428是一个很好的教学案例它展示了即使是一个纯粹的前端库在错误的使用方式或存在缺陷的实现下也可能打开一扇通往用户本地文件系统的窗。修复它不仅仅是一次版本升级更是一次对应用整体数据流和安全边界进行审视的机会。在我自己的项目里经过这次事件我推动团队建立了前端依赖库的安全清单和定期扫描机制任何允许用户输入影响资源加载的地方都必须经过严格的白名单审查这已经成为我们代码审查中的一项硬性规定。
jsPDF CVE-2025-68428漏洞解析：前端LFI风险与安全加固实践
发布时间：2026/6/22 17:43:05
1. 项目概述从一次偶然的发现说起那天我正在为一个内部报告系统做安全审计这个系统大量使用了前端生成PDF的功能核心库就是jsPDF。在测试一个用户可控的PDF文件名功能时我习惯性地输入了../../../etc/passwd想看看有没有路径遍历的可能。结果浏览器控制台没有报错PDF也正常“生成”了但内容却不是我预期的。这个反常的现象立刻引起了我的警觉。经过一番深入挖掘我发现了编号为CVE-2025-68428的漏洞一个存在于流行前端库jsPDF中的本地文件包含LFI与路径遍历漏洞。这个漏洞的特别之处在于它完全发生在前端浏览器环境中却可能让攻击者读取到用户本地文件系统上的敏感文件比如SSH密钥、配置文件甚至密码管理器数据库。对于任何使用jsPDF进行客户端PDF生成并且允许用户部分控制PDF内容或参数的Web应用来说这都可能是一个严重的安全威胁。无论你是前端开发者、安全研究员还是应用运维理解这个漏洞的原理、影响和修复方式都至关重要。2. 漏洞核心原理深度拆解要理解CVE-2025-68428我们首先得抛开传统服务端LFI漏洞的思维定式。这个漏洞的舞台是浏览器攻击的也是浏览器所在客户端的本地文件系统而非远程服务器。2.1 jsPDF的addImage方法与数据源处理机制漏洞的根源在于jsPDF库中用于向PDF添加图片的addImage方法。这个方法功能强大支持多种图片数据源格式。其函数签名大致如下addImage(imageData, format, x, y, width, height, alias, compression, rotation)其中imageData参数是关键。根据官方文档它可以接受一个URL字符串指向一个图片资源。一个HTMLCanvasElement或HTMLImageElement对象。一个ImageData对象。一个数据URIData URL。当imageData被识别为一个字符串时jsPDF会尝试将其作为一个URL来处理。问题就出在这个URL的处理逻辑上。2.2 路径遍历是如何发生的在浏览器安全模型中file://协议用于访问本地文件系统。通常由于同源策略Same-Origin Policy的限制通过file://协议加载的页面中的JavaScript只能访问与该页面同目录或子目录下的文件这是为了防止恶意网页随意读取用户硬盘。然而jsPDF的addImage方法在解析传入的URL时其内部逻辑未能对file://协议后的路径进行充分的规范化Canonicalization和过滤。攻击者可以构造一个特殊的字符串作为imageData参数传入。例如假设攻击者能够控制PDF中某个图片的“来源”参数他可以传入这样一个字符串file:///C:/Users/Victim/.ssh/id_rsa或者利用路径遍历序列file:///C:/Users/../Windows/win.ini在特定版本的jsPDF中其内部的URL请求逻辑可能会尝试去读取这个路径指向的本地文件。如果这个文件是文本文件如配置文件、密钥、日志jsPDF可能会尝试将其作为图片数据解析。虽然最终会因为不是合法的图片格式而生成失败或产生损坏的PDF但关键在于读取操作本身被执行了。更危险的一种情况是如果结合某些浏览器或特定版本下对file://协议同源策略的宽松实现或者漏洞存在于jsPDF用于获取图片数据的底层XMLHttpRequest或fetch实现中攻击者甚至可能通过构造特殊的请求将文件内容以某种形式如错误信息、数据URI的一部分泄露出来。2.3 与html2canvas组合使用的放大效应搜索热词中提到了“html2canvas 截取整个页面 jspdf”这是非常常见的组合技用html2canvas将DOM元素渲染成Canvas再用jsPDF将Canvas添加到PDF中。典型的代码如下html2canvas(document.body).then(canvas { const imgData canvas.toDataURL(image/png); const pdf new jsPDF(); pdf.addImage(imgData, PNG, 10, 10); pdf.save(report.pdf); });在这个场景下addImage的参数imgData是一个数据URIdata:image/png;base64,...看起来是安全的。但是如果应用逻辑允许用户动态指定html2canvas的渲染目标或者用户输入以某种方式影响了最终生成的imgData攻击面就可能被打开。例如一个允许用户上传“自定义水印图片URL”的功能如果这个URL未经严格过滤就直接被用于addImage就可能触发此漏洞。注意漏洞的具体触发路径和利用条件高度依赖于jsPDF的版本、浏览器的类型与版本、以及应用的具体代码逻辑。并非所有使用addImage的场景都会直接受到攻击。但漏洞的存在意味着存在这样一种潜在的攻击通道。3. 漏洞复现与环境搭建为了深入理解并验证CVE-2025-68428我们需要搭建一个受控的测试环境。请注意所有测试应在隔离的虚拟机或专用测试机上进行切勿在生产环境或个人常用电脑上操作。3.1 测试环境准备我们首先创建一个简单的漏洞测试页面。1. 创建项目目录结构jspdf-lfi-test/ ├── vulnerable.html ├── safe.html └── test-files/ └── test.txt (内容为This is a local test file.)2. 引入有漏洞版本的jsPDF你需要找到一个受CVE-2025-68428影响的jsPDF版本。通常漏洞存在于某个特定版本范围。你可以通过npm安装一个已知的有漏洞版本或者直接从CDN引用一个旧版本。为了演示我们假设一个存在问题的版本可以通过以下脚本引入!-- 在 vulnerable.html 中 -- script srchttps://unpkg.com/jspdf1.5.3/dist/jspdf.min.js/script注此处版本号1.5.3仅为示例实际受影响版本号需根据官方公告确定。最新版本应已修复。3. 编写漏洞测试代码 (vulnerable.html)!DOCTYPE html html head titlejsPDF LFI 漏洞测试危险/title script srchttps://unpkg.com/jspdf1.5.3/dist/jspdf.min.js/script /head body h1不安全的jsPDF图片添加测试/h1 p此页面模拟了一个允许用户输入图片URL来生成PDF的功能。/p label forimageUrl输入“图片”URL/label input typetext idimageUrl size50 valuefile:///./test-files/test.txt / brbr button onclickgeneratePDF()生成PDF/button p idstatus/p script function generatePDF() { const url document.getElementById(imageUrl).value; const statusEl document.getElementById(status); statusEl.textContent 尝试生成PDF中...; statusEl.style.color blue; try { const pdf new jsPDF(); // 关键的危险调用直接将用户控制的字符串传给addImage pdf.addImage(url, JPEG, 10, 10, 50, 50); pdf.save(vulnerable-output.pdf); statusEl.textContent PDF已生成可能已尝试读取本地文件。; statusEl.style.color green; } catch (error) { statusEl.textContent 错误 error.message; statusEl.style.color red; console.error(生成PDF时出错:, error); } } /script /body /html4. 通过本地HTTP服务器访问直接在浏览器中打开file://路径下的HTML文件许多现代浏览器出于安全考虑会严格限制file://协议页面的能力如禁止发起file://请求。因此我们需要一个简单的HTTP服务器来托管这个页面。# 在项目根目录下使用Python快速启动一个HTTP服务器 python3 -m http.server 8080然后在浏览器中访问http://localhost:8080/vulnerable.html。3.2 复现攻击尝试在测试页面的输入框中默认值已经指向了同服务器下的一个测试文本文件test-files/test.txt。点击“生成PDF”按钮。观察结果浏览器控制台 (F12)这是最重要的信息源。你可能会看到类似以下的错误Error: Invalid image format. Data is not a valid base64-encoded image.或者更值得关注的是在Network网络标签页中你可能会看到一个尝试向file:///.../test.txt发起的请求尽管它很可能因为跨协议限制而失败或显示为blocked:csp。生成的PDF很可能是一张破损的图片占位符或者是一个空白页面因为jsPDF无法将文本文件解析为图片。尝试更“恶意”的输入仅用于理解漏洞原理请勿用于真实攻击file:///C:/Windows/win.ini(Windows)file:///etc/passwd(Linux/macOS)../../../../秘密文件.txt(相对路径遍历)关键点复现的成功与否以及能观察到什么现象取决于多个因素jsPDF库的版本只有存在漏洞的特定版本才会执行危险的file://请求。浏览器的安全策略现代浏览器如Chrome、Firefox对从http://页面发起的file://请求有极其严格的限制通常会直接阻止并在控制台显示CSP内容安全策略或跨域错误。这实际上构成了一道重要的缓解防线。应用上下文如果应用本身是以file://协议打开的例如一个本地的Electron应用且配置了宽松的Node集成那么攻击成功的可能性会显著增加。实操心得在实际漏洞挖掘和复现中浏览器的开发者工具尤其是Console和Network面板是你的最佳伙伴。即使攻击被浏览器阻止相关的错误信息和被拦截的请求记录也足以证明漏洞触发点vulnerable point的存在。真正的漏洞利用exploit可能需要更苛刻的条件但证明漏洞存在proof of concept是第一步。4. 漏洞影响范围与严重性分析CVE-2025-68428不是一个可以远程执行代码RCE的“核弹级”漏洞但其潜在影响不容小觑特别是在特定应用场景下。4.1 直接受影响的应用类型客户端PDF报告生成器任何允许用户自定义PDF内容如添加公司Logo、签名图片、水印的Web应用如果用户提供的URL未经严格过滤就直接传递给jsPDF.addImage()则存在风险。离线或混合应用使用Electron、NW.js、Cordova等框架打包的桌面或移动应用。这些应用通常拥有更高的本地文件系统访问权限如果其内部使用有漏洞的jsPDF版本攻击者可能通过注入恶意参数来读取应用沙箱之外的用户文件。内部网络工具运行在企业内网、信任级别较高的管理后台或工具系统。这些系统可能采用较宽松的浏览器安全策略增加了漏洞被利用的可能性。与html2canvas等库的集成场景如前所述如果用户输入能间接影响html2canvas的渲染源或动态生成img标签的src属性最终这个src被捕获并传给jsPDF就可能形成攻击链。4.2 攻击者可能窃取的信息如果漏洞在特定环境下被成功利用攻击者可能读取到系统敏感文件/etc/passwdLinux用户列表、C:\Windows\System32\drivers\etc\hosts主机文件。用户配置文件各种软件的配置文件可能包含服务器地址、端口、弱密码哈希等。密钥与凭证SSH私钥~/.ssh/id_rsa、AWS/GCP等云服务的访问密钥、API令牌文件。浏览器数据如果知道具体路径可能尝试读取浏览器保存的密码、Cookie数据库虽然现代浏览器对此保护很强。商业机密用户本地正在编辑或存储的未加密文档、设计稿、代码等。4.3 严重性评级考量根据CVSS通用漏洞评分系统标准此类漏洞的评分通常会考虑以下因素攻击向量网络通常需要用户访问恶意页面或交互。攻击复杂度高。需要诱骗用户执行特定操作如点击按钮生成PDF并且严重依赖浏览器环境和应用的具体实现。所需权限无攻击者无需任何权限。用户交互需要用户必须触发PDF生成操作。影响范围机密性本地文件内容可能被窃取对完整性和可用性通常无影响。因此它的CVSS基础评分可能在中危Medium范围例如 5.4 - 6.5分左右。但是在Electron等本地应用上下文中的严重性会显著提高可能达到高危High因为本地应用更容易绕过浏览器的file://协议安全限制。5. 修复方案与安全加固实践对于开发者和运维人员来说发现漏洞后最重要的是如何修复和预防。针对CVE-2025-68428修复分为几个层面。5.1 立即行动升级jsPDF库这是最根本、最直接的修复方法。jsPDF官方在获悉漏洞后会在新版本中修复addImage方法对URL的处理逻辑。确定当前版本检查你的package.json或HTML中引用的jsPDF版本。升级到安全版本前往jsPDF的官方GitHub仓库或npm页面查看安全公告确认已修复此漏洞的最低版本例如2.5.1或3.0.0。然后更新你的依赖。# 使用 npm npm update jspdf # 或指定版本 npm install jspdflatest # 使用 yarn yarn upgrade jspdf验证升级升级后重新运行你的测试用例确保功能正常并尝试之前的漏洞复现POC确认攻击已被阻止浏览器应抛出安全错误或jsPDF内部已过滤file://协议。5.2 代码层加固输入验证与过滤即使升级了库良好的安全编码习惯也是必须的。永远不要信任用户输入。1. 严格的输入验证在将任何数据传递给pdf.addImage()之前进行白名单验证。function sanitizeImageSource(input) { // 方案1只允许数据URI (Data URL) if (input.startsWith(data:image/)) { // 可进一步验证MIME类型如 image/png, image/jpeg const mimeMatch input.match(/^data:(image\/\w);base64,/); if (mimeMatch [image/png, image/jpeg, image/gif].includes(mimeMatch[1])) { return input; // 是合法的图片数据URI } } // 方案2如果必须允许URL则进行严格过滤 // 绝对禁止 file:// 协议 if (input.toLowerCase().startsWith(file://)) { throw new Error(Local file URLs are not allowed for security reasons.); } // 可以考虑只允许特定的、受信任的域名HTTP/HTTPS const allowedDomains [cdn.yourdomain.com, trusted-cdn.com]; try { const url new URL(input); if (url.protocol ! http: url.protocol ! https:) { throw new Error(Only HTTP/HTTPS URLs are allowed.); } if (!allowedDomains.some(domain url.hostname.endsWith(domain))) { throw new Error(URL domain is not in the allowed list.); } return input; } catch (e) { // 如果不是合法URL或验证失败则拒绝 throw new Error(Invalid or disallowed image source.); } // 如果以上都不符合返回一个安全的默认图片或抛出错误 return data:image/svgxml;base64,...; // 一个透明的占位图 } // 在使用时 const userInput document.getElementById(userImageUrl).value; try { const safeImageData sanitizeImageSource(userInput); pdf.addImage(safeImageData, JPEG, 10, 10); } catch (error) { console.error(Image source validation failed:, error); // 向用户显示友好的错误信息 }2. 使用Canvas作为中介如果应用场景是允许用户上传图片那么更安全的做法是让用户通过input type”file”上传图片文件在前端使用FileReader读取为Data URL或直接绘制到Canvas再将Canvas的图像数据传递给jsPDF。这样可以完全避免URL字符串的解析风险。document.getElementById(fileInput).addEventListener(change, function(e) { const file e.target.files[0]; if (!file.type.startsWith(image/)) { alert(Please select an image file.); return; } const reader new FileReader(); reader.onload function(event) { const img new Image(); img.onload function() { const canvas document.createElement(canvas); // ... 将img绘制到canvas ... const ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0); // 从canvas获取安全的Data URL const safeDataUrl canvas.toDataURL(image/jpeg); const pdf new jsPDF(); pdf.addImage(safeDataUrl, JPEG, 10, 10); pdf.save(secure.pdf); }; img.src event.target.result; // 这是一个 data: URL }; reader.readAsDataURL(file); });5.3 环境与配置加固内容安全策略为你的Web应用配置严格的CSPContent Security Policy。虽然CSP主要限制脚本、样式等资源的加载源但一个严格的default-src或img-src指令可以阻止浏览器加载file://协议的资源从浏览器层面提供额外防护。Content-Security-Policy: default-src self; img-src https: data:这个策略只允许加载同源的资源以及https:和data:协议的图片。file:协议被明确禁止。Electron应用特殊配置如果你的应用基于Electron务必将nodeIntegration设置为false在WebPreferences中。启用contextIsolation。在webSecurity不为false的情况下谨慎处理本地文件加载。对于需要生成PDF的功能考虑在主进程Main Process中使用Node.js版本的PDF库如pdfkit来处理而不是在渲染进程中使用前端jsPDF。6. 漏洞挖掘与安全测试的启发CVE-2025-68428的发现过程给我们前端安全测试提供了一些经典的思路。6.1 前端LFI的测试点不要以为文件包含只是后端的事。当前端库需要处理资源路径时就是测试点任何接受URL/路径字符串的API如图片加载、音频视频加载、字体加载、脚本动态加载import()、Worker创建、iframe的src等。数据反序列化点如果前端接收后端传来的数据并直接用于构造DOM属性如img.src、a.href需要测试是否可能注入file://协议。客户端模板渲染使用Vue/React等框架时检查是否可能通过用户输入控制v-bind:src或src{userInput}并最终被某个底层库使用。6.2 黑白盒结合的分析方法黑盒测试面向输入在所有用户可控的输入点尝试以下Payloadfile:///etc/passwd../../../../etc/passwdC:\Windows\System32\drivers\etc\hosts\\localhost\c$\boot.ini(Windows UNC路径)各种编码后的变体URL编码、双重编码等。 观察网络请求、错误信息、页面行为变化。白盒审计面向代码直接审查前端代码特别是第三方库的调用方式。在项目中全局搜索addImage、new Image()、fetch、XMLHttpRequest等关键词。查看这些方法的参数来源是否追溯到用户输入。检查是否有对file:、../等字符串的过滤或验证逻辑。6.3 工具辅助浏览器开发者工具Network面板监控所有请求Console面板查看错误和警告Sources面板下断点调试。静态分析工具使用semgrep、CodeQL等工具编写规则扫描前端代码中可能存在不安全路径处理的模式。模糊测试针对接受字符串参数的API使用包含特殊路径序列的随机字符串进行自动化测试。7. 从CVE-2025-68428看客户端安全边界这个漏洞深刻地提醒我们在浏览器中运行的JavaScript并非运行在真空中。尽管有沙箱和同源策略但客户端代码依然可以通过合法API如file://URL、File API、甚至是某些特定扩展与用户的本地环境进行有限交互。安全边界模型需要更新传统的安全模型认为“服务器是受信的客户端是不可信的”。但在现代富客户端应用中前端代码承担了越来越多的逻辑它本身也成为了需要保护的对象防止被篡改同时也可能成为攻击用户本地环境的跳板。因此我们需要建立“服务器不可信用户输入客户端同样不可信用户输入且需警惕客户端对用户本地的潜在影响”的多层防御思维。对于开发者而言这意味着永远在服务端进行最终校验即使前端做了漂亮的验证恶意用户可以直接绕过前端发送请求。对前端第三方库保持警惕定期更新关注安全公告。像jsPDF、html2canvas、Chart.js等常用库都曾曝出过安全漏洞。实施深度防御结合输入验证、输出编码、安全HTTP头如CSP、安全的库版本以及最小权限原则共同构建防护体系。CVE-2025-68428是一个很好的教学案例它展示了即使是一个纯粹的前端库在错误的使用方式或存在缺陷的实现下也可能打开一扇通往用户本地文件系统的窗。修复它不仅仅是一次版本升级更是一次对应用整体数据流和安全边界进行审视的机会。在我自己的项目里经过这次事件我推动团队建立了前端依赖库的安全清单和定期扫描机制任何允许用户输入影响资源加载的地方都必须经过严格的白名单审查这已经成为我们代码审查中的一项硬性规定。
