1. 项目概述当图片不再是图片在Web安全领域跨站脚本攻击XSS是经久不衰的话题。我们通常认为XSS的载体是HTML、JavaScript或者通过URL参数、表单输入进行注入。但今天要聊的是一种更为隐蔽、更具迷惑性的攻击手法——利用PNG图片文件本身来携带并执行XSS Payload。这听起来有些反直觉图片不是用来显示的吗怎么还能执行代码这正是这种攻击的狡猾之处它利用了浏览器、服务器乃至安全设备对“图片”这一文件类型的固有信任和宽松处理策略。简单来说这种攻击的核心思路是将一个精心构造的XSS Payload巧妙地“藏”进一个完全合法的PNG图片文件的二进制结构中。这个图片文件在视觉上看起来完全正常可以被任何图片查看器打开也能正常上传到绝大多数允许图片上传的网站。然而当这个图片被特定的方式例如被错误的Content-Type头、或某些存在缺陷的解析逻辑加载到网页上下文中时其中隐藏的脚本就会被浏览器解析并执行从而触发XSS攻击。这种攻击方式绕过了传统基于文件后缀名或简单MIME类型检查的防护对开发者构成了新的挑战。2. PNG文件结构与Payload植入点解析要理解攻击如何实现首先得对PNG文件格式有个基本认识。PNG文件并非一堆像素数据的简单堆砌它遵循一个严谨的结构化格式由一系列称为“数据块”的段组成。每个数据块都有其特定的类型和功能。2.1 PNG文件格式速览一个标准的PNG文件以固定的8字节文件头89 50 4E 47 0D 0A 1A 0A开始之后便是串联的多个数据块。每个数据块的结构如下长度4字节表示数据字段的长度。块类型4字节由ASCII字母组成标识块的功能如IHDR是图像头IDAT是图像数据IEND是结束块。数据可变长度存储该块的实际信息。CRC4字节循环冗余校验码用于校验块类型和数据的完整性。关键点在于PNG规范定义了一些关键块如IHDR,PLTE,IDAT,IEND它们是图像显示所必需的。同时也允许存在辅助块Ancillary Chunks例如tEXt文本信息、iTXt国际文本、zTXt压缩文本等。这些辅助块用于存储元数据如图片作者、创建软件、版权信息等它们的存在不会影响图片的正常渲染。2.2 理想的Payload藏身之处tEXt与iTXt块对于攻击者而言辅助块是绝佳的“藏污纳垢”之地。尤其是tEXt和iTXt块。tEXt块用于存储简单的键值对文本信息。其数据部分格式为关键词\0文本字符串。这里的\0是空字符作为分隔符。iTXt块功能更强大支持国际化的UTF-8文本可以包含语言标签、经过压缩的文本等。攻击者可以创建一个tEXt块将关键词Keyword设置为一个看似无害的名字如Comment、Software而将文本字符串Text String部分替换为我们的XSS Payload例如。注意直接将scriptalert(1)/script这样的完整标签放入文本块在大多数情况下不会直接触发XSS因为当图片以标签嵌入时浏览器不会解析tEXt块中的HTML。攻击的成功依赖于后续的“触发场景”。2.3 更底层的植入篡改IDAT数据这是一种更高级、更隐蔽的手法。IDAT块存储着经过压缩通常是zlib压缩的图像像素数据。理论上攻击者可以在压缩的像素数据流中嵌入特定的字节序列这些序列在解压后虽然可能轻微影响图片视觉质量甚至通过精心构造可以做到肉眼难辨但其主要目的是包含可被某些解析器错误解释的字符串。例如在像素数据中嵌入类似scriptalert(1)/script的字符串。当某些服务器端图像处理库如某些旧版本或配置不当的库在解析PNG、试图从图像数据中提取“注释”或遇到错误时可能会将这部分数据以不安全的方式输出到HTML中从而导致XSS。这种方法的隐蔽性极高但实施难度和成功率依赖于非常特定的服务器端漏洞。3. 攻击链构建从上传到触发的完整路径仅仅把Payload放进PNG文件里图片并不会自己“爆炸”。整个攻击链的成功需要一系列条件的配合这通常涉及服务器端和客户端的双重失误。3.1 场景一错误的Content-Type与直接引用这是最常见且经典的触发场景。上传攻击者将携带XSS Payload的PNG文件上传至目标网站。网站的后台仅检查了文件魔数Magic Bytes或后缀名确认它是“真”PNG后便允许上传并将其存储在服务器的某个可公开访问的路径下例如/uploads/evil.png。存储与访问服务器在保存文件时正确地保留了文件内容包括我们植入的tEXt块。触发点网站上存在一个页面会动态地引入用户上传的图片但其引入方式存在缺陷。例如!-- 危险示例服务器错误地设置了Content-Type -- img src/path/to/image_proxy?url/uploads/evil.png /这里的/path/to/image_proxy是一个服务器端的代理或图片处理程序。它的本意可能是为了图片鉴权、压缩或防盗链。但如果这个代理程序在输出图片时错误地将Content-Type响应头设置成了text/html灾难就发生了。攻击发生浏览器收到响应看到Content-Type: text/html便会将响应体作为HTML文档进行解析。当它解析到隐藏在PNG文件tEXt块中的时就会将其当作HTML脚本执行XSS攻击就此触发。3.2 场景二服务器端解析与不当回显某些服务器端的应用程序或API可能会尝试读取图片的元信息Exif、PNGtEXt块等并显示在网页上。如果这个过程没有对读取出的内容进行充分的HTML编码就会导致注入。上传同上。解析网站有一个“图片详情页”它会调用服务器端的库如PHP的getimagesize()配合iptcparse()或Python的PIL/Pillow来提取图片的元数据比如tEXt块中的Comment字段。不安全输出服务器将提取到的Comment内容未经任何过滤或编码直接拼接进HTML响应中。// 危险示例 (PHP) $image_info getimagesize($uploaded_file, $info); if(isset($info[APP13])) { $iptc iptcparse($info[APP13]); $comment $iptc[2#120][0]; // 假设从IPTC获取原理类似 echo div图片描述: . $comment . /div; // 直接输出未编码 }攻击发生如果$comment变量里包含我们预先植入的它就会被原样写入HTML页面并被浏览器执行。3.3 场景三SVG与PNG的“跨界”利用虽然标题聚焦PNG但一个相关的进阶思路是利用浏览器的复杂渲染行为。攻击者可以上传一个实际内容是SVG格式但文件后缀名为.png的文件。如果服务器仅校验后缀名而浏览器又根据文件内容SVG的XML头来实际渲染那么SVG内嵌的JavaScript就可能执行。这属于文件类型混淆攻击与纯PNG植入有所不同但威胁模型相似。4. 实战演练构造一个“带毒”PNG我们以最常用的tEXt块注入为例演示如何手工借助Python创建一个携带Payload的PNG文件。4.1 工具与库准备我们将使用Python的PillowPIL的分支库来处理图片并用struct模块进行二进制数据打包。# 安装所需库 pip install Pillow4.2 分步构造过程import struct import zlib from PIL import Image import io def create_malicious_png(original_image_path, output_path, keyword, text_payload): 创建一个在tEXt块中携带Payload的PNG文件。 参数: original_image_path: 原始干净PNG图片路径。 output_path: 输出的恶意PNG图片路径。 keyword: tEXt块的关键词如Comment必须1-79字节ASCII。 text_payload: 要注入的文本内容即XSS Payload。 # 1. 打开原始图片确保它是PNG格式 img Image.open(original_image_path) if img.format ! PNG: raise ValueError(请提供PNG格式的原始图片) # 2. 将图片保存到字节流获取原始的PNG数据 img_byte_arr io.BytesIO() img.save(img_byte_arr, formatPNG) original_data img_byte_arr.getvalue() # 3. 解析原始数据找到IEND块的位置 # PNG文件以固定的IEND块结束其内容固定为 00 00 00 00 49 45 4E 44 AE 42 60 82 iend_position original_data.rfind(b\x00\x00\x00\x00IEND\xaeB\x82) if iend_position -1: raise ValueError(无效的PNG文件未找到IEND块) # 4. 构建恶意的tEXt块 # 数据部分关键词 空字符 文本Payload chunk_data keyword.encode(latin-1) b\x00 text_payload.encode(latin-1) # 计算数据长度 (4字节大端序) data_length struct.pack(I, len(chunk_data)) # 块类型 (4字节) chunk_type btEXt # 计算CRC32校验码 (针对块类型数据) crc_input chunk_type chunk_data # 注意Python的zlib.crc32默认返回有符号整数需与0xffffffff进行与操作得到无符号值 crc_value struct.pack(I, zlib.crc32(crc_input) 0xffffffff) # 组装完整的tEXt块 malicious_chunk data_length chunk_type chunk_data crc_value # 5. 构造新的PNG数据 # 在IEND块之前插入我们的恶意tEXt块 new_png_data original_data[:iend_position] malicious_chunk original_data[iend_position:] # 6. 写入新文件 with open(output_path, wb) as f: f.write(new_png_data) print(f[] 恶意PNG文件已生成: {output_path}) print(f[] 注入关键词: {keyword}) print(f[] 注入Payload: {text_payload}) # 示例用法 if __name__ __main__: # 使用一个干净的、小尺寸的PNG图片作为模板 create_malicious_png( original_image_pathclean.png, output_pathevil_xss.png, keywordComment, # 常见且不易引起怀疑的关键词 text_payloadimg srcx onerroralert(document.domain) # 一个简短的XSS Payload )4.3 关键步骤解读与注意事项选择原始图片最好使用自己生成的或确信无毒的简单PNG图片。从网上下载的图片本身可能已被污染。关键词选择Keyword必须是1-79字节的可打印ASCII字符。选择像Comment、Software、Author这类常见的元数据关键词能更好地规避简单的安全检查。Payload设计由于tEXt块是文本块Payload中不能包含空字节\x00因为它是关键词和文本的分隔符。Payload应尽量简洁高效。示例中使用了这是一个利用img标签onerror事件的经典向量它不依赖script标签在某些过滤了script的上下文中可能依然有效。插入位置我们将恶意的tEXt块插入到IEND块之前。根据PNG规范IEND必须是最后一个块但在这之前插入辅助块是允许的。这样做兼容性最好。CRC校验必须正确计算并写入CRC值。如果CRC校验失败大多数严格的PNG解析器会认为文件损坏可能导致图片无法加载从而破坏攻击的隐蔽性。实操心得在实际测试中可以先尝试上传一个包含无害文本如test: hello的PNG确认服务器能正常存储和访问。然后再替换为真实的XSS Payload。务必在授权测试的环境中进行。5. 防御策略从开发与运维角度筑墙了解了攻击原理防御的思路就清晰了在每一个可能被利用的环节上设置检查点。5.1 服务器端上传处理强化这是最根本的防线。白名单文件类型校验不要依赖文件扩展名。应使用服务器端语言读取文件头魔数来判断真实文件类型。对于PNG检查文件开头是否是\x89PNG\r\n\x1a\n。import magic # python-magic库 def get_file_mime(file_path): mime magic.from_file(file_path, mimeTrue) return mime # 只允许 image/png, image/jpeg, image/gif 等内容安全扫描与净化剥离元数据在上传后使用图像处理库如Pillow将图片重新保存一遍。这个过程通常会丢弃所有非关键的辅助块包括tEXt,iTXt等。from PIL import Image img Image.open(uploaded_file_path) img.save(sanitized_file_path, formatPNG, optimizeTrue) # 重新保存会清除大部分元数据主动检查解析PNG文件遍历所有数据块检查tEXt、iTXt、zTXt等辅助块的内容。对内容进行严格的合法性检查过滤或拒绝包含、、javascript:、onerror等危险模式的文本。文件存储隔离与重命名将上传的文件存储在非Web根目录下通过后端脚本代理访问。对文件进行重命名如使用UUID避免用户控制最终的文件路径和名称。5.2 服务器端输出编码与Content-Type强制强制正确的Content-Type任何用于提供图片资源的接口必须显式地、强制地设置正确的Content-Type响应头例如Content-Type: image/png。绝对不能让用户输入或文件内容影响这个头。严格的输出编码如果网页需要显示图片的元信息如描述、作者必须对从图片中提取出的所有文本进行HTML实体编码。// 安全示例 (PHP) $comment $iptc[2#120][0] ?? ; echo div图片描述: . htmlspecialchars($comment, ENT_QUOTES, UTF-8) . /div;// 安全示例 (前端) // 假设 imageComment 是从API获取的、服务器已编码过的文本 document.getElementById(desc).textContent imageComment; // 使用.textContent而非.innerHTML5.3 客户端内容安全策略部署强大的Content Security Policy是最后一道也是极其有效的防线。CSP可以告诉浏览器哪些来源的资源是可信的并禁止内联脚本的执行。Content-Security-Policy: default-src self; img-src self data:; script-src self这个策略意味着default-src self默认只加载同源资源。img-src self data:图片只能从同源或data URL加载。script-src self脚本只能从同源加载。即使恶意图片被以text/html的Content-Type加载由于CSP禁止了内联脚本onerror属性和来自非self源的脚本XSS Payload也将无法执行。CSP能极大程度地缓解包括此攻击在内的多种XSS变种。6. 常见问题与排查技巧实录在研究和防御这类攻击时我遇到过一些典型问题和误区。6.1 问题为什么我构造的恶意图片上传后直接通过访问没弹窗排查与解答这是最正常的情况。直接通过标签加载浏览器会将其作为图像资源处理不会解析其中的tEXt块内容为HTML。攻击成功需要满足前面提到的特定触发场景如错误的Content-Type。不要误以为攻击无效这只是因为缺少触发环境。你需要检查网站是否存在图片代理、元数据展示等功能点。6.2 问题使用Pillow重新保存图片后Payload依然存在排查与解答Pillow的默认行为在保存PNG时可能会保留某些tEXt块尤其是Software这类。为了确保清除可以更彻底地操作from PIL import Image, PngImagePlugin img Image.open(evil.png) # 创建一个新的info对象只复制必要的元数据或直接置空 new_info PngImagePlugin.PngInfo() # 可以选择性地添加一些安全的元数据如 # new_info.add_text(Software, Pillow, zipFalse) img.save(cleaned.png, formatPNG, pnginfonew_info)这样生成的cleaned.png将只包含你明确添加的文本块。6.3 问题服务器检查了文件头但攻击还是成功了排查与解答可能的原因检查点被绕过文件头检查代码可能只检查了前几个字节攻击者可以在PNG文件前面添加GIF或JPEG的文件头形成一个“多态”文件。某些解析器可能因为兼容性而误判。确保你的文件类型检查逻辑是严谨的。触发点非上传功能攻击图片可能通过其他途径如SSRF、第三方图片链接引用进入系统。防御需要覆盖所有图片加载入口。服务器端库漏洞使用了存在已知漏洞的图像处理库如CVE相关的库这些漏洞可能导致即使文件头正确库在解析图像数据时也会发生内存破坏或逻辑错误从而被利用。定期更新服务器端组件至关重要。6.4 高级技巧如何检测网站是否存在此类风险手工探测上传一个包含无害tEXt块如Comment: test123的PNG图片。找到该图片的展示页面或元信息展示处。查看网页源代码搜索test123看它是否被原样输出到HTML中。如果是且未被编码则存在风险。尝试通过图片代理链接访问你的图片使用Burp Suite或浏览器开发者工具检查响应头确认Content-Type是image/png而非text/html。工具辅助可以使用类似ExifTool命令行工具批量检查服务器上的图片是否包含可疑的文本块。exiftool -t -r /path/to/uploads | grep -i -E (script|onerror|onload|javascript:|vbscript:)这种通过PNG图片承载的XSS攻击其威力不在于技术的高深而在于思路的巧妙和利用了对“图片”这一可信文件类型的盲点。作为开发者我们必须建立起“所有用户输入皆不可信所有用户上传的文件都是潜在的武器”的安全意识在文件上传、存储、处理和输出的每一个环节都实施纵深防御。从严格的类型校验、内容净化到强制性的安全头CSP缺一不可。安全是一个持续的过程而非一劳永逸的状态。