chrome

让我虚惊一场的 PDF “XSS 漏洞”

2607
0
2023-03-30

手上负责的一个项目收到了一份来自外部的漏洞报告,演示了一个跟鉴权有关的 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 这个问题不用管
至此,结案!
虚惊一场

昵称
邮箱
网址