文件上传漏洞的文件防御

上个月，朋友的上传公司被脱了库。攻击者没打什么高深漏洞，漏洞就靠一个没设防的文件头像上传接口，传了个PHP webshell上去。上传服务器直接成了别人的漏洞跳板。这事不稀奇，文件但每次发生都让人觉得窝囊——文件上传功能太常见了，上传常见到很多人忘了它是漏洞个敞开的门。

防御的文件第一道坎，是上传后缀名白名单。别用黑名单，漏洞永远别用。文件你堵了php，上传人家换phtml；你堵了phtml，漏洞还有php5、php7、phar。黑名单是猫鼠游戏，你永远追不完。白名单就简单了：图片就只允许jpg、png、gif，文档就只允许pdf、docx。逻辑上先想清楚，这功能到底该收什么文件，然后一刀切，其他全拒。

但白名单也不够。攻击者会改后缀，把php文件改成jpg上传。所以第二道坎是内容校验。别只看扩展名，要看文件头。jpg的开头是FF D8 FF，png是89 50 4E 47。用getimagesize()或类似函数读一下真实格式，对不上就拒绝。这招能挡掉大多数简单伪装。

说到这，得提个细节——文件存储路径。很多人把上传文件直接丢在web根目录下，还带着原始文件名。这等于告诉攻击者“你来啊，文件就在这儿”。正确的做法是：重命名文件，用随机字符串或时间戳加随机数，别保留用户提供的名字。存储目录放到web根目录之外，通过脚本读取并输出。这样即使上传了恶意文件，也没法直接通过URL访问执行。

还有层防御容易被忽略：执行权限。上传目录要关掉脚本执行权限。Nginx里配置location ~ \.(php|pl|py)$ { deny all; }，Apache用。这招是纵深防御——就算前面全被绕过，文件落地了也跑不起来。我见过不少案例，攻击者传了shell上去，结果发现目录里执行不了脚本，白忙一场。

再深入点说，图片处理也是个好办法。很多语言有现成的图片重绘库，比如PHP的GD库。上传的图片，用GD重新采样生成一张新图，丢弃原文件。这样不仅去掉了可能嵌入的恶意代码，还能顺便压缩体积。副作用是动图会变成静态图，但对大多数业务场景来说，这代价可以接受。

对了，别忘了检查文件大小。有人会传个几百MB的“图片”来撑爆你磁盘。限制在合理范围内，超了就拒绝。另外，MIME类型别信浏览器的，那东西随手就能改。用服务端检测到的实际类型为准。

最后说个很多人会踩的坑：二次渲染。有些CMS会对上传的图片做二次处理，但处理后的文件可能保留了原图里的恶意代码。所以校验逻辑要放在最终存储前，而不是上传时。处理完再检查一遍，确认没问题才落盘。

这套组合拳打下来，不敢说百分百安全，但能把攻击面缩到极小。文件上传这功能，本质上是在跟攻击者的创造力对抗。你每多设一道关卡，他就得多花几倍精力绕过。大多数攻击者都是挑软柿子捏，你做到位了，他们自然换个目标。