SQL注入绕过WAF原理与实战：从编码混淆到协议层攻击

1. 项目概述：当WAF不再是铜墙铁壁

在网络安全攻防的战场上，Web应用防火墙（WAF）长久以来被视为抵御SQL注入攻击的一道关键防线。它像一位不知疲倦的哨兵，守在应用入口，过滤着每一个可疑的请求。然而，现实情况是，没有绝对安全的盾牌。很多开发者和安全新手常常陷入一个误区：部署了WAF，就等于给应用上了“万能保险”。直到某天，一个看似无害的请求绕过了所有规则，直接命中了数据库，他们才会惊觉，WAF并非无懈可击。

这个项目标题“WAF拦不住？一篇搞懂SQL注入绕过原理与实战”，精准地戳中了当前安全实践中的一个痛点。它不仅仅是探讨一个技术漏洞，更是对“安全即产品部署”这种惰性思维的挑战。我见过太多项目，在代码评审时发现一堆SQL拼接的“老毛病”，开发者的第一反应往往是：“没事，我们前面有WAF挡着。”这种将安全责任完全外包给边界设备的想法，是极其危险的。WAF的本质是基于规则的模式匹配，它擅长识别已知的、特征明显的攻击载荷，但对于精心构造的、利用了应用本身逻辑或WAF解析差异的绕过手法，其防御效果就会大打折扣。

理解SQL注入绕过WAF的原理，对于不同角色的人意义重大。对于安全工程师和渗透测试人员，这是必须掌握的“矛”，用以评估WAF防护的实际有效性，进行更深入的漏洞挖掘。对于应用开发者和架构师，这是至关重要的“镜”，能让你看清自身代码的脆弱点，明白真正的安全必须构筑在严谨的编码和设计（如使用参数化查询、ORM框架的正确使用）之上，而非依赖外部设备。对于运维人员，这有助于你更合理地配置和调优WAF规则，理解其局限，避免产生虚假的安全感。

简单来说，如果你认为部署WAF后就高枕无忧，或者你在测试中遇到WAF拦截便束手无策，那么这篇文章正是为你准备的。我们将深入WAF的“黑盒”，拆解它如何工作，又如何被绕过，并通过实战案例，让你获得一手对抗经验。

2. WAF工作原理与SQL注入检测逻辑拆解

要绕过一个系统，首先必须理解它是如何工作的。WAF的核心工作原理可以概括为“请求解析-规则匹配-处置动作”这一流程。它不是魔法，其有效性高度依赖于规则的完备性和解析的准确性。

2.1 WAF的规则引擎与检测模式

主流的WAF（如ModSecurity、Cloudflare WAF、阿里云/腾讯云等云WAF）通常采用基于正则表达式（Regex）的规则集进行检测。这些规则由安全社区（如OWASP ModSecurity核心规则集）或厂商维护，包含了成千上万条模式，用于匹配SQL注入、XSS、文件包含等攻击特征。

例如，一条简单的检测SQL注入的规则可能会匹配 UNION SELECT 、 OR 1=1 、 ' （单引号）、 -- （注释符）等关键字和特殊字符。当HTTP请求（包括URL参数、Body、Cookie、Header）经过WAF时，其内容会被提取并与这些规则进行逐条匹配。一旦匹配成功，WAF就会根据预设策略执行动作，通常是拦截（Block）或告警（Alert）并记录日志。

然而，这种基于特征匹配的机制存在几个固有弱点：

1. 误报与漏报的平衡 ：规则如果写得过于宽泛（例如，简单匹配 select 和 from ），会导致大量正常业务请求（如搜索功能）被误拦截，影响业务。因此，规则往往需要结合上下文（如参数位置、长度）进行优化，但这又可能给攻击者留下绕过空间。
2. 对编码变形的识别能力 ：攻击载荷可以通过各种编码（URL编码、HTML实体编码、Unicode编码、多重编码）来伪装。WAF是否能在匹配前进行正确的多层解码，直接决定了其防御能力。
3. 协议解析一致性 ：WAF和后台Web服务器（如Nginx、Apache）、应用框架（如PHP、Java Spring）对HTTP协议的解析可能存在细微差异。攻击者可以利用这些差异，构造出WAF解析为一个无害请求，但后端服务器解析为恶意SQL语句的“畸形请求”。

2.2 SQL注入的常规检测与拦截点

WAF针对SQL注入的检测通常关注以下几个层面：

