DASCTF · easy_sql —— Writeup（无 select 的堆叠注入链）

过滤规则原文（/i 表示大小写不敏感）：

preg_match("/select|update|delete|drop|insert|where|\./i", $inject);

一、题目形态

首页是一个 GET 表单，参数名 inject，默认值 1。页面顶部把过滤规则原样打印出来：

return preg_match("/select|update|delete|drop|insert|where|\./i",$inject);

页面行为（后面所有判断都依赖它）：

三条反馈通道：正常 / 被拦 / 报错。分清它们，比记 payload 重要。

后端语句可由报错反推：

select * from words where id = '$inject'

依据：inject=1' 时报 near ''1'''（尾部引号是模板自己带的），且页面只回 array(2) 单行。

二、环境探测（四步基线，不能跳）

顺带可读环境：extractvalue(1,concat(0x7e,database())) → supersqli，@@version → 10.3.18-MariaDB，current_user() → root@localhost。

三、第一步撞墙：union 这条路根本不通

最自然的想法：

inject=-1' union select 1,group_concat(schema_name) from information_schema.schemata --+

这条 payload 同时踩了两个雷：

即使把两处都绕过，union 后面必须跟一个查询表达式，而 MySQL 里最短的查询表达式就是 select —— 这条路是被语法堵死的，不是被 WAF 堵死的。

这就是本题的分水岭：不要想着"怎么把 select 写进去"，要想"不写 select 怎么拿到数据"。

四、三个关键原理

原理 1：黑名单是「子串匹配」，不是「词法匹配」

preg_match 只看字符串里有没有那几个片段，不理解 SQL 语法。两个推论：

记住这点，比记任何 payload 都值钱：被拦的从来不是"某个操作"，而是"某几个字母的组合"。

原理 2：\. 的杀伤力是双份的

所以常规的"先查 information_schema 列表 → 再 select 数据"两步走，第一步就死了。

破法：MySQL 里还有一批语句，引用表不需要点号：

show tables                       -- 当前库所有表
show databases                    -- 所有库
show columns from 表名             -- 表的字段
desc 表名

这就是「点号过滤」逼出来的转向：从 information_schema 转向 show 系列。

原理 3：; 没被过滤，等于把「语句级执行」交给你了

过滤规则清一色是关键字 + 点号，唯独漏了 ;。这直接意味着堆叠查询可用（mysqli 多语句 / PDO 相应配置）。

一旦能堆叠，你就从"只能改 WHERE 条件"升级成"能执行任意 SQL 语句"——虽然关键字库里还缺 select。

而页面 while 循环打印每个结果集，正好让堆叠语句的输出也能被看见。三个条件缺一不可：

能堆叠  +  有不需要 select 的读表语句  +  页面打印所有结果集
   ↓              ↓                        ↓
 执行通道        数据来源                  观察窗口

五、完整解题步骤（全部实测）

第 6 步的用处不是拿数据，而是验证引号闭合方式 + 确认页面会打印整个结果集（三行都出来了）。这个观察决定了后面敢用 handler——因为它的输出同样是一个结果集。

六、最后一关：select 被禁，怎么把那一行读出来

此时你手上有：表名 1919810931114514、列名 flag、能堆叠、能看所有结果集。但就是写不了 select。

三条路：

路线 A：HANDLER（本题采用，非破坏性）

HANDLER 是存储引擎级的"游标"语句，直接打开表、按行读，全程不涉及 select：

handler `1919810931114514` open;
handler `1919810931114514` read first;

注意事项：

• 两条语句必须指向同一张表（把 open 用表名、read 用列名是最容易犯的错，会静默失败）
• 纯数字表名必须用反引号，否则被当整数解析
• 多行时用 read next 继续

路线 B：rename 偷梁换柱（经典但破坏性）

思路：程序的 select * from words where id='$inject' 里，表名 words 是写死的。既然改不了语句，就改表——把数字表改名成 words，让程序自己帮你查。

坑在于程序的 where id='1' 需要 id 列，而数字表只有 flag 一列：

error 1054 : Unknown column 'id'

所以实际需要三步：

rename table words to words2;
alter table `1919810931114514` change flag id varchar(100);
rename table `1919810931114514` to words;
-- 然后正常提交 inject=1

顺序错一步、或中途报错，靶场结构就被改坏且无法刷新恢复。能用 HANDLER 就别用这条。

路线 C：prepare + 十六进制（最优雅，但这题有第二层 WAF）

思路：把整条 select * from ... 塞进用户变量，变量值用十六进制写，这样 select 两个字根本不出现在你的输入里：

set @a = 0x73656c656374202a2066726f6d20...;
prepare b from @a;
execute b;

过滤器只能看输入字符串，看不到你拼进变量的内容——这是黑名单类 WAF 的结构性缺陷。

但这道题在页面打印的规则之外还藏了第二层：

strstr($inject, "set") && strstr($inject, "prepare")

一旦输入里同时出现 set 和 prepare，直接拦。这正是标题那句"开发和安全缺一不可"的含义：你看到的 WAF 不是全部的 WAF。

七、五个真实卡点（复盘）

第 5 条是本题最容易让人放弃的地方：你以为是"被 WAF 拦了"，其实只是"语法错得没人告诉你"。

八、可复用的方法论

碰到「SQL 注入 + 关键字黑名单」，按这个顺序推：

一句话：黑名单永远只能枚举"它想到的东西"，解题就是找它没想到的那一个词。

九、汇总表

一句话总结：出题人封了 select，就等于封了"自己造查询"；但没封 ;（能执行语句）、没封 handler（能不查而读），于是绕过点从"怎么改写 select"变成了"怎么换一条读数据的语句"。