网站系统存在安全漏洞自查整改报告
网站系统存在安全漏洞自查整改报告
上周三凌晨两点，系统运维群里跳出一条告警：后台登录接口在十分钟内被尝试了四千多次，存安查整来源IP集中在两个境外网段。全漏我爬起来查日志，洞自发现攻击者已经用弱口令撞进了一个测试账号，改报告虽然权限不高，网站但那个账号居然能访问用户订单表的系统只读接口。这件事让我意识到，存安查整网站的安全防线比想象中脆弱得多。
一、漏洞是怎么被发现的
除了那次撞库告警，我们后来主动做了一轮扫描。工具跑完，结果不太好看：一个三年前上线的文件上传功能，没有校验文件类型，直接允许上传.jsp和.php；另一个是用户中心的重置密码接口，返回信息里带上了手机号前三位和后四位，攻击者可以拿来枚举。最要命的是，数据库连接池的配置文件中，密码是明文写的，而且这个文件被放进了Git仓库的历史记录里。
我找开发聊了聊，他说那个上传功能是早期外包做的，后来没人动过。重置密码接口则是为了“方便用户回忆”，故意返回部分手机号。至于明文密码，他反问我：“内网数据库，有必要加密吗？”这种心态很常见，但恰恰是漏洞的温床。
二、整改动作和踩过的坑
我们先从最急的入手。上传功能加了白名单，只允许jpg、png和pdf，并且把上传目录移到了Web根目录之外。重置密码接口改成统一返回“如果账号存在，验证码已发送”，不再泄露任何用户信息。数据库密码改成了环境变量注入，同时用git filter-branch清理了历史提交里的敏感内容——这一步花了整整一个下午，因为仓库有十几个分支。
撞库那边，我们加了登录失败五次锁定十分钟的策略，并且对测试账号做了强制下线。但这里有个小插曲：锁定策略上线后，有个内部同事因为连续输错密码被锁了，跑来找我抱怨。我只好解释，安全策略对所有人一视同仁，包括自己人。
另外，我坚持让团队把依赖库也扫了一遍。果然，fastjson的版本还是1.2.60，存在反序列化漏洞。升级到1.2.83后，有个老接口报错，因为新版本默认关闭了autoType。开发一开始想回滚，我说不行，宁可改代码也不能留这个口子。最后花了两小时调整序列化方式，问题解决。
三、还没做完的事
漏洞不会一次修完。目前我们还有两个遗留问题：一是后台管理系统的会话超时设成了24小时，太长了，但改短会影响运营人员操作，需要先做个提醒弹窗；二是日志里记录了完整的请求参数，包括用户密码，这个得改成脱敏输出，但涉及日志采集链路，要协调运维一起改。
我给自己定了个规矩：每周五下午抽一小时，用nuclei跑一遍常见漏洞模板，再人工看一遍新增的接口。安全不是一次性的项目，更像是一种日常习惯。上次撞库事件后，我在团队里说了一句话：“别等别人打进来才想起锁门。”现在看，这句话得改成——“锁了门，还得记得定期检查窗户。”
这次自查总共发现7个中高危漏洞，已修复5个，剩余2个在排期中。报告写到这里，不总结什么大道理，只提醒一句：你的网站可能正被人盯着，只是你还不知道。
```