防火墙sql注入攻击与防范

凌晨三点，防火防范某电商平台的注入订单库突然被清空。DBA查看日志时发现，攻击攻击者只在登录框里输入了' OR '1'='1，防火防范就把整个用户表拖走了。注入这不是攻击电影情节——我见过太多小公司以为装了防火墙就万事大吉，结果连最基本的防火防范输入过滤都没做。

SQL注入的注入本质，是攻击攻击者把SQL代码伪装成普通数据提交给服务器。防火墙在这里的防火防范角色很尴尬：它站在应用前面，却看不懂应用内部的注入查询逻辑。你可以在WAF里写一百条规则拦截union select，攻击但攻击者用/*!50000union*/+select就能绕过——MySQL的防火防范注释符里藏着版本号，老版本防火墙根本不认识。注入

有个朋友的攻击公司被注入过三次，每次都是因为开发图省事用字符串拼接SQL。第三次出事时，他们终于把参数化查询提上日程。但改代码要时间，防火墙那边还得顶着。他们试过在Nginx层加正则过滤，结果误杀了一堆含“select”关键词的正常评论。后来换了个思路：在数据库账号上做手脚。应用连接数据库的账号只给增删改查权限，连drop和information_schema都禁掉，这下就算注入成功，攻击者也拿不到表结构。

但别高兴太早。现在的攻击者早就不玩' or 1=1这种老套路了。他们用时间盲注——让数据库执行sleep(5)，通过响应时间差逐字符猜解数据。防火墙对这种低频慢速攻击几乎无感，因为每个请求看起来都像正常访问。我见过最狠的一次，攻击者用脚本每三秒发一个请求，花了整周时间把某政府网站的身份证号全拖走了，日志里全是200状态码。

所以我的判断是：防火墙是必要的地基，但别指望它当天花板。真正要命的是开发习惯。写过十年PHP的人都知道，mysqli_real_escape_string不是万能药——它对宽字节注入就束手无策。最稳妥的办法还是预编译语句，PDO的预处理加上绑定参数，从根上断了拼接的可能。如果你还在用存储过程，记得别把用户输入直接塞进EXEC里，那等于给攻击者递刀。

还有个细节容易被忽略：错误信息。默认的数据库报错会泄露表名和字段名，攻击者拿到这些就像拿到地图。生产环境务必把display_errors关掉，日志里记个时间戳和IP就行。别问我是怎么知道的——有次渗透测试，我靠一个Unknown column 'xx' in 'where clause'的报错，十分钟摸清了对方整个库结构。

说到底，防火墙规则要定期更新，但别迷信规则数量。真正有效的是三层防御：入口处过滤特殊字符，应用层全部参数化，数据库侧最小权限。三层都做扎实了，防火墙才睡得着觉。那些只买设备不调策略的公司，跟把保险柜门开着然后上把挂锁有什么区别？