从启明星辰面经反思到 SQL 注入黑名单绕过实战：sqli-labs 严苛正则过滤、括号闭合转折与全维度绕过技术深度复盘

目录

一、背景与复盘范围：一份渗透测试面试记录引发的技术代差反思

1.1 学习路径与行业技术社区的沉淀差异

1.2 核心漏洞机理表述的技术硬伤：以 XXE 为例

1.3 现代 WAF 对抗认知与传统黑名单绕过的代差审视

1.4 工具运用禁忌与内网实战边界

1.5 所谓“SSL 绕过”的概念误区与真实考点澄清

二、案例一：关键字过滤与双写重构机制（sqli-labs Less-25 深度复盘）

2.1 实验环境代码审计与过滤基准

2.2 基础注入点验证与联合查询回显探测

2.3 敏感字段名隐式过滤遭遇与排错转折

2.4 系统元数据获取中的级联过滤与逐级排查

三、案例二：空白与注释全面封锁下的极限构造（sqli-labs Less-26 深度复盘）

3.1 极端过滤规则审查

3.2 空白字符与注释替代方案的连环挫败

3.3 注释绕过思路转变：放弃注释符，转向构造逻辑闭合

3.4 引入辅助研判工具与认知校准

3.5 切换底层环境：本地 MySQL 命令行精准排错与技术转折

3.6 真实有效载荷的最终验证

3.7 延伸对比：sqli-labs Less-26a 的过滤特征与解题取舍

四、系统性 MySQL 过滤绕过知识图谱与技术演进（Typora 笔记深度解析）

4.1 空格过滤的四维突破路径

方案一：内联注释与特性注释

方案二：空白字符编码置换

方案三：反引号包裹表名与字段

方案四：浮点数与科学计数法突破单词边界正则（）

4.2 引号过滤与十六进制绕过

4.3 逗号过滤的三大实战解法

方案一：联合查询中的逗号绕过——JOIN 虚拟联表法

方案二：盲注截取函数中的逗号绕过——FROM … FOR … 语法规范

方案三：截取函数受限下的函数级逐级替代

方案四：彻底规避函数与逗号——LIKE 模式匹配暴破

方案五：分页查询与集合包含中的逗号绕过

4.4 比较符号（<、>、=）受限下的替代方案

五、自动化盲注实现与攻防工具的工程取舍

5.1 Python 自动化盲注脚本的双重演进

模式一：双重嵌套循环（线性暴力破解）

模式二：基于二分查找（Binary Search）的高效收敛

5.2 免脚本替代：Burp Suite Intruder 的集束炸弹（Cluster Bomb）实操

5.3 实战技能延伸：内网横向移动中的密码喷洒（Password Spraying）

六、讲师经验总结与现代安全实战/面试认知升级

6.1 正则黑名单与商业级语义 WAF 的代差分野

6.2 渗透测试面试中的避坑指南与能力重塑

七、复盘结论

交付自检报告

摘要：本文围绕一份典型渗透测试岗位面试实录展开技术反思，剖析了传统黑名单绕过话术与现代化防御之间的认知断层。随后以 sqli-labs 第 25、26 及 2 关为实验靶场，深度复盘了面对 OR/AND 过滤、空白字符及注释全拦截等极限环境下的排查路径，详细记录了利用双写重组、URL 隐式空白失效分析、MySQL 命令行底层排错以及最终将逻辑闭合嵌入字段表达式的转折突破全过程。最后系统梳理了空格、引号、逗号、比较符与盲注优化的实战替代方案，为安全研究与攻防技术复盘提供严谨的工程实践参考。

一、背景与复盘范围：一份渗透测试面试记录引发的技术代差反思

在网络安全工程实践与技术求职考核中，面试沟通不仅是个人技能的检验窗口，更是观察行业攻防认知演进的切面。本次技术复盘的起点源自一份流传于安全技术社群的公开求职实录——一篇标题为《某星辰面试分享》的技术面经。该求职者目标岗位为北京地区的渗透测试工程师，面试单位为头部网络安全企业启明星辰。

图 01：公开面经分享文章的起始部分，包含求职城市、应聘岗位以及整体面试流程背景。

梳理该记录的初始语境可以发现，求职者为非科班背景出身，此前从事设计类工作，因行业变化自学转岗至网络安全领域约两年时间。在实战经验积累方面，求职者主要依靠在漏洞盒子等漏洞响应平台（SRC）提交基础 Web 漏洞为主，涉及的漏洞类型集中在 SQL 注入、跨站脚本（XSS）、URL 重放以及任意文件上传等范畴。

图 02：面试官就个人经历、日常学习渠道及简历技术关键词展开询问的对话实录。

然而，当面试官深入追问细节时，暴露出的技术表述与攻防认知引发了深入探讨：

1.1 学习路径与行业技术社区的沉淀差异

在回答“日常通过哪些论坛进行技术学习”时，求职者提及平时主要浏览 CSDN。这一回答在专业安全工程师视角的面试场景中显得不够精准。CSDN 作为一个泛开发类的综合技术平台，内容涵盖极广但质量参差不齐，且缺少针对高对抗性攻防、底层漏洞挖掘以及前沿分析的垂直沉淀。

在当前的企业级攻防与漏洞研究生态中，行业公认且具备高含金量的交流社区主要集中在两大平台：

图 03：先知社区展示的 Linux 内核漏洞分析与 FastJson2 反序列化等高水平攻防文章。

图 04：奇安信攻防社区首页，聚合了漏洞自动化利用、代码审计与新型实战技术成果。

图 05：社区内针对 Spring Boot Actuator 认证绕过与容器逃逸等前沿漏洞的深度解析。

