，漏洞浏览器弹窗里选中一张JPG，伪造服务器返回“上传成功”。图片整个过程不到两秒，上传但攻击者早就知道——这文件压根不是漏洞照片，是伪造伪造的图片。漏洞就藏在这两秒里。图片 图片上传功能是上传Web应用的日常入口，头像、漏洞商品图、伪造证件照，图片哪都见得到。上传开发者以为校验了扩展名、漏洞Content-Type和文件头就能高枕无忧，伪造可攻击者偏不信邪。图片他们拿记事本改一个文件，后缀改成.png，再塞进几行二进制伪装成PNG头，服务器照样收下。更狠的是，有些系统连文件内容都不看，只认MIME类型——那更简单，用curl发个请求，把Content-Type改成image/png，后端就信了。 我见过一个案例，某论坛的图片上传接口，开发人员用了getimagesize()函数做校验，觉得这函数能读图片尺寸，总该靠谱吧？结果攻击者构造了一个合法的GIF文件，前面是正常图像数据，后面附上PHP代码。服务器把整个文件存下来，扩展名还是.gif，可当Apache配置了将某些扩展名解析为PHP时，这个文件就能执行代码。访问那个GIF链接，服务器直接跑起shell。那叫图片？那叫后门。 还有个经典手法，利用图片解析器的漏洞。攻击者精心构造一个畸形JPEG，里面嵌入恶意数据，当服务器用ImageMagick处理缩略图时，触发CVE-2014-1943这类命令注入漏洞。服务器本想裁剪图片，结果执行了系统命令。图片上传变成了远程命令执行的入口，这比伪造文件本身更致命。 别以为加了白名单就安全。有些系统只允许.jpg，但攻击者上传一个真正的JPEG，在EXIF信息里塞入payload，等后台程序读取EXIF时，SQL注入或XSS就触发了。图片本身没问题，问题出在解析它的代码上。这就是漏洞的核心逻辑——攻击者伪造的不是图片，是信任边界。 防御手段其实不复杂，但执行起来容易走样。最保险的是随机生成文件名，重新编码图片内容，剥离所有元数据，再存储到独立域名。但很多项目图省事，直接保存原文件，只改个名。攻击者赌的就是这种偷懒。 回到那个两秒的上传过程，用户看到的是进度条走完，服务器看到的是字节流。真正的较量发生在字节流和代码之间。伪造图片上传不是单一漏洞，而是一类问题的统称——凡是接收外部文件又不彻底验证的地方，都可能被钻空子。别把文件后缀当防护，那只是第一道门，门后还得有安检。