• 关键字检测 ： SELECT , UNION , INSERT , UPDATE , DELETE , DROP , FROM , WHERE , OR , AND 等。
• 运算符与逻辑检测 ： = , > , < , LIKE , 1=1 , '1'='1' 等。
• 注释符检测 ： -- （及其变体 --+ 、 -- ）， # ， /*...*/ 。
• 特殊字符检测 ：单引号 ' 、双引号 " 、反引号 ` 、分号 ; 等。
• 函数与语句检测 ： sleep() , benchmark() , database() , version() , information_schema 等。

一个典型的拦截场景是：攻击者提交参数 id=1' UNION SELECT 1,2,3--+ ，WAF的规则引擎会同时匹配到单引号 ' 、关键字 UNION SELECT 和注释符 --+ ，从而触发拦截。

注意 ：这里存在一个常见的认知偏差。很多人以为WAF是“语义理解”的，它能理解这是一条完整的SQL注入语句。实际上，绝大多数WAF只是进行“模式匹配”，它看到的是字符串中出现了黑名单里的特征片段。这就为“拆解”和“变形”攻击载荷提供了可能。

3. 主流SQL注入绕过WAF的原理与手法详解

理解了WAF的检测逻辑，我们就可以系统地梳理绕过手法。这些手法本质上是利用WAF规则集或解析引擎的“盲点”，让恶意SQL语句在WAF眼中“看起来不像”攻击载荷。

3.1 编码与变形绕过

这是最基础、也最常用的一类手法，核心思想是改变攻击字符串的表现形式，使其不匹配WAF规则，但在后端被正常解码还原。

1. URL编码与多重编码 ：

   • 原理 ：WAF可能只做一次URL解码，或者解码顺序与后端不一致。
   • 示例 ： UNION SELECT 可以被编码为 %55%4e%49%4f%4e %53%45%4c%45%43%54 。甚至进行双重编码： %2555%254e... 。如果WAF只解码一次，看到的是 %55%4e... 这个看似乱码的字符串，可能不会触发关键字规则，而后端应用解码两次后，得到了原始的攻击语句。
   • 实战技巧 ：对关键空格、括号、等号进行编码。例如空格可以用 %20 、 + 或 /**/ （内联注释）代替。 = 可以用 LIKE 、 RLIKE 或 REGEXP 运算符替代，或者使用 <> （不等于）进行逻辑构造。

2. Unicode编码与规范化问题 ：

   • 原理 ：某些Unicode字符在标准化（Normalization）后，会变成另一个字符。例如，全角字符（在某些语境下）可能被后端转换为半角。
   • 示例 ：使用全角单引号 ＇ （Unicode: FF07）代替半角单引号 ' （ASCII: 27）。一些WAF的规则可能只匹配半角字符，而数据库或应用层在字符串处理时，可能将全角字符视为普通字符，或者在比较时进行了隐式转换，从而闭合了SQL语句。
   • 实战技巧 ：在输入点尝试插入 %c0%27 、 %bf%27 等特殊的UTF-8编码序列。在某些旧的、配置不当的数据库连接层（如PHP的 mysql_real_escape_string 配合错误字符集），这些序列可能被错误解析，导致单引号逃逸。

3. HTML实体编码 ：

   • 原理 ：如果参数值在后续处理中会经过HTML解码（例如，先存入数据库，再被另一个页面读取并输出），那么可以提前将攻击载荷进行HTML实体编码。
   • 示例 ： ' 编码为 ' 或 ' 。当这个值被插入到另一个动态SQL查询的上下文中并被HTML解码器处理后，就会还原为单引号。这常用于二阶SQL注入。

3.2 语法混淆与等价替换

这类手法不改变字符本身，而是改变SQL语句的书写方式，利用数据库SQL语法的灵活性来绕过基于固定字符串匹配的WAF规则。

1. 内联注释（ /*!...*/ ） ：

   • 原理 ：MySQL特有的“可执行注释”。注释中的内容会被MySQL服务器执行，但其他数据库或简单的字符串匹配器会将其视为注释。可以用来拆分关键字。
   • 示例 ： UNION/*!SELECT*/1,2,3 。WAF的规则可能匹配连续的 UNION SELECT ，但被 /*!*/ 隔开后，规则就失效了。更高级的用法是 /*!50000UNION*/ /*!50000SELECT*/ ，其中 50000 表示在MySQL版本大于等于5.00.00时才执行。
   • 实战心得 ：这是MySQL环境下最强大的绕过工具之一。不仅可以拆分关键字，还可以在注释中插入任意字符干扰匹配，如 U/**/NI/**/ON SE/**/LECT 。

