让我虚惊一场的 PDF “XSS 漏洞”
手上负责的一个项目收到了一份来自外部的漏洞报告，演示了一个跟鉴权有关的 bug （此 bug 与上传文件无关，这里原本就是允许用户上传文件的）
这个 bug 不是什么疑难杂症，很快就修好了。反倒是报告最底下的补充说明让我大吃一惊：
并且可上传 xss 文件进一步扩大危害，可诱导成员点击进一步获取 cookie 等信息
什么？pdf 居然支持嵌入 js！？而且浏览器还会执行！？
完了完了，居然有这么严重的问题，要知道用户上传的文件都存在一个二级域名指向的静态存储里。要是有哪个 cookie 的 domain 没配好岂不是完蛋
我马上使用 pdf xss 漏洞 等关键字进行搜索，确实找到不少相关文章。随手一翻，最早在 18 年就有提到这个漏洞
好家伙，都多少年了，那浏览器厂商肯定知道这件事呀，为什么浏览器要执行能预览的文件里的 js 啊？
赶紧看看有什么办法解决：
- pdf 文件响应头添加
Content-Disposition: attachment强制下载而不是预览 - 前端接入第三方 pdf 预览组件，避免使用浏览器自带的预览
- 后端预处理 pdf，将其逐页截图后再生成 pdf 替代源文件
- 修改 pdf 去掉其内嵌的 js
看似方案很多，但一个靠谱的都没有
支持上传、预览 pdf 的网站明明那么多，都不怕出事？
……
在我的不懈搜索下，终于找到这篇文章：在线pdf请你谨慎打开
过往的xss很容易联想到session劫持，这次我也是想尝试自己构造一个用例来加深理解，看了官方api和一些博客以后我有点绝望了，似乎没有方法可以读取cookie，session劫持之路暂时搁浅。
突然回想起来，搜到的所有展示这个 xss 漏洞的文章，无一例外都只用到 alert，没有其他更进一步的内容
仔细一看，这些文章展示出来的代码都是 app.alert() 而不是 js 的标准 alert()
结合上文中提到的 官方 api，我似乎明白了什么
我找到一份 Adobe PDF JS Api 文档，里面确实有 app.alert() 相关的内容，但更多的只是与 pdf 交互有关的接口，用 cookie 等关键字也搜不出任何内容。看来确实如上文所说，结论很明显了：
PDF 内的 JS 是被大幅阉割过的，不存在能够获取 cookie 等问题
后来，我们也向安全平台部的同事求证过，得到的答复是：pdf xss 这个问题不用管
至此，结案！
虚惊一场