网站漏洞整改报告

3月17日凌晨两点，网站监控系统弹出告警——某个后台接口被高频请求刷了整整四十分钟。漏洞查日志发现攻击者用的整改是最笨的遍历方式，挨个猜用户ID，报告居然真让他翻出了三个管理员的网站密码哈希值。其中一个哈希值还是漏洞MD5加固定盐，跟明文没区别。整改这事直接导致我们紧急下线了整个用户模块。报告

漏洞的网站根子不在密码强度，而在接口设计。漏洞当初开发时图省事，整改把用户ID直接塞进URL路径里，报告连个签名校验都没加。网站这种低级失误出现在2024年，漏洞说出去都丢人。整改可事实就是，团队赶版本时砍掉了安全评审环节，测试环境的数据又和生产库做了同步——典型的省小钱亏大钱。

整改分三步走。第一步，所有涉及用户信息的接口强制加Token校验，Token有效期压缩到十五分钟，刷新逻辑用独立的密钥服务。第二步，把密码哈希算法整体迁移到bcrypt，成本高一点，但至少让彩虹表彻底失效。第三步最麻烦——清理历史遗留的备份文件，有台开发机上居然躺着2019年的全量数据库导出文件，权限还是777。

光修自己的系统还不够。我们顺手查了第三方登录SDK，发现它回调地址没做白名单校验，理论上可以伪造登录状态。这问题报给厂商后，对方一周没回复。后来我们自己写了个网关层过滤规则，硬是把回调请求拦下来重定向到统一认证入口。跟外部供应商扯皮的时间，够我们再修十个漏洞。

修复过程中有个意外收获。安全团队用自动化扫描工具重新跑全站，发现之前漏掉的一个上传接口能绕过文件类型检测，攻击者可以传PHP脚本。这个洞其实去年就存在，但一直藏在内测功能后面，没被外部触达。这次整改顺手把它堵上了，也算因祸得福。

上线前做了两轮渗透测试。第一轮找的外部测试机构，报了四个中危问题，其中一个是CORS配置太宽松，允许任意域名跨域读取接口数据。修这个倒简单，把白名单改成动态配置，只放行备案过的域名。第二轮是自己人测的，专门盯着业务逻辑漏洞试，比如越权修改订单状态、用负数金额触发退款——这类问题自动化工具测不出来，必须靠人肉判断。

整个整改周期花了三周，比原计划超了五天。超期的原因是开发团队在改密码重置流程时，发现旧逻辑允许用户通过修改响应包跳过短信验证步骤。这问题牵扯到前端加密逻辑，得重新设计整个验证链路。虽然延期了，但没人抱怨——之前那种随时可能被拖库的状态，谁心里都不踏实。

报告提交后，我特意让运维把服务器的SSH密钥全部轮换了一遍。上次漏洞排查时发现有个离职员工的密钥还挂在授权列表里，这比任何代码漏洞都危险。技术上的坑能填，管理上的洞得靠流程堵——以后每个季度强制做一次权限审计，没商量余地。