2. 空白符与注释符变体 ：

   • 原理 ：SQL语句中的空白符可以用多种方式表示。
   • 示例 ：
     • 换行符： %0a (LF), %0d (CR)
     • 制表符： %09 (Tab)
     • 括号： () 本身也可以在某些位置起到分隔作用
     • 特殊注释： -- - （注意末尾空格）、 # 、 ;%00 （空字节截断，在某些特定环境下有效）
   • 技巧 ：将 UNION SELECT 写成 UNION%0aSELECT 或 UNION%09SELECT%0aFROM ，可能绕过一些简单的正则表达式 /\bUNION\s+SELECT\b/i 。

3. 关键字等价替换与大小写变换 ：

   • 原理 ：WAF规则可能是大小写敏感的，或者没有覆盖所有等价写法。
   • 示例 ：
     • 大小写混合： UnIoN SeLeCt
     • 使用数据库特定函数或语法：用 || 连接字符串代替 CONCAT() ；用 LIKE 代替 = ；用 SUBSTR() 代替 SUBSTRING() 。
     • 信息获取场景 ： version() 可以用 @@version (MySQL) 或 SELECT @@GLOBAL.version_comment 替代。 database() 可以用 schema() 替代。

3.3 协议层与请求构造绕过

这类手法攻击的是WAF与后端Web服务器在解析HTTP请求时的差异，属于更高级的绕过技术。

1. 参数污染（HPP） ：

   • 原理 ：HTTP标准允许同一参数名出现多次（如 ?id=1&id=2 ），但不同的服务器处理方式不同。可能取第一个值、最后一个值，或将所有值合并为数组。
   • 示例 ：构造请求 ?id=1&id=2' UNION SELECT 1,2,3--+ 。如果WAF只检查第一个 id=1 （干净），而后端应用（如PHP的 $_GET[‘id’] ）取最后一个值 2' UNION... ，则攻击成功绕过。
   • 实战步骤 ：在测试任何参数时，都尝试重复该参数名，赋予不同的值，观察响应差异。Burp Suite的“Param Miner”等插件可以辅助自动化测试。

2. 分块传输编码（Chunked Transfer Encoding） ：

   • 原理 ：将请求体分块发送。一些WAF可能为了性能，不会完整地重组和解析分块数据，而是直接基于原始数据块进行匹配，这可能导致攻击载荷被拆分后无法被识别。
   • 示例 ：将 UNION SELECT 拆分到两个不同的数据块中发送。WAF在第一个块看到 UNI ，第二个块看到 ON SELECT ，单独看都不匹配规则。但后端服务器会正确重组得到完整的恶意语句。
   • 操作要点 ：这需要手动修改HTTP请求头，添加 Transfer-Encoding: chunked ，并按照分块格式构造请求体。通常用于POST请求的Body绕过。工具如Burp Suite的“Chunked”插件可以简化这个过程。

3. 畸形请求头/方法 ：

   • 原理 ：利用WAF与后端对非标准HTTP方法、特殊头字段或格式错误的请求的解析差异。
   • 示例 ：
     • 使用 GET /index.php?id=1 被拦截，但换成 POST /index.php?id=1 （即使没有Body）可能绕过，如果WAF的规则只关联了GET方法。
     • 添加一些特殊的、可能被WAF忽略的Header，如 X-Forwarded-For: 127.0.0.1' ，如果应用错误地将该头值用于SQL查询且WAF未检查该头部。
     • 构造畸形的 Content-Type ，如 Content-Type: application/x-www-form-urlencoded 与 multipart/form-data 的混淆，可能导致WAF解析参数位置错误。

3.4 基于时间与逻辑的盲注绕过

当直接的错误回显和联合查询被WAF封死时，盲注（Boolean-Based / Time-Based）是主要手段。绕过WAF对盲注的检测，关键在于让请求看起来“正常”。

1. 延长延迟时间与随机化 ：

   • 原理 ：WAF可能有规则检测短时间内密集的、带有 sleep() 或 benchmark() 函数的请求。通过延长每次请求的延迟时间（如从5秒增加到30秒），并加入随机等待，可以降低被频率规则或时间特征规则命中的概率。
   • 示例 ：不使用 SLEEP(5) ，而使用更隐蔽的 SELECT COUNT(*) FROM information_schema.tables A, information_schema.tables B, information_schema.tables C （笛卡尔积产生计算延迟），或者结合 IF() 和 BENCHMARK() 。

