SQL注入漏洞原理

2008年，入漏一名安全研究员在测试某知名电商网站时，洞原在搜索框输入了' OR '1'='1，入漏页面瞬间返回了全站用户订单数据。洞原这不是入漏电影桥段，而是洞原真实发生的攻击事件。SQL注入的入漏可怕之处在于——攻击者只需要一个输入框，就能把整个数据库拖走。洞原

原理其实不复杂。入漏网站后端代码常把用户输入直接拼进SQL语句。洞原比如登录验证，入漏开发者写了SELECT * FROM users WHERE username='$name' AND password='$pass'。洞原当你在用户名栏输入admin'--，入漏实际执行的洞原语句变成了SELECT * FROM users WHERE username='admin'--' AND password='...'。两个连字符把后面的入漏密码验证注释掉了。系统只检查用户名，密码形同虚设。就这么简单。

更狠的玩法是联合查询。攻击者输入' UNION SELECT username,password FROM users--，就能直接读取密码字段。要是数据库权限配置不当，还能用INTO OUTFILE写webshell，直接拿下服务器控制权。我见过一个案例，攻击者通过房产网站的户型参数注入，把整站数据库拖下来，在暗网标价3比特币出售。那家公司的技术负责人后来在行业群里说，他们连备份都没做过。

为什么防不住？很多开发者的思维还停留在"过滤关键字"上。他们过滤了select、union，但攻击者用SeLeCt、/**/UNION/**/绕过。黑名单思路永远有漏洞，因为数据库解析器的容错性太强了。你过滤'，他可以用%27编码绕过。你限制长度，他用分块传输。这场猫鼠游戏里，防守方永远慢半拍。

真正靠谱的方案是参数化查询。用预编译语句把SQL结构和数据分离，数据库先解析指令结构，再绑定参数值。这时候你输入什么，都只是数据，永远不可能变成代码。就像快递员只看运单号，不会因为包裹上写着"炸弹"就爆炸。这方法从2006年就有人推广，但直到今天，我扫描过的国内中小企业网站里，至少六成还在用字符串拼接。

有些老系统改不了代码，那就做输入校验。严格限制输入类型、长度、格式，比如订单号只允许数字，那就用is_numeric()先判断。但别指望这招能彻底挡住高手——他们总有办法绕过正则表达式的盲区。最保险的做法是纵深防御：数据库账号权限最小化，Web应用防火墙兜底，日志监控异常查询。三层防护，才敢说基本安全。

说到底，SQL注入不是技术难题，而是开发习惯问题。每个新手程序员都该被灌输一个观念：永远不要信任用户输入。这句话听起来像废话，但无数血淋淋的漏洞背后，都是这句废话没被当回事。下次写代码时多写一行参数绑定，可能就省下了一次连夜应急响应。

(责任编辑：休闲)