sql注入漏洞整改报告

上周三晚上十一点，入漏值班手机突然震得桌子嗡嗡响。洞整告警平台显示，改报告我们一个对外查询接口的入漏SQL错误日志在五分钟内暴涨了三百多条——有人往参数里塞了' OR '1'='1。那行代码我太熟了，洞整是改报告十年前外包团队留下的老接口，当时验收文档里写着“已过滤危险字符”，入漏实际上连个参数化查询都没做。洞整

攻击者大概也没想到这么老的改报告接口还挂在公网上。日志显示他先试了单引号，入漏接着是洞整注释符，最后搬出sleep函数想测时间盲注。改报告好在数据库账号权限早就被收紧过，入漏他最多只能读到几张冗余表，洞整但这件事把整个部门都吓醒了——谁也不敢保证其他老接口没有类似问题。改报告

整改从第二天早上开始。第一步不是改代码，而是把所有接口翻出来做“体检”。我们用开源工具扫了一遍全量API，结果比预想中糟糕：三十七个接口里，有十一个存在拼接SQL的情况，其中六个是近两年新写的。新代码也犯这种错，多半是框架自带的ORM太难用，开发图省事直接写了原生查询。这让我有点恼火，但想想自己刚入行时也干过这种事——当时觉得参数化查询多写几个问号太麻烦，直到被甲方爸爸指着鼻子骂“你这不是筛子，是漏勺”。

修复方案分三层。最底层是强制所有新代码走预编译语句，这个靠代码评审卡脖子，没有商量余地。中间层给数据库账号做了最小权限划分，每个接口只能操作自己那几张表，就算被注入了，最多丢点无关紧要的数据。最上层是加了个轻量级WAF，专门拦截常见的注入特征——虽然知道这玩意儿能绕过，但总归能挡住八成脚本小子。

有个插曲挺有意思。整改时发现一个内部管理后台，登录框居然直接拼接了用户输入的账号名。开发解释说是为了方便模糊查询，但登录逻辑里拼SQL，这不是给自己留后门吗？我们当场把那段代码删了，改成先查用户表再比对密码，性能慢了十几毫秒，但安全上踏实多了。后来复盘时有人嘀咕“这后台只有内网能访问”，我直接怼回去：内网就安全了？上次钓鱼邮件不就从内网发出来的？

整个整改花了四天。第四天下午做回归测试时，我特意用sqlmap对着所有接口跑了一遍，看着工具报“所有目标均不可注入”的时候，心里那块石头才算落地。不过说实话，这种安全感是暂时的——昨天又看到新闻，某大厂因为ORM框架的bug被拖了库。安全这东西，从来不是修一次就完事，得天天盯着，像看火一样。

现在我们的代码规范里加了条硬性规定：凡是涉及数据库操作的代码，必须用参数化查询，除非能证明当前场景无法实现——但到目前为止，还没人找到过这样的场景。我猜以后也不会有。