2. 拆分布尔逻辑 ：

   • 原理 ：将一次判断拆分成多次请求，利用应用逻辑的“记忆性”（如Cookie、Session状态）来组合结果。
   • 示例 ：攻击目标：判断数据库名的第一个字母是否为‘a’。常规Payload： id=1' AND SUBSTR(database(),1,1)='a'--+ 。绕过思路：先请求一个设置标记的页面（如 ?action=set&value=1 ），该页面将 SUBSTR(database(),1,1)='a' 的结果（真/假）以某种形式（如一个特定的Session变量）记录下来。然后，再请求另一个正常业务页面（如 ?id=1 ），该页面的输出会根据之前的标记有所不同。通过对比两次响应，间接推断出布尔值。这完全避开了在单个请求中携带明显的SQL比较语句。

4. 实战演练：手工构造绕过Payload的全过程

理论需要实践来巩固。我们假设一个目标：一个存在数字型SQL注入漏洞的URL http://target.com/news.php?id=1 ，但前端部署了某云WAF，直接使用 id=1 AND 1=1 就会被拦截。

4.1 信息收集与WAF指纹识别

在开始绕过前，我们需要知道面对的是什么WAF。

1. 触发拦截 ：首先发送一个明显攻击 id=1 AND SLEEP(5) 。预期会被拦截，返回403或一个特定的阻断页面。
2. 观察响应 ：仔细查看拦截页面的源代码、HTTP响应头。常见的WAF会在Header中留下指纹：
   • X-Powered-By: WAF/2.0
   • Server: cloudflare
   • X-Protected-By: Mod_Security
   • 页面内容中可能包含 Blocked by ModSecurity , Powered by Safe3 , 360WZB 等字样。
3. 使用工具辅助 ：使用 WAFW00F 、 Nmap 的 http-waf-detect 脚本等工具进行自动化识别。例如，在Kali Linux中： wafw00f http://target.com 。

识别出WAF类型（例如Cloudflare）后，我们可以去搜索该WAF已知的绕过技巧或规则特性。

4.2 逐步试探与Payload构造

我们的目标是让 id=1 AND 1=1 这个逻辑永真条件能够正常执行并返回与 id=1 相同的结果。

步骤一：基础绕过尝试

1. 尝试URL编码： id=1%20AND%201=1 （编码了空格和等号）。可能依然被拦截，因为WAF会解码后匹配。
2. 尝试内联注释（如果是MySQL）： id=1 /*!AND*/ 1=1 。发送请求。
3. 观察响应：如果页面正常返回，说明 AND 关键字被成功拆分绕过。如果被拦截，尝试更复杂的注释： id=1 /!50000AND/ 1=1 。

步骤二：绕过等号与空格

1. 假设 AND 被绕过，但 = 仍被检测。尝试用 LIKE 替代： id=1 /*!AND*/ 1 LIKE 1 。 LIKE 在数值比较时，如果两边都是数字且无通配符，效果等同于 = 。
2. 空格可以用注释符 /**/ 代替： id=1/**/AND/**/1/**/LIKE/**/1 。
3. 现在Payload变为： id=1/**/AND/**/1/**/LIKE/**/1 。发送测试。

步骤三：构造完整的联合查询绕过 假设我们需要进行联合查询注入，获取数据库版本。

1. 常规Payload： id=1 UNION SELECT 1,@@version,3
2. 分步绕过：
   • 拆分UNION SELECT ： id=1 /*!UNION*/ /*!SELECT*/ 1,@@version,3
   • 处理 @@version ：可能被识别。尝试函数 version() ，并用注释拆分： /*!version*/() 。或者使用十六进制编码版本信息字符串，但这里需要先知道值，不适用。可以尝试 /*!50000@@global.version_comment*/ 。
   • 最终尝试 ： id=1 /*!UNION*/ /*!SELECT*/ 1,/*!50000@@global.version_comment*/,3
   • 进一步变形 ：如果 SELECT 被严格检测，可以尝试大小写混合+内联注释： id=1 /*!uNiOn*/ /*!sElEcT*/ 1,version(),3
   • 利用参数污染 ：同时发送两个参数： ?id=1&id=2 /*!uNiOn*/ /*!sElEcT*/ 1,version(),3 。观察后端处理哪一个。

步骤四：利用协议特性（进阶） 如果上述方法均无效，考虑使用Burp Suite进行协议层攻击。

