研究Google Scholar上的多态图像XSS
2020年4月30日 - 作者：Lorenzo Stella
几个月前，我在Google Scholar上发现了一个有趣的设计模式。该Web应用程序的多个屏幕通过结合使用location.hash参数和XHR来获取相对URI中的模板片段，并在页面上未经转义地渲染这些片段。
除非平台允许用户上传任意内容并从同一源提供服务，否则这本身并不危险。不幸的是，Google Scholar确实如此，因为它具有图像上传功能。
虽然任何称职的渗透测试人员都会认为利用此问题很简单，但Scholar的图像处理后端会对上传的图像应用不同的转换（例如，剥离元数据并重新处理图片）。在报告漏洞时，Google的VRP团队认为上传携带有效XSS载荷的多态图像是不可能的，并要求提供概念验证（PoC）。
鉴于这项技术的年代，我首先回顾了所有过去"众所周知"的生成多态图片的技术，然后开发了一个测试套件来研究一些最流行的图像处理库（如Imagemagick、GraphicsMagick、Libvips）的行为。这项努力导致发现了一些有趣的注意事项。其中一些方法也可用于隐藏Web shell或JavaScript内容以绕过"self" CSP指令。
EXIF中的载荷
最简单的方法是将我们的载荷嵌入图像的元数据中。对于JPEG/JFIF，这些元数据存储在应用程序特定的标记（称为APPX）中，但大多数图像库不会考虑这些标记。Exiftool是一种流行的编辑这些条目的工具，但您可能会发现在某些情况下字符会被实体转义，因此我改为手动插入它们。
希望Google Scholar保留一些白名单的EXIF，我创建了一个包含1.2k个常见EXIF标签的图像，包括CIPA标准和非标准标签。
虽然这在我的案例中没有成功，但一些EXIF条目至今仍保留在许多流行的Web平台中。在测试的大多数图像库中，从PNG转换为PNG时，PNG元数据总是被保留，而从PNG转换为JPG时，它们总是丢失。
载荷附加在图像末尾（JPG的0xFFD9之后或PNG的IEND之后）
这种技术仅在上传的图像未进行任何转换时有效，因为只有图像内容被处理。
顾名思义，这个技巧涉及将JavaScript载荷附加在图像格式的末尾。
PNG的iDAT中的载荷
在PNG中，iDAT块存储像素信息。根据应用的转换，您可能能够直接将原始载荷插入iDAT块，或者尝试绕过调整大小和重新采样操作。Google Scholar只生成JPG图片，因此我无法利用这种技术。
JPG的ECS中的载荷
在JFIF标准中，熵编码数据段（ECS）包含代表图像数据的最小编码单元（MCU）的原始霍夫曼压缩比特流的输出。理论上，可以将我们的载荷放置在这个段中，但不能保证我们的载荷能在服务器上图像库应用的转换中存活下来。创建一个能抵抗库转换的JPG图像是一个反复试验的过程。
作为起点，我制作了一个具有与转换后图像相同质量因子的"基础"图像。为此，我最终使用了这个具有0长度字符串EXIF的图像。尽管将载荷放置在距离段开头可变偏移处的方法没有成功，但我发现当经过Google Scholar处理时，图像的ECS段的前几个字节如果被0x00和0x14字节的模式分隔，就会被保留。
从这里开始，我花了一些时间找到允许载荷在转换中存活的正确字节序列，因为大多数用户代理不容许页面脚本标签定义中的低值字节。对于感兴趣的人，我们已经提供了嵌入onclick和mouseover事件的图像。我们的图像库测试套件可在Github上找到：doyensec/StandardizedImageProcessingTest。
时间线
- [2019-09-28] 向Google VRP报告
- [2019-09-30] Google VRP要求提供PoC
- [2019-10-04] 提供PoC #1
- [2019-10-10] Google VRP要求提供不同的PoC载荷
- [2019-10-11] 提供PoC #2
- [2019-11-05] Google VRP确认2个端点存在漏洞，奖励6267.40美元
- [2019-11-19] Google VRP发现另一个使用相同技术的XSS，额外奖励3133.70美元