漏洞攻击案例
2023年夏天，漏洞一个普通的攻击周三下午，某中型企业的案例IT主管老张发现公司官网登录页面响应慢得离谱。他以为是漏洞服务器负载问题，重启了nginx，攻击没效果。案例又清了缓存，漏洞还是攻击慢。直到他打开数据库监控，案例才发现user表里多出了三千多条新记录——全是漏洞同一个邮箱前缀加随机数字。
这是攻击个典型的撞库攻击。攻击者手里有一份从其他网站泄露的案例账号密码组合，拿过来批量往这家公司的漏洞登录接口怼。系统没做登录频率限制，攻击密码错误也没延迟，案例于是几万个请求在半小时内就灌了进来。真正成功的只有几十个，但就这几十个账号里，有三个是财务部的，权限能导出客户发票信息。
老张后来跟我说，他当时后背发凉。因为那三千多条记录不是凭空插入的——攻击者利用了一个SQL注入点，在登录表单的用户名栏里塞了`' OR '1'='1`，直接把查询条件给绕了。更讽刺的是，这个注入点三个月前就有安全扫描报告提示过，但开发排期一直“没空修”。
这类案例我见过太多了。不是攻击手段多高明，而是防守方连最基础的卫生都没做好。你看，撞库要生效，前提是用户在不同平台用相同密码；SQL注入要成功，前提是代码里用了字符串拼接查询。攻击者只是把两件已知的事串起来，像开锁匠试钥匙，一把不行换一把，总有一把能转。
有意思的是，事后复盘时，老张发现日志里其实有异常信号——凌晨三点，同一个IP段连续请求了四千多次登录接口。安全设备也报了警，但值班人员以为是爬虫，直接加了条IP黑名单就完事。黑名单只封了那个IP，攻击者换个代理池继续打，毫无阻碍。
这暴露了另一个问题：很多人把安全当成“装个防火墙、买个WAF”就完事。但真正的漏洞往往不在技术层，而在流程层。没人规定登录接口必须限速，没人要求密码错误必须锁定账号，没人强制关键操作需要二次验证。这些规则不写进代码里，攻击者永远有空子钻。
那天的最终损失不算大——被导出的发票信息大概几百条，没涉及银行卡号。但老张花了两周时间挨个通知用户改密码，还得跟客户解释为什么他们的联系方式会收到钓鱼邮件。他说最难受的不是处理过程，是那种“明明早就能堵住却拖到出事”的憋屈感。
后来他学乖了，把登录接口加了滑动验证和IP限速，数据库查询全部改成参数化语句。上个月我问他最近咋样，他说：“消停多了，但心里总不踏实。你说那些没扫出来的漏洞，什么时候会炸？”我没法回答。安全这行就是这样，防守方要永远正确，攻击方只要赢一次。