我们的答案很快以（主要）SQL 功能的形式出现：JSON。在现代，JSON 已成为数据存储和传输的主要形式之一。为了支持 JSON 语法并允许开发人员以类似于他们在其他应用程序中与数据交互的方式与数据交互，SQL 中需要 JSON 支持。

目前所有主要的关系数据库引擎都支持原生 JSON 语法；这包括 MSSQL、PostgreSQL、SQLite 和 MySQL。此外，在最新版本中，所有数据库引擎都默认启用 JSON 语法，这意味着它在当今大多数数据库设置中都很普遍。

由于多种原因，开发人员选择在 SQL 数据库中使用 JSON 功能，首先是提高性能和效率。由于许多后端已经使用 JSON 数据，因此在 SQL 引擎本身上执行所有数据操作和转换会减少所需的数据库调用次数。此外，如果数据库可以使用后端 API 最有可能使用的 JSON 数据格式，则需要更少的数据预处理和后处理，从而使应用程序可以立即使用它，而无需先进行转换。

通过在 SQL 中使用 JSON，应用程序可以获取数据、从数据库中组合多个来源、执行数据修改并将其转换为 JSON 格式——所有这些都在 SQL API 中进行。然后，应用程序可以接收 JSON 格式的数据并立即使用它，而无需处理数据。

在 SQL 中使用 JSON 的数据流，允许开发人员在 SQL 中使用 JSON API 更好地与数据进行交互。

虽然每个数据库都选择了不同的实现和 JSON 解析器，但每个数据库都支持不同范围的 JSON 函数和运算符。此外，它们都支持 JSON 数据类型和基本的 JSON 搜索和修改。

每个主要数据库的 JSON 支持级别。

然而，尽管所有的数据库引擎都添加了对 JSON 的支持，但并不是所有的安全工具都添加了对这个“新”特性的支持（早在 2012 年就添加了）。安全工具缺乏支持可能导致安全工具（在我们的例子中为 WAF）和实际数据库引擎之间的解析原语不匹配，并导致 SQL 语法错误识别。

新的'or'a'='a语法

使用 JSON 语法，可以制作新的 SQLi 有效负载。由于这些有效载荷并不为人所知，因此可用于在雷达下飞行并绕过许多安全工具。使用来自不同数据库引擎的语法，我们能够在 SQL 中编译以下真实语句列表：

• PostgreSQL：'{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb左边的JSON包含在右边的JSON中吗？True.

• SQLite：'{"a":2,"c":[4,5,{"f":7}]}' -> '$.c[2].f' = 7 这个 JSON 的提取值是否等于 7？True.

• MySQL：JSON_EXTRACT('{"id": 14, "name": "Aztalan"}', '$.name') = 'Aztalan' 此 JSON 的提取值是否等于“Aztalan”？True.

配备 JSON 语法

根据我们对 WAF 如何将请求标记为恶意请求的理解，我们得出结论，我们需要找到 WAF 无法理解的 SQL 语法。如果我们可以提供 WAF 不会将其识别为有效 SQL 但数据库引擎会对其进行解析的 SQLi 负载，我们实际上可以实现绕过。

事实证明，JSON 正是 WAF 的解析器和数据库引擎之间的这种不匹配。当我们传递使用不太流行的 JSON 语法的有效 SQL 语句时，WAF 实际上并未将请求标记为恶意请求。

自动化流程

为了展示这种 WAF 绕过有多大，我们决定在最大的开源利用工具SQLMap中添加对 JSON 语法规避技术的支持。 

SQLMap 工具允许用户自动化和攻击目标。

SQLMap 提供了一个自动的 SQL 注入利用过程，允许用户扫描整个站点以查找漏洞。在 SQLMap 识别出 SQL 漏洞后，它提供了识别漏洞类型和识别最适合该特定漏洞的利用技术的能力。 

在正确选择利用漏洞的技术后，SQLMap 甚至为用户提供了自动转储存储在数据库中的信息、枚举表和数据库、泄露密码哈希以及执行一些后期利用技术的能力。

虽然 SQLMap 提供了一些 WAF 规避技术，但我们发现它仍然很容易被大多数现代 WAF 识别，这意味着用户无法在存在 WAF 的情况下使用它。

sqlmap已更新项目地址：https://github.com/sqlmapproject/sqlmap