SQL 注入攻击即便在开发团队严守预编译和输入过滤的情况下，仍可能因遗留代码、第三方组件漏洞或人为疏忽而存在风险。KingbaseES V009R002C014 版本内置的 SQL 防火墙提供了一种更高效的解决方案——从数据库内核层构建主动防御，让恶意 SQL 无处遁形，真正实现'规则先行'。
SQL 注入原理与风险
SQL 注入的原理并不复杂，却极其致命：攻击者将恶意代码伪装成正常输入，欺骗数据库执行非预期操作。
例如，一个登录表单中，用户在用户名栏输入 ' OR '1'='1，后台查询语句可能变为：
SELECT * FROM users WHERE username = '' OR '1'='1' --
由于 '1'='1' 恒为真，攻击者无需密码即可绕过认证，获取所有用户信息。
更严重的情况是附加 DROP TABLE users;--，如果应用层未做好过滤，整张表可能瞬间被清空。
传统防御手段（如预编译）固然有效，但完全依赖开发人员的编码习惯。一旦某个动态 SQL 遗漏了参数化，漏洞便应运而生。金仓数据库 SQL 防火墙直接在数据库内核层'设卡查验'，无论应用层是否有疏忽，所有 SQL 语句都必须经过它的校验才能放行。
三种工作模式
其核心理念很简单：只让'好人'通行，拒绝'坏人'闯入。通过建立合法 SQL 白名单，系统只允许白名单内的 SQL 正常执行，任何不在白名单的语句都会被警告或拦截。
金仓 SQL 防火墙设计了三种工作模式，可以灵活配置：
学习模式：管理员指定需要监控的用户后，系统自动观察并学习这些用户执行的所有 SQL，将它们记录为合法规则。无需手动编写复杂的规则，避免了人为疏漏。
警告模式：正式上线前，可以先开启警告模式。此时，所有 SQL 都会被执行，但若某条 SQL 不在白名单中，系统会发出警报并记录日志。安全管理员可以根据日志微调白名单，确保业务不受影响。
报错模式：经过充分测试后，开启报错模式，真正开启防护。任何不在白名单的 SQL 都会被直接拦截并返回错误，同时写入日志。恶意 SQL 注入的企图将彻底破产。
你可以根据实际场景直接选用不同模式，让防护策略的落地更平滑、可控，最大程度减少对正常业务的干扰。
性能与准确率验证
高拦截准确率
SQL 防火墙会全面检查所有数据库连接执行的 SQL 语句，且无法被绕过，只有白名单内的合法 SQL 可以正常执行。同时，SQL 防火墙直接读取数据库内核解析 SQL 的结果来计算特征值，而非简单匹配字符串。这意味着，即使 DML 语句中的常量千变万化（比如查询不同的用户 ID），特征值仍然稳定不变，不会误判。
为验证 SQL 防火墙的拦截能力，我们通过对 100 万条合法 SQL，和 900 万条非法 SQL 进行多轮实测：
| 指标 | 数值 |
|---|---|
| 非法 sql 总数 | 900 万 |
| 合法 sql 总数 | 100 万 |
| 被检出的非法 sql 数 | 900 万 |
| 被拦截的合法 sql 数 | 0 |
