2023年某国产OA系统被曝出一个SQL注入点，漏洞攻击者构造`id=1 AND 1=2 UNION SELECT ...`就能直接拖走全库用户表。检测厂商的修复修复补丁只做了一件事：把拼接SQL改成参数化查询。三行代码的漏洞改动，背后是检测三十万条数据差点裸奔。

漏洞检测这件事，修复很多团队做得挺敷衍。漏洞装个扫描器，检测跑一遍，修复导出报告，漏洞然后丢给开发说“修一下”。检测开发打开报告一看，修复满屏的漏洞“潜在风险”“建议排查”，连个具体的检测请求包都不给。这种检测等于没做。修复真正有用的检测，得能复现。你得把PoC写出来，证明这个洞确实能打进去，而不是靠规则匹配猜出来的误报。

我见过一个做电商的朋友，他们的优惠券接口有个逻辑漏洞。正常流程是领券时校验用户等级，但并发请求下，校验和发券之间存在时间窗口。攻击者用两百个线程同时打，一个普通账号能领到两百张满减券。扫描器根本扫不出这种问题，因为单次请求完全合法。后来是他们自己的测试同学写了个Python脚本，用`threading`模块模拟并发，才把这个洞挖出来。修复方案也简单，数据库加唯一索引，把“校验+插入”塞进一个事务里。

修复漏洞比检测更考验人。有些洞修得不对，比不修还危险。比如XSS，你把`