网站自查工作总结

上周三凌晨两点，网站我盯着监控后台的自查总结实时日志，发现一条异常请求每秒重复了47次。工作这不是网站攻击，是自查总结网站某个老接口在疯狂轮询数据库。那次自查，工作就是网站从这种“半夜惊魂”开始的。

网站自查这事，自查总结很多人觉得是工作走个过场，填几张表格，网站点几下按钮。自查总结但真干起来，工作你会发现最耗时间的网站不是技术排查，而是自查总结厘清“谁在什么时候改了什么”。我们团队六个人，工作三个月里对主站、三个子域名和两个后台系统做了全量扫描。工具用的是开源的，外加一点自己写的脚本。扫描结果出来那天，光是高危漏洞列表就打印了四页A4纸。

SQL注入点有六个，其中两个在登录接口。说实话，看到这个结果我有点冒冷汗——登录接口是去年为了兼容旧版APP临时加的，当时觉得“内部用，问题不大”。结果它一直挂在外网。修复方案不复杂，参数化查询加输入过滤，两小时改完。但真正让我在意的是，为什么这种临时接口能活一年？没人记得它，也没人负责下线。

权限配置的问题更隐蔽。有个后台管理页面，普通用户登录后看不到入口，但直接输URL就能访问。这属于典型的“界面隐藏式安全”，骗自己。我们花了半天时间把前后端权限校验对齐，又加了一层基于角色的访问控制。测试的时候，我用一个普通账号试了二十多次越权请求，全部被拦截，这才算踏实。

文件上传功能是另一个重灾区。用户头像上传允许jpg、png，但没校验文件头。我试过把一个小型webshell改后缀传上去，居然成功了。修复时加了白名单校验、内容检测和随机重命名。顺带把上传目录的执行权限也关了。这些操作不新鲜，但每次自查都能抓到几个漏网的。

数据备份这块，我们原来每天凌晨三点全量备份一次。自查时模拟了一次恢复，发现备份文件损坏率大概百分之七。原因在于备份脚本没做校验，网络抖动导致文件不完整。后来改成备份后自动校验MD5，失败就重试，同时把备份文件同步到另一个机房。这个改动花了一周，但值。

日志审计以前是关着的，嫌占磁盘。这次开了，保留三十天。结果发现一个内部员工账号在非工作时间频繁导出用户手机号。问了一圈，是运营同事在做活动分析，但没走审批流程。这事说大不大，说小不小。后来加了个规则：导出超过一千条记录必须二次授权。

前端方面，XSS漏洞主要出现在评论区和用户昵称。有个老哥把昵称改成一段脚本，每次有人点他主页就弹窗。修复方案是输出转义加CSP策略。CSP上线后，有几个第三方统计脚本被拦了，又花时间调白名单。麻烦，但必要。

自查过程中最烦的不是技术问题，是沟通成本。开发说“这个接口没人用了”，运维说“防火墙规则不能随便动”，产品说“改这个会影响用户体验”。最后靠一份带截图的漏洞报告和一次半小时的站立会才推动下去。我的经验是：别发邮件，当面聊，拿着证据聊。

现在回头看，这次自查总共修复了二十三个漏洞，下线了四个废弃接口，重写了两个核心模块的权限逻辑。网站响应时间从平均1.2秒降到0.8秒，数据库慢查询减少了六成。但最大的收获不是这些数字，而是建立了一个简单的规矩：任何临时方案必须标注过期时间，到期自动提醒。这比任何扫描工具都管用。

自查不是一劳永逸的事。下个月我们打算做一次针对API接口的专项检查，重点是速率限制和参数校验。工具已经选好了，脚本也在写。如果你也在做类似的事，记住一句话：别信“应该没问题”，跑一遍，看日志，动手试。问题往往藏在你觉得最不可能的地方。