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

学校官网在三月中旬被安全扫描工具扫出了三个高危漏洞，学校其中两个直接指向文件上传模块。网站文件这不是上传理论上的风险——攻击者一旦利用成功，就能直接往服务器扔一个WebShell，漏洞然后整台服务器的排查控制权就到手了。我花了一周时间把这些漏洞逐一复现、工作验证、报告修复，学校这里把过程和结论写清楚。网站文件

先说最严重的上传一个：教师风采栏目的头像上传功能。这个接口只校验了Content-Type头，漏洞也就是排查浏览器声称的文件类型。攻击者用Burp Suite把请求头改成image/jpeg，工作就能上传任意后缀文件。报告我实际测试时传了一个.aspx的学校脚本文件，服务器居然原样保存了，而且路径直接暴露在静态目录下。更离谱的是，上传后的文件名是时间戳加随机数，但扩展名完全没过滤。这意味着任何人只要猜不到文件名，就能通过目录遍历或者信息泄露拿到实际路径。

第二个漏洞出在教务处的成绩单批量导入功能。这里倒是做了扩展名白名单，只允许.xls和.xlsx。但白名单只检查了文件名的最后一个点后面的字符。我构造了一个成绩单.xls.aspx的文件名，服务器居然放行了。原因很蠢——代码里用split(".")取最后一段，但没考虑文件名里可以包含多个点。这个文件上传后，IIS会把.aspx当作可执行脚本解析，直接导致远程代码执行。我本地搭了个IIS环境测试，上传后访问那个URL，服务器真的执行了whoami命令并返回了结果。

第三个问题不是功能缺陷，而是配置疏忽。学校官网用的是一台老旧的Windows Server 2012，IIS 8.0上跑着PHP和ASP.NET两个应用池。文件上传目录的写权限居然给了IUSR账户，而且没有关闭父路径。这意味着攻击者如果先通过某个低危漏洞上传一个.jpg文件，再利用路径穿越把文件写到上级目录，就能绕过目录限制。我在测试时发现，上传接口对文件名做了..过滤，但过滤逻辑只替换了一次，双写....//就能绕过。这个组合拳打下来，防护形同虚设。

修复方案并不复杂，但我做了一些取舍。第一个漏洞直接改成校验文件内容头，用getimagesize()判断真实图片类型，同时把存储目录移到Web根目录之外，改成通过一个独立的下载接口输出图片。第二个漏洞把扩展名判断改成取最后一个点后的子串，并且强制转小写，同时禁止asp, aspx, php, jsp等可执行后缀。第三个问题最麻烦，因为涉及系统层面，我建议管理员把上传目录的脚本执行权限关掉，在IIS里对那个目录单独设置Request Filtering，禁止.asp和.aspx的请求。

修复后我重新跑了三轮扫描，又手动试了十几种绕过方式，包括空字节截断、Unicode编码、超长文件名、双扩展名，全部被拦截了。说实话，这类漏洞在学校网站里特别常见，因为开发时往往只关注功能能不能用，没人想过上传的文件会被服务器执行。但攻击者眼里，每一个上传接口都是通往服务器的一扇门。这次排查让我觉得，安全测试不能只靠扫描器，你得真的站在攻击者角度去琢磨那些“没想到”的细节。