我正在研究和研究不同的SQL注入方法和对策。
检查 HackerOne Hacktivities 告诉我，Web 应用程序仅使用 WAF（例如 Cloudfront、cloudflare、Akamai 等）是不够的，因为黑客使用和构建 WAF 绕过有效负载来克服这些技术进行攻击成功的 。
在 Internet 上搜索Database Firewall关键字，但大多数链接都与 Oracle Database firewall 相关。
因为我目前正在研究 SQL 注入和对策。我很想知道如何研究和开发一个好的数据库防火墙，它可以像代理一样使用主动监控引擎分析 SQL 查询来监控和阻止 SQL 恶意负载。
除了编程语言之外，您还为我提供了哪些方法或技术来编写此类应用程序？您是否让我开始研究和编写低级应用程序防火墙（如 Windows 驱动程序工具包中可用的示例）或应用程序层防火墙？
最后，我们可以使用 Web 应用程序防火墙术语作为数据库防火墙的术语吗？它们之间有什么区别？
提前致谢。
我在 OWASP 推荐这个资源，以及它链接到的演示文稿。https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project
WAF 可以处理多种类型的安全问题，不仅限于 SQL 注入。例如 XSS、CSRF、cookie 中毒等。这些不一定与数据库有关。
如果您使用非 SQL 数据库，数据库防火墙更具体地意味着阻止或至少检测 SQL 注入或等效注入。
检测被篡改的 SQL 很困难。我读过的数据库防火墙产品很难同时避免误报（错误识别不良内容）和误报（未能检测到不良内容）。
Oracle 产品的最新版本已将重点转向白名单。也就是说，承认通过算法检测不良内容太容易出错。相反，训练数据库防火墙，哪些查询对于给定的应用程序是合法的。
这意味着每次更改应用程序代码和添加/删除/修改 SQL 查询时，都必须在部署之前重新训练数据库防火墙，否则合法的查询流量将被阻止。这意味着部署您的应用程序需要更多步骤，这会增加复杂性并延迟部署。
对于需要高度可配置的查询，白名单也是一个问题，例如，如果您的应用程序代码在 WHERE 子句或多个 UNION 子句中附加多个布尔项，或者在列数是动态的情况下运行数据透视查询。
如果您的系统在存储过程中使用动态 SQL，白名单也无效，因为查询的格式可能包含不受信任的内容并且存在 SQL 注入漏洞。这些查询直接在 RDBMS 引擎中执行，从不通过您的数据库防火墙。因此，它们无法被过滤或检测到。
ModSecurity是一个包含一些 SQL 注入检测功能的开源 WAF 示例。它是 Apache http 服务器的一个模块。
Libinjection是一个可以尝试检测 SQL 注入的可嵌入 SQL 解析器的示例。我没有使用过它，但我怀疑它与所有其他基于模式的方法一样存在准确性的不确定性。
我仍然相信防御 SQL 注入的最佳方法是防御性编码。假设恶意内容传入，代码要么拒绝它，要么使用 SQL 查询参数确保内容无害。