2018年，什文某跨境电商平台的传漏一次促销活动中，安全团队发现有人上传了一个看似普通的什文商品图片。文件名是传漏logo.jpg.php，服务器居然把它当成了PHP脚本执行。什文攻击者用一个文件就拿到了服务器权限，传漏数据库里几十万用户的什文收货地址、手机号全被打包下载。传漏这不是什文电影情节，是传漏文件上传漏洞最典型的利用方式。

文件上传漏洞的什文核心就一句话：网站让用户传文件，但没管住传的传漏是什么、传上去之后怎么处理。什文很多开发者觉得“我只允许传图片”就够了，传漏实际上漏洞往往出在细节里——比如只检查了文件扩展名，什文却没检查文件内容；或者检查了内容，但服务器配置有问题，把图片当脚本跑了。

我见过一个真实案例。某小型CMS系统的头像上传功能，前端用JavaScript限制了只能选.jpg和.png。但攻击者直接抓包改请求，把文件名改成shell.php，后端只检查了Content-Type头，而这个头也是可以伪造的。传上去之后，访问/uploads/shell.php，直接执行任意命令。整个过程不需要什么高深技术，Burp Suite抓个包就行。

为什么这类漏洞这么常见？因为上传功能太普遍了。发帖要传图、实名认证要传身份证、企业注册要传营业执照。每个上传点都是一个潜在入口。更麻烦的是，很多老系统用的是Apache+PHP的默认配置，.php后缀被解析成脚本，而上传目录又恰好有执行权限。一个文件上传漏洞，往往能直接升级成远程代码执行，危害等级直接拉满。

防御这件事，得从几个层面同时下手。白名单是最基本的——只允许.jpg、.png、.gif这些明确安全的扩展名，别用黑名单，因为黑名单永远列不全。然后检查文件内容，比如用getimagesize()函数确认它真的是图片，而不是伪装成图片的PHP代码。文件名也要处理，别直接用用户传上来的名字，生成随机字符串加安全后缀。上传目录必须去掉执行权限，Apache里加一行php_flag engine off，Nginx里配置location ~* /uploads/.*\.php$ { deny all; }。这些措施叠加起来，才能把风险降到可接受范围。

有个细节很多人忽略：文件上传后的存储路径。如果上传目录可以通过URL直接访问，那攻击者传个.html文件就能做钓鱼页面，传个.svg文件就能执行JavaScript偷Cookie。更隐蔽的是，有些系统把上传文件存在Web根目录下，还保留了原始文件名，攻击者传个.htaccess文件就能改变服务器解析规则。这些都不是理论，是实际渗透测试中经常碰到的情况。

我自己的判断是，文件上传漏洞之所以难根治，是因为它横跨了前端、后端、服务器配置、文件系统多个层面。开发者往往只关注自己写的那部分代码，忽略了服务器环境本身的特性。比如PHP的move_uploaded_file函数本身没问题，但配合不安全的文件名和目录权限，就成了漏洞链的一环。安全不是某个函数的事，是整个处理流程的事。

最后说个真实场景。某次代码审计，我看到一个上传功能用了pathinfo($filename, PATHINFO_EXTENSION)来获取扩展名。看起来没问题，但攻击者传shell.php.jpg，获取到的是jpg，通过了检查。然后服务器配置里AddHandler把.jpg也当PHP解析了——因为运维为了省事，加了一堆后缀。两个看似独立的“小问题”叠加，就是一个完整的漏洞。文件上传漏洞从来不是单一原因造成的，它是一连串疏忽的集合。