我正在研究不同的SQL注入方法和对策。
检查HackerOne Hacktivities告诉我，仅使用WAF（例如Cloudfront，cloudflare，Akamai等）的Web应用程序是不够的，因为黑客使用并构建WAF旁路有效载荷来克服这些技术，使攻击成功。
在Internet上搜索了“ 数据库防火墙”关键字，但大多数链接都与Oracle数据库防火墙有关。
由于我目前正在研究SQL注入和对策。我很想知道如何研究和开发良好的数据库防火墙，这种防火墙的作用类似于代理服务器，并具有主动监视引擎来监视和阻止SQL恶意负载的SQL查询。
除了编程语言以外，您还提供哪些方法或技术来编写此类应用程序，并且是否允许我开始研究和编写低级应用程序防火墙（例如Windows驱动程序工具包中的示例）或应用程序层？防火墙？
最后，我们可以使用Web应用程序防火墙术语作为Database Firewall的术语吗，它们之间有什么区别？
谢谢。
答案 0 :(得分：1)
我建议在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子句中附加了多个布尔项，或者在列数是动态的情况下运行数据透视查询。 / p>
如果您的系统在存储过程中使用动态SQL，将白名单也无效，因为查询的格式可能是不受信任的内容，并且具有SQL注入漏洞。这些查询直接在RDBMS引擎内执行，而不会经过数据库防火墙。因此，无法对其进行过滤或检测。
ModSecurity是包含一些SQL注入检测功能的开源WAF的示例。这是Apache http服务器的模块。
Libinjection是可尝试检测SQL注入的可嵌入SQL解析器的示例。我没有使用过它，但是我怀疑它与其他所有基于模式的方法一样，在准确性方面也存在不确定性。
我仍然相信防御SQL注入的最佳方法是防御性代码。假设有恶意内容传入，并使用SQL查询参数通过代码拒绝它或确保内容无害。