行业研判与学习建议： 面试官询问日常学习渠道，核心意图在于评估候选人的信息获取质量、技术视野的前沿性以及自主研究的深度。如果求职者无法准确说出行业头部的垂直攻防平台，往往会被判定为缺乏与一线攻防接轨的自驱力与敏感度。

1.2 核心漏洞机理表述的技术硬伤：以 XXE 为例

当面试官针对简历中提及的外部实体注入（XXE）展开实战追问时，求职者的回答暴露了严重的技术断层。求职者称其操作为：“在一个 CMS 中搭建炮台，创建 1.xml、2.php、3.txt，抓包将 1.xml 数据从 2.php 发送到 3.txt，数据从 3.txt 回显，可能带加密，解密后继续渗透。”

图 06：求职者采用高度口语化且语焉不详的方式描述 XXE 实战步骤，缺乏底层技术机理。

这一表述存在多处关键缺陷：

• 核心机理缺失：完全未提及 XML 解析器对外部实体的解析支持（如 SYSTEM 标识符）、未说明是否配置了禁止外部实体解析选项（如 PHP 中的 libxml_disable_entity_loader(true)）。

• 缺乏技术抽象：将 Blind XXE（带外数据回显）的过程表述为缺乏逻辑支撑的文件流水线，没有阐明基于 DTD 文件的带外通道搭建（OOB，Out-of-Band）本质与数据传输协议（如 HTTP、FTP）的交互流程。

• 语言环境混淆：未区分 PHP（如 simplexml_load_string、DOMDocument）与 Java（如 DocumentBuilderFactory）在解析 XML 实体时的底层差异与防护特异性。

尽管面试记录显示面试官对此回复了“不错不错”，但从专业评审视角来看，这种客套反馈往往是因为面试官在电话初筛中并未过深纠缠，或是候选人面对非对口技术背景考核人员时的侥幸过关。

1.3 现代 WAF 对抗认知与传统黑名单绕过的代差审视

紧接着，面试对话进入了 Web 应用防护系统（WAF）对抗的讨论。这一环节充分展现了十年前的“靶场思维”与现代化防护体系之间的严重脱节。

面试官询问知名 WAF（如长亭科技的雷池 SafeLine 等）需要填充多少垃圾字符才能导致检测失效。求职者回答称时间太久已经遗忘，并表示主要依靠在请求前部填充大量垃圾字符进行缓冲区溢出测试；面试官随之给出了“某 WAF 需要 4.5 万个垃圾字符”的反馈。

图 07：对话中提及依靠填充超长垃圾字符触发 WAF 规则绕过的测试逻辑。

在随后的 SQL 注入 WAF 绕过提问中，求职者罗列了一系列经典手法：

图 08：求职者针对 WAF 绕过问题所列举的传统基于字符替换与注释的技术手段。

图 09：面试实录中关于各主流 WAF 限制字符长度的再次出现。

实战对抗结论与技术辨析： 上述所谓“绕过技巧”本质上属于十至十五年前针对简陋正则表达式检测系统的历史遗留产物。

图 10：面试官针对反序列化原理展开深入询问，求职者未能形成系统化回答。

图 11：简历中将渗透测试框架 Metasploit（MSF）误写为 smf 的细节被当场指出。

1.4 工具运用禁忌与内网实战边界

面试记录中还记录了一处极具警示意义的技术细节：求职者在描述主机渗透时表示，一旦扫描发现目标开放 445 端口，便直接调用 MSF 中的永恒之蓝（MS17-010）攻击模块实施漏洞打击，并提到曾导致靶机直接崩溃关机。面试官当场指出：“在真实商业项目中严禁直接使用 MSF 进行此类攻击，特别是在企业域环境中可能导致核心业务瘫痪。”

图 12：面试记录展示求职者使用 MSF 打击 445 端口引发系统崩溃的叙述，图上被重点标注红叉。

这一评价直击企业红蓝对抗与授权渗透测试的核心红线：

• 业务可用性第一原则：MS17-010 等内核级 SMB 漏洞利用涉及底层内存覆写，利用失败极易引发操作系统蓝屏（BSOD）。在生产网络或核心域控环境中执行此类操作属于严重的操作事故。

• 流量指纹高危暴露：MSF 原生生成的 Shellcode 与通信流量具备高度标准化的特征，早已被国内外主流防病毒软件（EDR）与流量分析设备打上明确标签。未经过深度免杀重构的 MSF 载荷在真实攻防中生存周期极短。相比之下，Cobalt Strike 等工具在具备可视化与团队协作优势的同时，同样必须依托深度定制的 Malleable C2 配置文件才能维持有效隐蔽。

图 13：面试官对求职者自学经历与 SRC 挖掘排名的肯定与录用沟通提示。

图 14：讲师在回顾该篇面试记录时，红笔圈画强调 WAF 绕过属于当前面试高频必考板块。

图 15：特写展示候选人关于大小写、空值、内联注释及参数污染的回答文本。

1.5 所谓“SSL 绕过”的概念误区与真实考点澄清

在面试实录的延伸分析中，涉及到一个常被误读的技术名词——“SSL 绕过”。面试官的提问语境实际指向移动端应用（APP 及小程序）在渗透测试过程中的抓包受阻问题。

• 网络架构本质：移动端 APP 本质上是一个独立的前端展示程序，其核心业务数据均依赖 API 接口向后端服务器异步请求。APP 渗透的核心路径在于捕获并分析这些与后端服务交互的数据包，通过分析服务端 Web 系统的接口逻辑寻找越权、注入或逻辑缺陷。

• 常见技术卡点：渗透测试人员在物理机配置 Burp Suite 监听 127.0.0.1:8080，并在移动设备中配置 Wi-Fi 代理指向物理机 IP 及端口后，常发现应用提示“网络连接中断”或完全无法收发数据。

