从「亡羊补牢」到「规则先行」：金仓数据库 SQL 防火墙实战解析
SQL 注入是数据库安全最顽固的威胁之一。即便开发团队严格执行预编译与输入过滤，遗留代码、第三方组件或人为疏忽依然可能留下突破口。金仓数据库（KingbaseES）V009R002C014 内置的 SQL 防火墙提供了一种数据库内生的主动防护方案——不依赖应用层代码修复，直接从内核层识别并阻断恶意 SQL，让安全团队从「疲于补漏」转向「规则先行」。
一、SQL 注入原理
SQL 注入就像不速之客通过门缝溜进房子：攻击者将恶意代码伪装成正常输入，诱导数据库执行意外操作。
典型攻击示例
场景 1：绕过登录认证
用户在登录表单输入 ' OR '1'='1 作为用户名，原本安全的查询被篡改为恒真条件，绕过所有认证：
-- 正常查询
SELECT * FROM users WHERE username = 'alice' AND password = 'secret';
-- 注入后：OR '1'='1' 恒为真，直接绕过认证，返回所有用户数据
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'anything';
场景 2：删表破坏
攻击者在 ID 参数中注入 1; DROP TABLE users;--，利用分号执行第二条 DDL 语句：
-- 正常查询
SELECT * FROM users WHERE id = '42';
-- 注入后：分号分隔出第二条语句，整张表被删除
SELECT * FROM users WHERE id = '1'; users;