1. 将请求方法从GET改为POST，但参数仍放在URL中（ POST /news.php?id=1 UNION SELECT... ）。
2. 尝试添加无关的Header头，如 X-Originating-IP: 127.0.0.1 。
3. 使用分块传输编码（Chunked Encoding）发送POST Body，即使原接口是GET，也可以尝试发送一个带有Body的GET请求（非标准，但某些服务器可能处理）。

4.3 自动化工具辅助绕过

手工构造效率低，可以借助sqlmap等工具的强大 tamper 脚本和引擎。

1. 使用sqlmap的tamper参数 ：sqlmap内置了数十个用于绕过WAF的tamper脚本，它们自动应用各种编码和混淆技术。

   sqlmap -u "http://target.com/news.php?id=1" --tamper=space2comment,equaltolike,charencode --random-agent --level=3 --risk=2
   

   • --tamper=space2comment,equaltolike,charencode ：依次应用将空格替换为注释、等号替换为LIKE、字符编码的脚本。
   • --random-agent ：随机化User-Agent，避免被基于Agent的简单封禁。
   • --level 和 --risk ：提高检测等级和风险，尝试更多Payload。
2. 组合tamper脚本 ：可以编写自定义的tamper脚本，将多种绕过技术组合。例如，先base64编码，再插入随机注释。
3. 注意 ：自动化工具虽然强大，但噪音大，容易被封IP。在授权测试中，应结合手工测试的精准和自动化工具的全面。

实操心得 ：绕过WAF是一个“猫鼠游戏”和“心理博弈”的过程。没有一成不变的方法。最关键的是 耐心和观察 。每次修改Payload后，都要仔细对比拦截页面和正常页面的区别（大小、响应时间、某个HTML标签内的细微差异）。有时，一个看似被拦截的请求，其实已经执行成功，只是WAF返回了一个伪装成正常页面的拦截页，需要你火眼金睛去识别。

5. 防御视角：如何构建真正有效的SQL注入防护体系

作为一名防守方，了解攻击手法是为了更好地防御。仅仅依赖WAF是远远不够的，必须建立纵深防御体系。

5.1 代码层：根治之道

这是最根本、最有效的防线。

1. 使用参数化查询（预编译语句） ：这是防御SQL注入的“银弹”。无论是Java的PreparedStatement、Python的DB-API的 execute 、PHP的PDO，还是.NET的SqlParameter，其原理都是将SQL语句的结构（模板）与数据（参数）分开发送给数据库。数据库先编译语句结构，再将参数作为纯数据处理，从根本上杜绝了数据改变语句结构的可能。
   • 错误示例（拼接） ： String sql = "SELECT * FROM users WHERE id = " + userInput;
   • 正确示例（参数化） ： String sql = "SELECT * FROM users WHERE id = ?"; PreparedStatement stmt = conn.prepareStatement(sql); stmt.setInt(1, userId);
2. 使用安全的ORM框架 ：如Hibernate（Java）、Entity Framework（.NET）、SQLAlchemy（Python）、Eloquent（PHP）。它们通常内部使用参数化查询。但 务必注意 ：不当使用ORM也可能导致注入，例如使用原生SQL拼接（ createNativeQuery ）或一些框架的“模糊查询”方法如果处理不当。
3. 严格的输入验证与过滤 ：在参数化查询的基础上，进行白名单验证。例如，对于 id 参数，确保它是整数： intval() 、 Integer.parseInt() 。对于排序字段名，只允许特定的几个值（如 name , time ），而不是直接拼接。
4. 最小权限原则 ：数据库连接账户不应使用 root 或 sa 等高权限账户。应根据应用需要，创建仅具有必要权限（如 SELECT , INSERT ）的账户，避免攻击者利用注入点执行 DROP TABLE 或 LOAD_FILE 等危险操作。

5.2 WAF层：正确配置与调优

WAF应作为代码安全之后的补充检测和虚拟补丁层。

1. 启用学习模式与精细调优 ：部署WAF后，先运行在“学习”或“检测”模式下一段时间，收集正常业务流量。根据日志，将误报的正常请求加入白名单，避免影响业务。
2. 自定义规则 ：针对自身业务特点，编写自定义防护规则。例如，如果某个接口只接受特定格式的JSON，可以编写规则严格检查 Content-Type 和参数结构。
3. 定期更新规则库 ：及时更新WAF的规则库，以应对新出现的攻击手法。
4. 理解WAF的局限 ：明确告知团队，WAF无法防御逻辑漏洞、已授权的恶意操作、以及针对加密通道（HTTPS）内流量的攻击（虽然WAF通常能解密）。不能因为有了WAF就放松代码安全审计。

