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