SQL注入 ✨

在目前的网络攻防环境中，SQL 注入仍然是一种应用广泛、操作简单、且效果显著的攻击手段。防范 SQL 注入攻击，对于防止数据泄露、保护用户隐私和保护 Web 应用的完整性任然是至关重要的一项工作。 Web 应用程序防火墙（WAF）系统，通常被认为是防御 SQL 注入攻击的主要基础设施。但有 WAF 真的就足够了吗？答案当然是否定的。 接下来，首先解释一下 WAF 如何防止 SQL 注入的，然后再展示它可能在什么情况下无法提供足够的保护能力。 WAF 如何防御 SQL 注入 简单来说，WAF 在 SQL 注入类防护中，主要通过监控应用层协议在网络流量中的潜在恶意签名、字符序列来达到防护效果。通过监控和过滤 HTTP GET 和 POST 请求，并解析传入的 SQL 代码片段，WAF 可以识别已知的有害 SQL 语法，并且对相应的恶意的数据包流量进行告警与阻止。 虽然 WAF 可以提供针对 SQL 注入攻击的安全检测和防护，但其有效性取决于它的识别规则。 什么情况下 WAF 会失效 在许多情况下，WAF 可能无法防止 SQL 注入： 未知的攻击模式和特征：WAF 擅长检测已知的攻击模式和特征，面对更复杂或未知的攻击方法则力有不逮。 封装技术：攻击者可以对载荷做针对性处理；使用嵌套编码，或者将恶意请求的部分放在 WAF 检查的字节之外；面对这种封装过后的载荷，WAF不具备识别能力。 配置错误：WAF的识别和防护功能，依赖防护规则的配置，如果规则配置错误，它可能无法提供足够防护能力来保护和抵御更复杂或不常见的 SQL 注入攻击。 更新和调整：随着 WEB 开发技术的更新迭代，有些更新可能会使之前的防护规则失效；如果 WAF 没有定期更新升级相应的规则，将无法提供相应的防护能力。 非网络流量数据：WAF 只能处理来自网络流量的问题，如果问题来自应用程序内部的代码或数据源而不经过网络力量，则 WAF 无法处理 0Day 漏洞：WAF 无法防止 0Day 漏洞利用 JSON 语法：WAF 可能无法识别 SQL 注入载荷中的恶意 JSON 语法内容，从而可以使用此类攻击者绕过 WAF 保护 示例 Claroty 研究人员能够通过在 SQL 注入攻击中使用 JSON 语法绕过 Amazon Web Services（AWS）内置的 WAF。通过将简单的 JSON 语法前置到 SQL 请求的开头，他们可以使用 SQLi 漏洞在云上泄露敏感信息。同样的 JSON in SQL 攻击也对 Cloudflare、F5、Imperva 和 Palo Alto Networks 的 WAF 有效 Reddit 用户对 WAF 测试了几个 SQL 注入负载，发现 WAF 基于某些关键字阻止了一些请求，同时仍然允许其他可疑查询。例如，/?...