• 概念辨析与纠偏：此现象绝非意味着“破解了 SSL 协议本身”。SSL/TLS 底层基于 RSA、ECC 及 AES 等严密的非对称与对称密码学算法，若真正实现 SSL 破解，全球加密通信与互联网金融体系将发生根本性雪崩。应用无法抓包的根本原因在于客户端实施了证书绑定（SSL Pinning）机制，即 APP 内部预埋了服务端合法证书的哈希或公钥信息，拒绝信任由本地抓包工具颁发的伪造根证书。实战中的应对方案是借助 Frida、Xposed 等动态 Hook 框架绕过客户端的证书校验函数，促使应用信任系统证书或本地代理，而非“绕过 SSL 加密”。

现代攻防考核趋势总结： 当前一线安全岗位对传统的 OWASP Top 10 基础原理提问正在大幅压缩，考核重心全面转向深度代码审计、高阶反序列化利用链分析、WAF 机制拆解与真实防御规避，以及WebShell 动态免杀技术。基于此，下文将脱离粗浅的口头表述，以严谨的代码审计和本地调试为基础，针对黑名单过滤展开系统性的攻防技术复盘。

二、案例一：关键字过滤与双写重构机制（sqli-labs Less-25 深度复盘）

本节以开源 SQL 注入靶场 sqli-labs 的第 25 关（Less-25）为实验对象，复盘在服务端实施特定关键词严格正则剔除时的调试全流程。

2.1 实验环境代码审计与过滤基准

审计 sqli-labs/Less-25/index.php 源码，后端在接收 HTTP GET 请求传递的 id 参数后，未直接拼入 SQL 语句，而是显式调用了自定义的 blacklist() 函数实施过滤：

图 16：Less-25 后端在将输入变量拼入数据库查询前，通过 blacklist 函数进行参数清洗。

图 17：黑名单函数使用 preg_replace 针对 or 与 and 设定了不区分大小写的全局替换规则。

审查该过滤逻辑的具体实现：

function blacklist($id)
{
   $id = preg_replace('/or/i', "", $id);   // 剔除 or（不区分大小写）
   $id = preg_replace('/AND/i', "", $id);  // 剔除 and（不区分大小写）
   return $id;
}

技术特征剖析：

图 18：在 blacklist 关键位置添加注释，标明两种核心对抗策略：彻底避开敏感词与构造双写重组。

【小白通俗注解】

单次替换（preg_replace）为什么会产生安全漏洞？ 当防御程序仅仅执行了一次查找并删除空字符的操作时，它只移除了它首次扫到的模式。如果攻击者将一个敏感词从中间切开，并在缝隙中再塞入一个敏感词（如 a + and + nd），程序删除了内层的 and 之后，原本被分开的外层字母就会重新合拢，再次拼凑成完整的 and。这就是“双写绕过”的物理本质。

2.2 基础注入点验证与联合查询回显探测

在浏览器端输入基础测试载荷，验证参数闭合与回显机制：

http://127.0.0.1/sqllabs/Less-25/?id=1'

系统立即抛出 MySQL 语法错误异常信息：You have an error in your SQL syntax; check the manual… near ''1' LIMIT 0,1' at line 1，明确证实单引号成功破坏了原有的 SQL 语句结构。

图 19：通过单引号成功闭合并破坏原始查询语句，页面回显错误信息证实字符型注入漏洞存在。

确认字段数量并探测有效回显位。构造标准的联合查询载荷：

http://127.0.0.1/sqllabs/Less-25/?id=-1' union select 1,2,3–+

图 20：在地址栏键入带有联合查询及注释截断的探测载荷。

页面回显显示 Your Login name: 2 与 Your Password: 3，表明当前数据表的字段总数为 3，且第 2 字段与第 3 字段为有效数据回显位置。

图 21：页面明确回显 2 和 3，验证联合查询通道建立成功。

2.3 敏感字段名隐式过滤遭遇与排错转折

在建立联合查询通道后，下一步是通过子查询提取 users 表中的用户凭证。构造常规子查询语句：

-1' union select 1,(select group_concat(username,0x3a,password) from users),3–+

图 22：尝试使用 group_concat 连接 username、冒号十六进制（0x3a）及 password 字段。

该请求发送后，页面并未如期输出用户数据，而是返回了数据库语法错误。 问题分析： 排查载荷构成，当前语句中并未显式包含逻辑连接词 OR 或 AND。然而，细致审查字段名发现，目标字段 password 的拼写中内嵌了连续字符 or（即 pass-w-or-d）。当输入字符串经过 blacklist() 函数处理时，内部的 or 被无条件替换为空，使得原字段名被篡改成非法的数据库列名 passwd，从而导致 MySQL 产生列名不存在的错误。

修复尝试 1：逻辑运算符替代 讲师尝试使用关系运算符 || 代替 password 中的 or 字母串，在地址栏输入：

passw||d

图 23：尝试使用双竖线 passw||d 绕过，但因字段名属于纯标识符而失效。

测试结果：执行失败。 失败归因：|| 是 SQL 语法中的逻辑析取运算符（或在某些模式下用作字符串连接符），而 password 是数据表中的物理列标识符。标识符必须是连续完整的文本，不能被操作符截断，因此语法解析无法将其识别为合法字段。

修复尝试 2：基于单次过滤特性的双写构造 利用 preg_replace 不具备递归清洗的特性，将 password 改写为双写形式：

passwoord

当防护函数扫描到中间的 or 时，将其替换为空字符 ""，前缀 passw 与后缀 d 以及外层保留的字符重新重组为合法的 password。

提交载荷：

http://127.0.0.1/sqllabs/Less-25/?id=-1' union select 1,(select group_concat(username,0x3a,passwoord) from users),3–+

