前几天有个开发组的同事跑来找我说他们项目在例行安全扫描的时候档案上传模块被标记出了“PDF XSS”漏洞。起初他们觉得是不是扫描器误报——一个PDF文件怎么就跟XSS扯上关系了直到我让他打开测试报告里的复现链接浏览器直接弹了个对话框他当场就不说话了。这件事其实挺有代表性的。很多做Spring Boot项目的团队对文件上传的安全认知还停留在“校验扩展名、限制文件大小、扫一下病毒”极少有人会想到PDF这种看似“被动阅读”的文档格式居然能成为脚本执行的载体。更麻烦的是这类问题一旦等到上线后被安全团队或外部白帽子报出来往往已经处在“必须马上修”的状态既没有预留排查时间也没有现成方案可抄。这篇内容就是围绕“Spring Boot项目上传PDF文件时如何系统性地解决PDF型XSS攻击”展开的。我会把PDF为何能执行脚本、在哪些环节会被触发、后端如何清理、输出侧如何防护以及最终可直接套用的代码实现都过一遍。如果你是Java技术栈的开发者或者正在被安全审计报告追着改接口这篇应该能帮你少走不少弯路。1. 为什么PDF会成为XSS的载体先把攻击原理讲透1.1 不要被“PDF”这个外壳骗了它本来就能跑脚本很多人默认PDF就是“电子打印纸”内容是不可变的、静态的。这个印象来源于90%的日常PDF确实只是文字加图片但PDF格式本身从诞生那天起就内置了一套完整的脚本能力叫JavaScript for Acrobat也常被称为“文档级JavaScript”。这套脚本可不是浏览器里那种只能操作DOM的网页JSPDF环境里的JavaScript能访问PDF内部对象模型能做文档级操作翻页、表单赋值、发起网络请求、读取文件元数据、甚至操作注释和附件。这就好比Word文档里的宏PDF里的JavaScript是正经的功能特性只不过恶意的人会拿它干别的事。很多做开发的人第一次听到“PDF里能跑JS”时都会愣一下然后问一句“那跟普通网页XSS有啥区别”区别大了普通网页XSS是攻击者往你的HTML页面里注入脚本靠的是浏览器对HTML的解析PDF XSS则是攻击者构造一个PDF文件让PDF查看器去执行内嵌脚本。一个攻击的是你的服务端输出另一个攻击的是文件本身。1.2 从触发到利用一个恶意PDF在浏览器里经历了什么PDF里的脚本触发点比想象中要多常见的挂载位置有这么几类文档打开动作也就是PDF规范里的OpenAction当用户打开PDF的那一刻就会执行。页面附加动作定义在页面或文档级的事件里翻页、关闭、鼠标按下等时机都可能触发脚本。表单字段事件如果PDF里带表单字段的失焦、点击、变更事件都可以绑脚本。命名目的地与链接动作点击PDF内部链接时触发虽然常见用途是跳转但也可以指向脚本。在Spring Boot项目里典型链路是这样的攻击者上传一个内嵌自动执行脚本的PDF到你的文件服务器然后把下载或预览链接发给受害者受害者浏览器打开链接时服务端返回了application/pdf类型的内容浏览器通常不会弹出“是否下载”而是直接唤起内置查看器。PDF查看器解析文件发现文档级OpenAction绑了一个JavaScript然后执行。脚本运行的上下文是什么如果浏览器通过某个站点的域名来加载这个PDF脚本发起请求时会带上该站点的Cookie或者至少能在浏览器对该域名已有的登录态环境下发起请求。更严重的场景还有利用查看器本身的漏洞做逃逸脚本拿到渲染进程权限去读写本地文件当然这依赖具体的CVE但XSS本身就已经能让攻击者在受害者的浏览器会话中做很多事了。1.3 和其他XSS不一样在哪别拿老套路来防传统服务端XSS防护思路无非是输入过滤、输出转义、加CSP、设HttpOnly。这些在应对HTML注入时确实有效但在PDF型XSS面前各有局限输入过滤你没法用“去掉