文件上传漏洞防御

文件上传漏洞，文件本质上是上传把“用户可控的文件”交给了“服务器上的解释器”去执行。攻击者上传一个 shell.php，漏洞如果Web容器把它当PHP解析，防御服务器就沦陷了。文件防御的上传核心不是“过滤危险文件”，而是漏洞“确保上传内容永远不被当作代码执行”。

我见过太多团队把精力花在扩展名黑名单上——拦.php、防御拦.asp、文件拦.jsp，上传结果攻击者传个.php5、漏洞.phtml或者.htaccess就绕过去了。防御黑名单永远堵不完，文件因为解析器的上传脾气你摸不透。Nginx配错了，漏洞.jpg都能当PHP跑。这就像你锁了前门，但窗户开着，贼照样进来。

真正靠谱的做法，第一层是“存储与执行隔离”。上传的文件一律扔到独立域名或独立目录，且该目录下彻底关闭脚本执行权限。Nginx里写location ^~ /uploads/ { php_admin_flag engine off; }，Apache就RemoveHandler。文件存进去，只是个死数据，谁也别想让它跑起来。第二层，文件名重写。别用用户原始文件名，服务端生成随机字符串，扩展名强制白名单——只允许图片、文档这类安全类型，比如jpg、png、pdf。白名单短，好维护，漏网之鱼少。

第三层是内容校验。光看扩展名不够，要读文件头。JPEG以FF D8 FF开头，PNG有固定签名，PDF有%PDF。用getimagesize()或finfo这类库去识别真实类型，别信Content-Type——那是客户端随便填的。但这里有个坑：图片马。一张合法图片尾部拼接PHP代码，只靠文件头检测拦不住。所以还得配合第一层，让图片马无处执行。再狠一点，用imagecreatefromjpeg()重新编码图片，把多余字节全洗掉。代价是性能，但安全收益实打实。

还有个容易被忽略的点：上传接口的频率限制和权限控制。很多漏洞不是技术多高明，而是后台未授权上传。给上传接口加登录态校验、加验证码、加每分钟次数限制，能挡住大部分自动化攻击。我见过某后台，上传功能没做权限检查，匿名用户直接传了个webshell，管理员还蒙在鼓里。

最后，别把宝押在WAF上。WAF能拦截已知特征，但绕过手法日新月异。有次客户上了WAF，攻击者用multipart/form-data边界混淆，文件名里塞了\x00截断，WAF没识别出来，后端的move_uploaded_file()倒是老实执行了。所以，纵深防御才是正解：存储隔离、白名单、内容校验、权限控制，每层都设卡。

一句话总结我的经验：把上传目录当成“只读仓库”，而不是“可执行区域”。你不需要猜攻击者会传什么，你只需要保证——就算他传了恶意文件，服务器也拿它没办法。这事，比想象中简单，也比想象中容易漏。

本文地址：http://www.79wt.cn/news/1841e1299803.html