图 24：页面成功打印 Dumb:Dumb, Angelina:I-kill-you 等全部敏感用户信息。

2.4 系统元数据获取中的级联过滤与逐级排查

在真实的盲盒渗透测试中，攻击者通常无法预先知悉数据表结构，必须依次遍历查询系统架构库 information_schema。然而在 Less-25 的过滤规则下，这一常规操作遭遇了连续的“隐式过滤陷阱”。

陷阱 1：元数据库名称被截断 尝试获取所有数据表名称：

-1' union select 1,(select group_concat(table_name) from information_schema.tables where table_schema=database()),3–+

图 25：地址栏中输入针对 information_schema 系统的查询尝试。

图 26：未处理关键字的查询语句，因 information 中含 or 将直接导致表名失效。

结果分析：information_schema 库名中同样包含敏感子串 or（inf-or-mation）。未双写直接输入会导致被清洗为 infmation_schema，引发库名不存在错误。 修正方案：将库名实施双写重构为 infoorrmation_schema.tables。

图 27：地址栏修正为 infoorrmation_schema，消除库名解析错误。

陷阱 2：查列条件中的逻辑连接词被剔除 在枚举目标表（users 表）中的列名时，需要同时限定当前数据库名与表名，常规写法如下：

select group_concat(column_name) from infoorrmation_schema.columns where table_schema=database() and table_name="users"

图 28：通过 infoorrmation_schema.columns 获取指定表列名结构。

图 29：报错信息明确指向 near 'table_name="user"),3–'，证实 and 消失导致前后子句无法连接。

测试结果：页面报错 near 'table_name="user"),3–' LIMIT 0,1。 原因定位：语句中的关键字 and 被完全剔除，导致 where table_schema=database() 与后续的 table_name="users" 失去逻辑连接符，语法结构发生断裂。同时，部分测试将表名误拼写为 user（正确应为 users）。

修复测试：双写逻辑词 aandnd 在地址栏将 and 替换为双写字符串 aandnd，重新提交：

图 30：对逻辑连接词实施双写重组，恢复 WHERE 条件的合法逻辑关系。

修复后查询顺利执行，完整输出了 users 表的各个字段名称。

图 31：结合靶场实测，对比面试实录中关于传统绕过方式的局限性。

实战经验沉淀： 基础黑名单过滤的致命弱点在于其静态单次清洗机制。防御方若仅依赖字符级删除，攻击者通过构造嵌套同构字符串（双写）即可轻松穿透。然而必须明确，这类技术属于典型的“教学靶场对抗技术”，在具备抽象语法树（AST）重构能力的现代化防护设施中不具备实战存活性。

三、案例二：空白与注释全面封锁下的极限构造（sqli-labs Less-26 深度复盘）

如果说 Less-25 仅是针对特定关键字的初级清洗，那么 sqli-labs 第 26 关（Less-26）则构建了一个几乎封锁所有常规外设通道的极限过滤场景。

3.1 极端过滤规则审查

审查 sqli-labs/Less-26/index.php 中的核心黑名单逻辑：

图 32：Less-26 源码构建了针对逻辑词、常见注释符、空白字符及反斜杠的组合正则清洗体系。

图 33：特写高亮展示黑名单函数对 [\\s] 及斜杠字符的处理方式。

提取核心过滤规则如下：

function blacklist($id)
{
$id = preg_replace('/or/i', "", $id); // 剔除 or
$id = preg_replace('/and/i', "", $id); // 剔除 and
$id = preg_replace('/[\\/\\*]/', "", $id); // 剔除 /*
$id = preg_replace('/[–]/', "", $id); // 剔除 —
$id = preg_replace('/[#]/', "", $id); // 剔除 #
$id = preg_replace('/[\\s]/', "", $id); // 剔除所有空白字符（空格、换行、制表符等）
$id = preg_replace('/[\\/\\\\]/', "", $id); // 剔除正反斜杠
return $id;
}

技术约束梳理：

• 逻辑运算符全面封锁：or 与 and 均被强制剔除。

• 物理注释符全面封锁：/*、–、# 全部被清洗，意味着载荷尾部无法再使用传统注释手段截断原 SQL 的剩余部分。

• 所有空白符彻底清除：正则 [\\s] 能够匹配 ASCII 中的所有标准空白字符（包括空格、 制表符、 回车符、 换行符等）。

进行单引号测试，确认仍然存在基于报错的回显反馈：

http://127.0.0.1/sqllabs/Less-26/?id=1'

图 34：页面标语“All Your Spaces and Comments belong to us”明确指明空白与注释均受管辖。

3.2 空白字符与注释替代方案的连环挫败

若直接尝试传统的联合查询：

http://127.0.0.1/sqllabs/Less-26/?id=-1' union select 1,2,3–+

图 35：未做任何规避处理的联合查询载荷，必然被过滤规则整体粉碎。

所有空格被清空导致关键字粘连为 unionselect，注释符被移除导致尾部单引号引发语法崩溃。

失败尝试 1：内联注释 /**/ 尝试利用内联注释代替空格：

-1' union/**/select 1,2,3–+

图 36：在地址栏使用经典 SQL 内联注释尝试隔开关键字。

