发现黑客通过sql漏洞入侵攻击

凌晨两点，发现安全监控平台弹出一条告警：某业务系统数据库出现异常批量查询。黑客我点开日志，通过一眼就认出那个熟悉的洞入模式——单引号闭合、OR 1=1、侵攻UNION SELECT。发现有人正在用SQL注入试探入口。黑客

这不是通过扫描器乱撞。请求参数里夹着精心构造的洞入payload，目标明确，侵攻直奔用户表。发现我顺着IP反查，黑客来源是通过境外一台VPS，但中间跳了三层代理。洞入攻击者不慌，侵攻节奏很稳，每轮注入间隔几分钟，像是在手工测试过滤规则。

SQL注入这事，说老不老。OWASP Top 10里它年年上榜，可真正被盯上时，很多系统还是裸奔状态。我见过一个内部管理后台，登录框直接拼接SQL，输入' OR '1'='1就能进。开发图省事，觉得内网没人看。结果呢？攻击者从外网一个SSRF漏洞跳进来，内网就成了后花园。

这次的情况稍微复杂点。目标接口有个id参数，后端用String.format拼进查询语句。我抓了一条payload：1' AND (SELECT SUBSTRING(username,1,1) FROM users LIMIT 1)='a'--。典型的布尔盲注，逐字符猜数据。攻击者不急，因为自动化工具会帮他跑。sqlmap一挂，睡一觉起来库就拖完了。

但有个细节让我停了一下。日志里有个请求返回了500，payload里带了WAITFOR DELAY '0:0:5'。这是时间盲注的探针。攻击者先确认数据库类型是MSSQL，再决定用哪种注入方式。这种分步试探，说明对方不是脚本小子，至少懂点数据库指纹识别。

我拉出WAF规则看了一眼。拦截记录里大部分注入被挡住了，但有一条绕过了：id=1%27%20AND%201=1--。URL编码后，WAF的正则没匹配上。规则写得太死，只认明文单引号，没考虑编码变形。攻击者显然试过几轮，找到了这个缺口。

再往下查，发现更麻烦的事。这个接口的数据库账号权限没做限制，能读sys.tables，也能执行xp_cmdshell。如果攻击者够狠，下一步就是提权拿服务器。我见过真实案例，注入点进去，直接EXEC xp_cmdshell 'whoami'，返回nt authority\system。那一刻，数据库和操作系统之间的墙就没了。

修复其实不复杂。参数化查询一上，注入就废了。但现实是，老系统改不动，新系统赶工期。开发觉得ORM能兜底，可有人偏要手写SQL拼字符串。安全团队提了修复建议，排期排到下个季度。攻击者不会等你排期。

我封了IP，加了条WAF规则，把编码后的单引号也拦了。但心里清楚，这只是堵了一个洞。那个id参数还在，拼接逻辑还在。下次攻击者换个编码方式，或者换个参数，照样能进。

凌晨四点，告警停了。我盯着日志里那条被拦截的payload，想起一句话：SQL注入不是漏洞，是习惯。写代码的人习惯图省事，攻击者就习惯找省事的地方下手。这事没完。