5.3 架构与运维层

1. Web应用与数据库分离 ：确保数据库服务器不直接暴露在公网，只允许特定的应用服务器IP访问。
2. 定期安全扫描与渗透测试 ：使用DAST（动态应用安全测试）工具定期扫描，并聘请专业的安全团队进行黑盒/白盒渗透测试，主动发现漏洞。
3. 安全开发生命周期（SDL） ：将安全要求融入需求、设计、编码、测试、部署的全流程。对开发人员进行持续的安全编码培训。

6. 常见问题与排查技巧实录

在实际的渗透测试和防御加固工作中，会遇到各种具体问题。这里记录一些典型的场景和解决思路。

Q1：我手工测试发现一个注入点，但一上sqlmap就被WAF封IP，怎么办？ A1：这是自动化工具的“副作用”。可以采取以下策略：

• 降低请求频率 ：使用 --delay=2 （每次请求延迟2秒）和 --threads=1 （单线程）。
• 使用代理池 ：通过 --proxy 参数轮换使用不同的代理IP。
• 精心设计tamper ：不要一开始就用 --tamper=all 。先手工测试出能绕过的1-2种方法，然后只使用对应的tamper脚本，减少无效Payload的探测次数。
• 利用已发现的注入点直接获取数据 ：如果手工已经确认了注入类型和可用的列数，可以尝试用sqlmap的 --sql-shell 或 --os-shell 直接进行交互，减少前期探测。

Q2：WAF拦截页面和正常页面几乎一模一样，如何判断Payload是否执行成功？ A2：这需要极其细致的观察。

• 对比响应长度 ：使用Burp Suite的 Comparer 工具，精确对比两个响应包的字节长度。即使页面看起来一样，一个额外的空格或换行符都会导致长度不同。
• 寻找隐藏标记 ：查看页面源代码，WAF可能在HTML注释、某个 div 的 style 属性或一个隐藏的 input 标签里留下标记。
• 时间盲注 ：如果页面无任何差异，尝试时间盲注。使用 AND SLEEP(5) 观察响应时间是否显著增加。注意网络延迟，多次测试取平均值。

Q3：针对云WAF，有没有通用的绕过思路？ A3：云WAF通常防护能力较强，但并非无懈可击。可以尝试以下方向：

• 寻找源站IP ：云WAF通常是反向代理。如果通过历史DNS记录、子域名探测、SSL证书信息泄露等方式找到了网站的真实服务器IP，并直接攻击该IP，就可能完全绕过云WAF。
• 利用边缘功能 ：如果目标网站使用了云服务商的其他边缘计算功能（如云函数、Worker），这些功能的代码可能部署在另一个安全边界较弱的环境中，成为突破口。
• 0day或逻辑漏洞 ：关注云WAF产品本身的安全公告。历史上，主流云WAF也曾爆出过绕过漏洞。

Q4：在防御中，参数化查询是不是百分百安全？ A4： 不是绝对的 ，但在正确使用的前提下，它是防御SQL注入最有效的手段。需要注意的“坑”：

• 错误使用 ：部分开发者会错误地使用字符串格式化后再传给参数化查询，这完全失去了作用。例如： String sql = String.format("SELECT * FROM %s WHERE id = ?", tableName); 这里的 tableName 仍然是拼接的，存在风险。
• IN语句的处理 ：参数化查询对于 IN (?) 子句支持不友好，不能直接传入一个列表。需要动态生成多个占位符 IN (?, ?, ...) ，这是一个容易出错的地方。
• ORDER BY动态排序 ： ORDER BY 后的字段名不能参数化（因为参数会被引号包裹）。此处必须使用严格的白名单校验。

Q5：内网系统的SQL注入漏洞，还需要考虑WAF绕过吗？ A5： 需要，但场景不同 。内网系统可能不部署商业WAF，但可能有主机防火墙、IPS/IDS或简单的输入过滤。绕过思路更侧重于：

• 混淆以绕过简单的字符串过滤 ：例如，系统可能简单替换 select 为空，可以用 selselectect （过滤一次后变成 select ）来绕过。
• 利用数据库特性 ：内网数据库版本可能较旧，存在一些已知的、在公网已被修复的奇怪语法或特性可以利用。
• 权限提升与横向移动 ：内网注入的目标往往不是直接获取数据，而是结合数据库的“提权”功能（如MySQL的UDF提权、MSSQL的 xp_cmdshell ）来获取服务器权限，进而横向移动。此时的Payload构造需要更精细，避免被主机安全软件检测。