测试结果：失败。 原因分析：源码中显式定义了 preg_replace('/[\\/\\*]/', "", $id)，直接将 /* 清理干净。

图 37：源码审计证实内联注释符处于严格黑名单之中。

失败尝试 2：URL 隐式空白编码（%0a、%a0、+） 讲师在代码中梳理了常见的 URL 编码空白替代符：%0a（换行）、%0b（垂直制表）、%0c（换页）、%0d（回车）、%09（水平制表）、%a0（不换行空格）。

图 38：梳理尝试清单：%0a、%0b、%0c、%0d、%09 以及 %a0。

测试提交 %a0：

-1' union%a0select 1,2,3–+

图 39：尝试利用非标准空白字符 %a0 穿透过滤机制。

结果分析：在 Windows/PHP 环境下，%a0 未被 MySQL 视为合法分隔符，解析呈现为不可见异常字符；而针对 %0a 等标准字符，由于 PHP 正则中 [\\s] 完整囊括了空白符集合，所有换行符均被精确剔除。 紧接着测试使用 URL 标准加号 +：

图 40：报错信息 near 'unionselect1,2,3' 证实加号在被服务端解析为空格后，被 [\\s] 清除导致字符粘连。

机理拆解：浏览器发送 +，Web 容器（Apache/Nginx）在进入 PHP 业务脚本前将其标准反编码为 ASCII 空格；随后脚本中的 [\\s] 正则捕获该空格并将其完全清除，最终依然导致 unionselect 字符粘连。

图 41：排查发现不仅分隔符失效，尾部的物理注释同样无法发挥作用。

3.3 注释绕过思路转变：放弃注释符，转向构造逻辑闭合

由于所有物理注释符全部被剔除，讲师确立了新的调试原则：放弃物理截断，通过逻辑运算符手工闭合原 SQL 语句的尾部单引号。

*图 42：记录闭合公式设计：select * from users id='1' union select 1,2,3 and '1'='1'。*

原 SQL 语句骨架为：SELECT * FROM users WHERE id='$id' LIMIT 0,1。 若注入载荷设计为：

-1' union select 1,2,3 aandnd '1'='1

当原语句尾部的单引号与闭合载荷末尾结合时，将在理论上形成 and '1'='1' LIMIT 0,1 的合法表达式。

图 43：在地址栏结合双写逻辑词 aandnd 与单引号闭合表达式。

图 44：报错信息指出 near 'union?select?1,2,3and'1'='1'，字段 3 与 and 之间无空白发生粘连。

报错分析：尽管双写成功重组出了 and，但由于数字 3 与 and 之间缺乏空格，被解析引擎拼接成了非法的词法单元 3and。

尝试利用括号隔离： 为解决字符粘连问题，尝试为逻辑表达式添加括号：

图 45：试图利用括号隔离逻辑表达式中的字符。

图 46：微调尾部括号与单引号的嵌套关系。

图 47：尝试通过将逻辑词自身加括号 (aandnd) 实现边界隔离。

图 48：报错信息显示在括号边界处依然存在语法冲突。

图 49：尝试对 union 与 select 分别加括号进行词法隔离。

图 50：特写展示针对联合查询关键词的括号嵌套实验。

尝试双重 URL 编码绕过空格： 讲师推测能否利用 URL 编码的双重嵌套实现空格重组，例如构造 %2%200：

图 51：设计理念为外层解码后释放 %20，期望逃逸后重新组合成空格。

图 52：页面明确回显 Hint: 1'%20unionselect，证实 %20 被作为字面量传入，未被第二次解码。

图 53：地址栏中未被识别的编码字面量特写。

图 54：全面覆盖测试双重编码，最终证实该思路在当前架构下不可行。

归因解析：Web 容器仅对外部输入执行一次标准 URL 解码。%2%200 中的中间部分 %20 被解码为一个空格后，被 [\\s] 清理；而两侧残留的字符拼接为字面量 %20。由于 MySQL 数据库内部不会对 SQL 语句二次执行 URL 解码，该字面量被直接判定为语法错误。

图 55：再次审视 [\\s] 规则，确认字符串清洗层不存在任何传统编码绕过的缝隙。

3.4 引入辅助研判工具与认知校准

在连续测试陷入僵局后，讲师借助 AI 对话模型（DeepSeek）针对该段黑名单过滤代码展开了规则验证：

图 56：明确向模型指出无法绕过 \\s 空白过滤，探讨如何使用括号实现空格消除。

图 57：模型分析指出 MySQL 允许在关键字与括号之间免除空格，推荐使用括号子查询结构。

图 58：模型列举了加号、取反符号（~）及 -1union(select(1),2,3) 的参考结构。

图 59：重点展示利用 -1union(select(1),(2),(3)) 规避空格的标准范例。

模型给出的关键洞察与讲师的设计方向一致：在 MySQL 语法规范中，圆括号 () 本身具备操作符与边界界定功能，关键字与括号之间、括号与数值之间完全无需依赖空格分隔。

然而，当讲师将 AI 给出的参考载荷直接套入浏览器时：

http://127.0.0.1/sqllabs/Less-26/?id=-1'union(select(1),(2),(3))aandnd'1'='1

图 60：将括号隔离语法与双写逻辑闭合组合后发起请求。

图 61：记录 id='1' union select 1,2,3 and '1'='1' 的逻辑结构。

图 62：继续测试该载荷在浏览器端的执行反馈。

图 63：将输入调整为 id=111' 确保主查询结果集为空。

图 64：尝试使用空字节 %00; 实施截断，因现代高版本环境失效。

浏览器端依然持续报错，无法定位深层语法冲突所在。

3.5 切换底层环境：本地 MySQL 命令行精准排错与技术转折

为彻底摆脱 Web 服务端与 PHP 正则清洗可能带来的干扰，讲师切换至本地 Windows 命令行环境下的 MySQL 终端，直面数据库底层解析引擎，展开纯粹的 SQL 语法调试。

图 65：登录 root 权限 MySQL 终端，选择 security 数据库进行独立语句测试。

在命令行中直接输入测试语句：

select * from users where id=-1'union(select(1),(2),(3));

终端立即返回提示符 '>，表明字符串单引号未完成闭合，语句处于挂起等待状态。讲师使用 Ctrl + C 中断。

图 66：多轮尝试均触发换行等待提示符，明确暴露了闭合结构未闭合的本质。

讲师尝试添加尾部闭合逻辑：

select * from users where id='-1'union(select(1),(2),(3)) and '1'='1';

此时 MySQL 命令行抛出了决定性的错误日志：

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'and '1'='1'' at line 1

图 67：终端排错关键帧：明确指出错误发生于 union 括号后的 and '1'='1'。

底层语法根因解密： 在标准 SQL 语法规范中，UNION 操作符用于合并两个独立的 SELECT 结果集： SELECT … UNION (SELECT …)。 当在第二个被括号包裹的子查询 (SELECT …) 外部直接追加 AND '1'='1' 时，解析引擎无法识别该 AND 条件属于哪一个查询——它既不能挂载给第一个 SELECT，也不能在 UNION 结束后作为全局过滤条件存在，因此直接触发 1064 语法错误！

重大技术转折点： 现场学员与讲师共同捕捉到了这一语法特性：必须将尾部闭合表达式 and '1'='1' 移入第二个子查询内部，作为其某个字段本身的布尔/算术表达式！

讲师立即重构 SQL 命令，将逻辑闭合写入第 3 个查询字段内：

select * from users where id='-1' union(select(1),(2),(3) and '1'='1');

图 68：SQL 成功执行！返回结果集成功输出 id=1, username=2, password=1。

图 69：终端稳定回显证明该语法结构具备 100% 的合法性。

【小白通俗注解】

为什么 (3) and '1'='1' 在数据库里是合法的？ 在 MySQL 中，任何数据列位置不仅可以放普通的数字，还可以放数学计算公式或逻辑判断。 表达式 (3) and '1'='1' 实际上让数据库进行了一次计算：

3.6 真实有效载荷的最终验证

基于底层调试成功的语法模型，讲师进一步将第 2 字段（回显字段）替换为数据库敏感信息提取函数 user()：

select * from users where id='-1' union (select(1),(user()),(3) and '1'='1');

命令回车执行，MySQL 终端立即精准打印出当前连接用户信息：root@localhost！

图 70：终端成功输出 root@localhost，验证了无空格、无注释闭合绕过方案的实战有效性。

至此，在完全杜绝空格、封锁一切物理注释、清洗所有标准逻辑词的苛刻环境下，通过全括号隔离配合字段级算术布尔闭合，实现了数据库信息的完整提取。

3.7 延伸对比：sqli-labs Less-26a 的过滤特征与解题取舍

讲师简要对比了靶场紧邻的第 26a 关（Less-26a）。审查其源码发现，该关卡在 blacklist() 中对空白字符实施了连续两次正则过滤：

$id = preg_replace('/[\\s]/', "", $id);
$id = preg_replace('/[\\s]/', "", $id);

图 71：Less-26a 源码展示双重空白清理机制，同时该关卡为基于盲注/报错的无回显环境。

针对此类关卡，由于页面不再提供类似 Less-26 的多字段直接回显位，测试路径通常有两种选择：

四、系统性 MySQL 过滤绕过知识图谱与技术演进（Typora 笔记深度解析）

在完成上述两个复杂靶场的极限排错后，讲师打开了系统整理的 MySQL绕过.md 知识大纲，针对常见的输入过滤与语法限制展开了横向的分类推演。

图 72：大纲涵盖空格、引号、逗号、比较符、逻辑词、注释符等十六个核心过滤方向。

4.1 空格过滤的四维突破路径

在实际业务防护规则中，针对空格的限制是最基础也是最频繁的策略。除了前文详述的括号隔离法，实战中存在四种典型替代方案：

方案一：内联注释与特性注释

利用 MySQL 独有的注释语法替代空格分隔：

• 标准内联注释：SELECT/**/*/**/FROM/**/users;

