学校网站文件上传漏洞排查报告

昨天下午，学校学校官网的网站文件“通知公告”栏目被人挂了个赌博链接。管理员老张第一时间删了，上传但教务处的漏洞人说，那个页面早上的排查访问量比平时多了三倍。这不太对劲。报告

排查是学校从服务器日志开始的。老张把IIS日志导出来，网站文件用Notepad++搜“upload”，上传结果跳出两百多条记录。漏洞多数是排查正常的图片上传，但有一条POST请求特别扎眼——它指向的报告路径是/uploads/2024/09/，可文件名却是学校avatar.php。图片目录里出现PHP文件，网站文件这本身就是上传个信号。老张顺着这条日志往下翻，发现请求来源IP是45.155.205.xxx，归属地显示荷兰，但学校根本没有任何海外访问需求。

问题出在文件上传功能上。学校网站在“教师风采”模块允许老师上传头像，前端只校验了文件扩展名，把.jpg、.png放行。但后端代码里，老张发现写的是if($_FILES["file"]["type"]=="image/jpeg")——只查了MIME类型，没查实际文件内容。攻击者把PHP代码伪装成图片，用Burp Suite拦截请求，把Content-Type改成image/jpeg，文件名改成avatar.php.jpg，就过了第一道关。更糟的是，服务器配置里uploads目录没有禁止执行脚本，Apache默认把.php.jpg当作PHP执行，因为AddHandler规则匹配了.php后缀。就这么个组合，一个webshell就落地了。

老张后来在服务器上找到了那个avatar.php，代码只有三行，用的是eval($_POST['cmd'])。我问他当时怎么想的，他说：“这代码写得比我那届学生的毕业设计还粗糙，但架不住我们漏洞藏得深。”他说这话时有点自嘲，因为去年学校等保测评时，测评机构就提过文件上传要白名单校验，但当时觉得“学校网站没啥价值”，一直拖着没改。

现在得说点具体的排查步骤。第一步，把uploads目录下所有非图片文件全筛出来，用脚本查文件头，比如JPEG文件开头应该是FF D8 FF E0，如果不是，直接隔离。第二步，检查所有上传入口的后端代码，不要只看扩展名，要强制用getimagesize()验证图片真实性和尺寸，并且把文件名改成随机字符串，比如uniqid().'.jpg'，彻底切断攻击者对文件路径的控制。第三步，在uploads目录放一个.htaccess，内容写php_flag engine off，或者用Nginx的话就配location ~* \.php$ { deny all; }。这三步做完，至少能挡住九成的脚本上传攻击。

还有个细节容易被忽略。老张翻日志时发现，攻击者早在两周前就上传过一个test.txt，里面只有一行数字7，当时没人在意。现在回头看，那是在探测目录是否可写。后来那个test.txt被删了，但攻击者已经确认了uploads目录的写入权限。所以排查时别只看攻击后的痕迹，那些“无害”的探测文件往往更早出现。老张说，他以后每周五下午都会手动查一遍uploads目录，就查文件类型和修改时间。

学校网站已经连夜给所有上传功能加了白名单校验，并且把服务器上的PHP版本从5.6升到了7.4——旧版本里那些危险的move_uploaded_file行为在新版本里被严格限制了。老张最后在漏洞报告里写了句大白话：“别觉得网站小就没人惦记，攻击者扫一个网段只要几分钟，扫到学校网站就像捡到软柿子。”