学校网站漏洞整改报告

行政楼三楼的学校服务器机房，空调嗡嗡响着，网站像一台老旧的漏洞肺。我盯着屏幕上那个红色的整改“高危”标记，后背有点发凉——学校官网的报告教师登录入口，存在SQL注入漏洞，学校攻击者甚至不需要密码，网站直接往URL里塞一段代码，漏洞就能把整个教师信息库拖走。整改

这个漏洞是报告上周五发现的。当时教务处的学校李老师打电话说，有几个老师的网站账号在半夜批量修改了学生成绩。查日志发现，漏洞攻击者用的整改是典型的union注入，先探字段数，报告再爆表名，最后把成绩表的update权限拿到手。整个过程持续了四十分钟，而我们学校的防火墙日志里，只留下几行看起来像乱码的GET请求。

整改得从根上动刀。第一刀切在代码层——老网站是2015年外包做的，用的还是拼接字符串的SQL写法，参数化查询根本没实现。我带着两个实习生，花了三个晚上把所有涉及数据库的接口翻出来，一共47处，全部改成预编译语句。改完之后拿sqlmap重新测，注入点从“高危”降到了“无”。但这个过程里最让人冒冷汗的是，我们居然在一个留言板功能里发现了存储型XSS漏洞，攻击者可以上传恶意脚本，任何管理员打开后台就会中招——这比SQL注入更隐蔽，因为不触发数据库报警。

第二刀砍向权限体系。原来所有老师账号都是同一个数据库权限，能读能写还能删表。整改后按角色拆分：普通教师只读自己的课程数据，教务处单独一个账号组，数据库管理员权限单独封存，平时锁在密码管理箱里。改完之后我拿教务处的账号试了试，想跨系查个学生信息，直接被拦回来，提示“权限不足”——这个提示语看着就舒坦。

第三刀是应急响应流程。这次漏洞之所以拖了三天才发现，是因为学校没有日志监控。现在我们在服务器上部署了简单的入侵检测脚本，每天凌晨三点自动扫描异常登录、批量数据导出、以及URL里的特殊字符。脚本是开源的，改了两行逻辑，花了不到两百块租了台云主机跑告警。上周四晚上十一点它真的报警了——有人用弱口令尝试登录旧版测试系统，IP来自境外，被自动拉黑。虽然没造成实际危害，但至少证明这套东西在干活。

整改报告交上去那天，分管副校长问了一句话：“以后还会不会出这种事？”我说会，只要还有人用弱密码、还有外包代码没审计、还有员工把账号借给别人用，漏洞就永远有生存空间。但这次我们把该补的补了，该看的看住了，至少下次再有攻击者来，他得先过三道门，而不是像以前那样，门都没锁。

机房空调还在响，但屏幕上的红色标记已经变成了绿色。我把报告存档，顺手在服务器根目录建了个文件，叫“别再偷懒.txt”，里面写着三行字：参数化查询、最小权限、每天看日志。这不是给电脑看的，是给人看的。