• 版本特性注释：/*!50000SELECT*/*/*!50000FROM*/users;

在本地 MySQL 命令行验证：

select/**/*from/**/users;

图 73：终端验证 /**/ 完美履行了字段与表名之间的空格分隔职责。

方案二：空白字符编码置换

在不同操作系统与解析环境下，部分特殊的 URL 编码可被识别为有效空白符： %20（标准空格）、%09（Tab）、%0a（换行）、%0b（垂直制表）、%0c（换页）、%0d（回车）、%a0（不换行空格）、%00（截断符）。

方案三：反引号包裹表名与字段

在 MySQL 中，反引号 ` 用于界定标识符。当表名前后缺乏空格时，直接使用反引号包裹可避免词法解析冲突：

select * from`users`;

方案四：浮点数与科学计数法突破单词边界正则（）

这一方案并非用于解决语法上的空格缺失，而是专门针对防守方设置的单词边界正则表达式展开的降维打击。

图 74：大纲详细记录 8E0union、8.0union 与单词边界 \\bunion(.?)select\\b 的对抗逻辑。*

机理深度拆解： 许多安全防护脚本（如 ModSecurity 基础规则或开发者的简易过滤器）常采用如下正则拦截联合查询：

union(.*?)select

【小白通俗注解】

什么是正则表达式里的“单词边界”（）？ 就像是一个检查岗哨，它专门站在“英文单词”和“标点符号/空格”的交界处。 比如在 select * from 中，select 前面是开头的空白，后面是空格，所以它的两端都是“边界”，select 就能抓到它。 但如果你在 select 前面紧紧贴着写一个数字或字母，让它变成 1select，那么数字和字母在电脑看来是“同一个单词的内部成员”，原本处于开头的“边界岗哨”就消失了，正则检查就会直接漏过去！

在在线正则测试平台 regex101.com 中重现该规则：

图 75：标准形态下，输入 select from 能够被正则完整捕获。

若在 select 前部拼接其他字母（如 aaaaselect from），则由于破坏了前置边界断言，该正则立即匹配失败：

图 76：前缀使得首字母 s 不再处于词边界，显示 Match Information: Does not match。

在 SQL 语法层面的工程实践： 如果注入点为数字型注入（例如 sqli-labs Less-2），原语句结构为：SELECT * FROM users WHERE id=$id LIMIT 0,1。 若输入常规载荷 id=-1 union select 1,2,3，必定触发 union 拦截。 此时攻击者可将参数构造为浮点数或科学计数法形式：

• 浮点数形式：id=-1.0union select 1,2,3

• 科学计数法形式：id=1E1union select 1,2,3

在 MySQL 终端中排查其语法合法性：

图 77：终端测试表明，在数字型字段之后直接紧贴 union 属于完全合法的数值与操作符组合。

在浏览器端访问 Less-2 实测：

http://127.0.0.1/sqllabs/Less-2/?id=-1.0union select 1,2,3–+

图 78：页面完美执行联合查询，回显用户信息，证实浮点数成功穿透单词边界限制。

图 79：模拟在源码中加入 if(preg_match('/(?:(\\bunion(.?)select\\b))/i',$id)) 防御体系。*

4.2 引号过滤与十六进制绕过

在很多严格过滤单双引号的环境中，攻击者在查询元数据时无法直接书写诸如 table_name="users" 的字符串常量。

图 80：原语句 table_name="users" 转换为十六进制 table_name=0x7573657273。

解决策略：MySQL 原生支持十六进制字面量语法。 将字符串 users 转换为 ASCII 十六进制编码：

• u -> 0x75

• s -> 0x73

• e -> 0x65

• r -> 0x72

• s -> 0x73 组合为十六进制标量：0x7573657273。 在查询语句中直接使用：

select column_name from infoorrmation_schema.columns where table_name=0x7573657273;

由于整条语句完全无需引入任何引号，成功实现对单双引号过滤的绝对规避。

4.3 逗号过滤的三大实战解法

逗号（,）在 SQL 语句中主要承担三个职责：联合查询多列分隔、函数多参数传递（如 substr()、mid()）、以及分页指令 limit 0,1 的参数界定。当逗号被黑名单封锁时，需采用差异化的结构替代方案。

图 81：总结包括 join 联表法、from for 语法及各类截取函数的替代演进。

方案一：联合查询中的逗号绕过——JOIN 虚拟联表法

常规联合查询使用逗号界定字段：UNION SELECT 1,2,3。 在缺乏逗号时，可将每个数字视为一个拥有独立别名的单列单行虚拟子查询表，通过 JOIN 关键字进行横向连接：

union select * from (select 1)a join (select 2)b join (select 3)c

在本地 MySQL 命令行中进行调试： 讲师初次输入时由于漏写了中间的 join 关键字：

select * from users where id=1 union select *from (select 1) a join (select 2) b (select 3) c;

终端立即抛出 ERROR 1064 (42000) 语法异常。

图 82：错误信息明确指出语法解析在 (select 3) c 附近中断，证明各虚拟表之间必须严格使用 join 声明。

补齐 join 后重新执行，查询顺利返回包含了 1, 2, 3 三列组合的合成数据行。

图 83：重点解释 join on 要求两表具备物理/逻辑外键对应，而此处使用笛卡尔积虚拟联表。

图 84：讲师详细阐述将学生 30 个属性拆分为基本信息表、银行卡表、邮箱表背后的工程意义。

数据库底层原理科普： 联合查询 UNION 是将两个结构相同（列数相同）的结果集进行纵向的数据行堆叠，两表之间可以不存在任何语义关联。 而 JOIN 则是基于特定关联条件（ON 条件）进行的横向列扩充。在关系型数据库规范化设计中，为了避免宽表的冗余，会将实体属性拆分至不同数据表，并通过外键建立参照完整性。在上述利用技巧中，由于各子查询只有单行单列且未指定 ON 条件，实际上触发的是单行数据集的自然笛卡尔积合并，从而巧妙拼装出包含三列的多字段结果集，完全绕过了逗号的限制。

方案二：盲注截取函数中的逗号绕过——FROM … FOR … 语法规范

在布尔盲注与时间盲注中，攻击者必须逐位提取字符串以进行 ASCII 码判断。 确认当前数据库名：

图 85：通过 select database(); 确认目标数据库标识为 security。

常规盲注语句使用 substr(database(), 1, 1)，其中包含了两个逗号。在命令行验证基础提取逻辑：

*图 86：构建 select * from users where id=1 and ascii(substr(database(),1,1)) 验证语句。*

当设置首字母 ASCII 为 115（即小写字母 s）时，条件为真，页面成功返回 id=1 的用户信息：

图 87：回显数据证实 security 库的首字符命中 ASCII 115。

当探测第二位字符且依然猜测 115 时，条件为假，返回 Empty set：

图 88：返回空集印证了布尔盲注基于正反状态区分猜测准确性的核心机理。

去除逗号的语法重构： 在 SQL 国际化标准中，截取操作原生支持 FROM 起始位 FOR 截取长度 的表达方式：

select * from users where id=1 and ascii(substr(database() from 1 for 1))=115;

在 MySQL 终端中执行该命令：

图 89：终端成功返回数据行，证实 from … for … 能够完全免除逗号并实现等效截取。

同理，标准函数 substring() 亦完全支持该特性：

图 90：验证 substring 具备完全一致的无逗号截取特性。

方案三：截取函数受限下的函数级逐级替代

当防护系统将 substr() 与 substring() 同时加入黑名单时，需要调用同功能函数族进行横向替代：

图 91：select mid(database(),1,1); 精确截出字母 s。

图 92：终端依次输出 's'、'se'、'sec'，展现了通过前缀累进进行盲注判定的可能性。

图 93：系统归纳 substring、mid、left、right 的替代调用逻辑。

方案四：彻底规避函数与逗号——LIKE 模式匹配暴破

如果所有字符串截取函数均被封杀，可彻底放弃切片思路，转而利用 SQL 通配符 % 进行模糊匹配盲注：

图 94：展示 select user() like 'r%' 与字符判断的等价关系。

在终端实测提取 user()（值为 root@localhost）：

• 测试 select user() like "a%"; -> 返回 0（匹配失败）；

• 测试 select user() like "b%"; -> 返回 0（匹配失败）；

• 测试 select user() like "r%"; -> 返回 1（成功命中首字母 r）！

图 95：当输入 r% 时返回 1，证实首字符为 r，固定首位后追加第二位即可递归爆破。

该方法全程无需引入任何逗号或内置函数，仅依靠布尔真假反馈便可提取全部信息。

方案五：分页查询与集合包含中的逗号绕过

*图 96：大纲展示 select * from news limit 1 offset 0 的标准语法转换规则。*

在 MySQL 终端中进行执行验证：

图 97：终端成功输出首条记录 Dumb，证明其与 limit 0,1 功能完全等价。

图 98：大纲总结通过逻辑析取 OR 消除 IN 集合中的逗号。

4.4 比较符号（<、>、=）受限下的替代方案

在自动化盲注测试中，比较符号主要用于算法层面的二分查找加速。当 < 或 > 被防御规则过滤时：

五、自动化盲注实现与攻防工具的工程取舍

在面对无法回显的注入环境时，手工测试效率极低，必须建立自动化提取链路。讲师深入分析了编写自动化脚本与直接利用渗透工具之间的工程差异。

5.1 Python 自动化盲注脚本的双重演进

模式一：双重嵌套循环（线性暴力破解）

最朴素的盲注脚本采用双层循环：外层控制字符偏移索引（从第 1 位至第 20 位），内层遍历 ASCII 打印字符集（从 32 至 126）。每个字符平均需要发起约 47 次 HTTP 请求，若目标库名较长且存在网络延迟，整体耗时显著。

模式二：基于二分查找（Binary Search）的高效收敛

讲师结合 sqli-labs 靶场分析了二分查找法如何将时间复杂度由 $O(N)$ 降至 $O(\\log N)$。

• 设定初始搜索区间：下界 low = 32，上界 high = 128；

• 计算中点：mid = (low + high) // 2（首次为 80）；

• 发送探测载荷验证是否大于 mid：

  • 若为真，说明目标值位于右侧区间，立即将下界调整为 low = mid + 1；

  • 若为假，说明目标值位于左侧区间，立即将上界调整为 high = mid；

• 每一轮探测直接将剩余候选字符数量腰斩。针对 ASCII 码 32 至 126 构成的近百个字符空间，二分查找仅需固定执行 7 次 HTTP 请求即可精准锁定唯一字符，整体提取效率提升近十倍。

5.2 免脚本替代：Burp Suite Intruder 的集束炸弹（Cluster Bomb）实操

在面试场景或紧急排查现场，面试官可能会询问：“若在无 Python 运行环境或禁止编写脚本的情况下，如何快速完成全自动盲注？”

讲师演示了直接利用 Burp Suite 的 Intruder 模块实施双参数爆破的技巧：

5.3 实战技能延伸：内网横向移动中的密码喷洒（Password Spraying）

结合 Burp Suite Intruder 工具特性的讨论，讲师拓展了一项极具实战价值的企业内网渗透策略——密码喷洒。

传统针对单一账户穷举密码的暴力破解方式存在严重的防护痛点：现代企业身份认证系统均配置了账户锁定策略（例如连续输错 5 次密码强制锁定账户 30 分钟）并会在安全运营中心（SOC）触发频繁的告警封禁。

密码喷洒的攻防逻辑：

六、讲师经验总结与现代安全实战/面试认知升级

在课程尾声，讲师对全篇技术复盘进行了高维度的提炼与升华，剖析了技术原理、面试策略与现代安全防御的本质差异：

6.1 正则黑名单与商业级语义 WAF 的代差分野

• 正则黑名单的局限性：本文所复盘的双写绕过、内联注释、括号规避、浮点数打破单词边界等手法，其生效的充分必要条件是目标系统依赖简单的正则表达式或字符替换逻辑。只要服务端仅在字符层面进行字面清洗，此类语法变形技术便存在利用缝隙。

• 商业级 WAF 的防御降维打击：以长亭雷池（SafeLine）为代表的现代企业级 WAF，其核心引擎基于词法与语法分析（AST）构建。无论攻击者如何嵌套注释、插入空值或变形编码，WAF 引擎都会将请求还原为标准抽象语法树并进行语义判定。在语法树视角下，UNION SELECT 与 UNION(SELECT) 的语义完全同构，传统的字符混淆手段在此类设备面前成功率趋近于零。

6.2 渗透测试面试中的避坑指南与能力重塑

针对开篇展示的求职实录，讲师给出了面向安全专业人员的面试改进建议：

七、复盘结论

SQL 注入漏洞虽然在现代开发框架与参数化查询（Prepared Statements）的普及下逐渐减少，但其背后的词法解析、编码转换、上下文转义以及输入净化逻辑，依然是理解 Web 安全与攻防对抗的绝佳试金石。

本次复盘通过对一份真实面试记录的反思切入，完整再现了从关键词双写重构到无空格无注释极限闭合的排错心路，最终落地为全维度的语法规避知识图谱。技术人员应跳脱出“盲目套用老旧技巧”的思维定势，深入数据库与网络协议底层，在认知现代防护体系高度的同时，打磨出更严谨、更具工程深度的攻防实战能力。

交付自检报告

根据改写规范与任务边界要求，对本文档的最终产出质量进行全项核验如下：