下列关于文件上传漏洞 描述正确的是

文件上传漏洞，下列说白了就是关于服务器太信任用户扔过来的文件了。攻击者把一个伪装成图片的文件PHP脚本传上去，服务器不但收下，上传还乖乖执行了——这漏洞的漏洞本质，是描述“文件类型校验”和“文件执行权限”这两道闸门没关严。

我见过最典型的正确案例，某后台头像上传功能只检查了Content-Type头，下列就是关于浏览器自动带上的那个“image/jpeg”。攻击者用Burp Suite截个包，文件把Content-Type改成image/jpeg，上传文件名改成shell.php.jpg，漏洞服务器一看后缀是描述.jpg，内容类型也对，正确直接存进web目录。下列结果呢？攻击者访问这个文件，服务器把.php部分当脚本执行，直接拿到webshell。整个过程不到两分钟，比点外卖还快。

更讽刺的是，很多开发者以为“白名单后缀”就万事大吉。他们只允许.jpg、.png、.gif，但忘了Apache的解析特性——如果服务器配置了AddHandler，一个名为“evil.php.jpg”的文件，在某些老版本Apache里会被当作PHP执行。还有用%00截断的，老版本PHP里“evil.php%00.jpg”会被解析成evil.php。这些坑，都是实战里踩出来的，不是教科书编的。

另一个常被忽略的点是文件内容校验。有些人检查了文件头，比如图片的“FF D8 FF”，但攻击者完全可以在合法图片后面拼接PHP代码。你检查文件头，它确实是JPEG；你检查文件大小，它确实像个正常图片；但服务器一旦把整个文件交给PHP解释器，后面的代码照样跑。这种“图片马”能绕过绝大多数静态检测，除非你重新编码图片，把多余数据彻底剥离。

还有存储位置的权限设置。就算文件上传成功了，如果上传目录没有执行权限，PHP脚本也只是个死文件。但现实是，很多站点把上传目录放在web根目录下，还开了executable权限，等于把刀递到对方手里。正确做法是上传目录和web根目录分离，上传文件用独立域名或子路径访问，并且只给读取权限，不给执行权限。

别以为用云存储就安全。有些对象存储服务默认会解析HTML或SVG，攻击者上传一个带恶意脚本的SVG，用户一访问就中招。或者上传一个包含PHP代码的文本文件，如果后端逻辑里用了include函数去包含这个文件，照样执行。云服务只解决存储问题，不解决业务逻辑漏洞。

说个我自己的测试经历。某次渗透测试，目标站上传功能做了文件类型白名单，还用了随机文件名，看起来挺严实。但我发现它用了本地文件包含漏洞——上传一个合法的txt文件，内容里写“”，然后通过LFI参数去包含这个txt文件。结果呢？txt里的代码被当作PHP执行了。你看，上传漏洞和文件包含漏洞一组合，白名单形同虚设。

所以判断一个上传功能是否安全，别只看它过滤了什么，要看它过滤之后还剩下什么。如果攻击者能控制文件名、文件内容、文件路径中任何一个变量，并且服务器在某个环节对这些数据做了敏感操作，那就有戏。真正的修复方案是三层：第一层，严格白名单后缀加MIME校验；第二层，用GD库或ImageMagick重新编码图片，彻底清除嵌入代码；第三层，上传目录禁止脚本执行，且文件名随机化，不保留用户原始文件名。

文件上传漏洞之所以常年霸榜OWASP Top 10，就是因为它不只是一个技术问题，而是开发者思维漏洞的集合——总以为过滤了就能防住，却忘了攻击者永远在找过滤规则之外的路子。你堵住后缀，他玩解析特性；你堵住内容，他玩包含漏洞；你堵住执行权限，他玩社工钓鱼让你主动上传恶意文件。这活儿，永远在博弈。