网站上传漏洞

一个看似人畜无害的网站上传框，可能是上传整站沦陷的起点。2019年，漏洞我用某开源CMS给客户搭了个企业站，网站后台有个“产品图片上传”功能。上传测试时我随手传了个修改后缀的漏洞PHP文件，服务器直接返回了200 OK。网站那一刻我就知道，上传这站活不过当晚。漏洞

上传漏洞的网站本质，是上传服务器把用户提交的文件当成了可执行代码。攻击者不传图片，漏洞传一个伪装成图片的网站webshell——文件名叫“avatar.jpg”，但内容是上传一段PHP。如果后端只检查了Content-Type或文件扩展名，漏洞那这层伪装就足以穿透防线。更糟的是，很多开发者会把上传目录直接放在Web根目录下，等于把武器递到了对方手里。

我见过最蠢的防护，是在前端用JS校验文件类型。这就像给保险柜装了个塑料锁——用Burp Suite改个请求包，分分钟绕过。还有一次，某系统把上传的文件随机重命名，但没过滤文件内容。攻击者上传一个包含恶意代码的合法图片，再用文件包含漏洞去调用它，照样能执行。你说这算不算掩耳盗铃？

真正的风险点往往不在上传本身，而在“上传后怎么处理”。

拿一个真实案例说：某电商平台的后台允许商家上传营业执照。他们做了扩展名白名单，只允许jpg和png。看着挺安全对吧？但攻击者上传了一个超大尺寸的图片，服务器用ImageMagick处理缩略图时触发了已知的ImageTragick漏洞，直接拿到了服务器权限。你看，白名单防住了文件类型，却防不住处理流程里的坑。

更隐蔽的是逻辑漏洞。有些系统会把上传的文件路径存在数据库里，然后在前端用标签引用。如果开发者没对路径做转义，攻击者就能通过构造文件名注入SQL，或者把路径改成“../../shell.php”。这已经不是上传漏洞了，是上传引发的连锁反应。

我自己修复过最头疼的一个案例，是某政府网站的文件预览功能。他们允许上传PDF，然后用第三方库转成图片展示。攻击者上传了一个恶意构造的PDF，库解析时崩溃，但崩溃前已经把部分内容写进了临时目录。利用这个时间差，攻击者反复上传，最终在临时目录里堆出了一个可执行的PHP文件。你猜怎么着？临时目录的权限是777。

别迷信WAF。我曾经用multipart/form-data的边界值差异绕过某知名WAF——把filename参数放在Content-Disposition之前，WAF只检查了后面的部分。还有一次，我往文件名里塞了2000个空格，后端截断后留下了“.php”，但WAF的正则匹配的是完整字符串，直接放行。这些小把戏，说穿了不值钱，但确实管用。

上传漏洞的根因，不是技术不行，是信任错了对象。你信任了用户上传的文件名，信任了MIME类型，信任了文件内容的“看起来像图片”。但攻击者不按常理出牌。真正的解法只有一个：把上传的内容当作不可信数据，存储和解析彻底隔离。

具体怎么做？存到独立文件服务器，用随机字符串命名，不保留原始扩展名，禁用执行权限，通过CDN分发。然后，在应用层做二次校验——用getimagesize()检查图片的真实格式，用白名单限制处理库的版本。这些步骤不复杂，但能挡住90%的脚本小子。剩下的10%，得靠日志监控和应急响应兜底。

写这篇文章的时候，我又想起了那个2019年的客户。他们后来被黑了一次，数据库被拖走，客户信息泄露，赔了二十万。那二十万，够请一个靠谱的开发者做十次安全审计。但人总是这样，不在坑里摔一跤，不知道疼。