sql注入漏洞修复建议

一个真实的入漏例子：某电商平台在2023年遭遇攻击，攻击者只在搜索框输入了' or 洞修1=1 --，就拖走了整个用户表的复建明文密码。事后排查发现，入漏漏洞根源是洞修研发为了赶上线，把用户输入直接拼进了SQL语句——这操作在2010年就属于低级失误，复建现在依然遍地都是入漏。

修复sql注入，洞修最核心的复建就一句话：**永远不要信任任何用户输入**。不管是入漏搜索框、登录表单、洞修URL参数，复建还是入漏藏在HTTP头里的Referer、Cookie，洞修到了后端一律当恶意样本处理。复建别觉得“我们做了前端校验就安全了”——前端校验是给用户体验用的，不是安全边界。抓个包就能绕过，没人会傻到用浏览器慢慢敲。

第一道防线是参数化查询。拿Java的PreparedStatement举例，SQL骨架先固定好，用户输入只作为参数传进去，数据库引擎自己会处理转义。这招能防住99%的注入，因为SQL语句的结构和用户数据被彻底分开了。Python的cursor.execute("SELECT * FROM users WHERE name=%s", (name,))同理。如果你还在用字符串拼接SQL，别找借口，立刻改。

第二道防线是白名单校验。有些场景参数化查询确实不好使，比如动态排序的字段名、表名，这些没法预编译。那就老老实实做白名单：定义一个允许的字段数组，用户传过来的值必须精确匹配数组里的某一项，否则直接报错。别用黑名单过滤关键字，什么select、union、--，攻击者用注释符、编码混淆、大小写变体就能轻松绕过，黑名单就是个筛子。

第三道防线藏在数据库权限里。很多公司图省事，应用连数据库的账号直接给了DBA权限。这不等于把保险柜钥匙挂门口吗？给应用账号只分配它业务必需的权限——查询用只读账号，写入用单独账号，删表权限永远不给。就算被注入了，攻击者顶多读点数据，搞不了破坏。我见过一个案例，某系统被注入后，攻击者试着执行xp_cmdshell，结果账号权限低得连存储过程都调不了，攻击直接卡死。

还有个细节容易被忽略：错误信息泄露。数据库报错要把完整的堆栈、SQL语句、表结构都吐给前端，这等于给攻击者画了张地图。生产环境务必把详细错误信息关掉，统一返回“系统繁忙”这种废话。开发环境开详细日志，生产环境只留必要的信息，这个切换别忘。

最后说个实操技巧——定期做注入测试。别等出了事才查，用sqlmap这类工具每周自动扫一遍所有接口。扫出来的漏洞别急着修，先复盘：是哪个开发写的？为什么参数化查询没用上？是培训不到位，还是代码评审漏了？修完再扫一遍确认干净。安全这东西，靠的是习惯和流程，不是某次突击。

说白了，sql注入已经存在二十多年了，修复方案成熟得不能再成熟。真正难的不是技术，是让每个写代码的人把“输入不可信”刻进肌肉记忆里。你写下的每一行拼接SQL，都可能成为某个攻击者今晚的突破口。