失眠数羊1. 拿到题目后的第一印象
这两年打CTF打多了，其实一看到“BabySQL 1”这种命名，大概就能猜出个七八分：这是一道面向新人的SQL注入题，比赛方故意把名字起得很“萌”，本质是想让刚入门的选手在登录框里把SQL注入的完整链路走一遍。这类题目在白帽圈子里出现频率很高，很多攻击队早期培训也是用类似的靶场题目来练手。
题目界面上往往不会给你太多东西，通常就是一个登录表单：用户名输入框、密码输入框、一个登录按钮，顶多再放一行提示。这恰恰是SQL注入最经典的场景——后台大概率是把用户名和密码直接拼进SQL语句里查询。换句话说，任何一个能提交字符串的入口，都可能变成攻击面。
这道题适合谁？我觉得有三类人可以从中受益：第一，刚接触Web安全、对SQL注入停留在“知道原理但没实际打过”的同学；第二，参加过几场比赛但一遇到“关键字被过滤”就卡住的新手；第三，需要给团队做培训的师傅，拿这种题目当教学样本非常合适。因为它不烧脑，却把“判断注入点—摸过滤规则—绕过滤—取数据”这条链路完整地串了一遍，比单纯看文档记payload有效得多。
真正值得玩味的是，比赛方在“Baby”两个字后面藏了一点门槛：注入点好找，问题是当你把常规的SQL语句发过去时，会发现服务器像没听到一样。这时候才意识到，题目考的不是“会不会SQL注入”，而是“在注入被限制的情况下，还能不能把数据拿出来”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境侦察：先别急着上 SQL 武器库
很多新手拿到题目，第一件事就是打开Burp Suite，对着参数的位置直接上 ' or 1=1#，这是最常见的错误习惯。打个不恰当的比方，这就像没看门牌号就开始敲门——你根本不知道后台拿你的输入做了什么操作，谈何注入？我自己的习惯，永远是先用最“干净”的请求把环境摸一遍。
2.1 先发一次正常请求观察响应
我一般会先按正常用户的操作走一遍：随便填个用户名和密码，比如 admin / 123456，点击登录，观察返回结果。这里要注意几个细节：
- 页面是整页刷新还是Ajax异步刷新，这决定了注入点是否唯一；
- 返回的是“用户名或密码错误”还是直接跳转到某个页面；
- 响应包里的状态码、Set-Cookie、跳转Location是否存在异常；
- URL是GET拼接参数还是POST表单提交，参数名是什么，有没有隐藏字段。
以这道题的常见形态来说，登录接口基本是POST方式，参数名可能是 username 和 password，也可能后台把两个参数都拼进同一条SQL。这时候可以先用一个普通账号试一发，请求包是什么样的、响应体里的报错信息是否可见，这些信息都会直接影响后续payload的构造。
2.2 看页面源码和静态资源
第二个动作，别嫌麻烦，把登录页的HTML源码从头到尾翻一遍。有些题目会在HTML注释里藏提示，比如“SQL语句已拼接完成，错误会直接显示”之类的信息；有些题目会通过JS在本地做参数校验，绕过后台反而对输入比较“宽容”；还有的可能在CSS或JS文件里残留了代码框架名，比如ThinkPHP、Laravel或者老式的原生PHP项目，知道框架后，你就能推测出它的数据库类型和查询写法。
这次的题目我印象里藏了一个很关键的提示——源码里能看到后台使用了较为原始的MySQL拼接查询，这意味着报错注入和联合查询都有发挥空间，同时也意味着注入点十有八九就在用户名参数上。不过，光靠猜测不靠谱，还得实测。
2.3 推测后端的SQL拼接逻辑
正常登录场景的SQL一般长这样：
sql复制SELECT * FROM users WHERE username = '$username' AND password = '$password'
如果后台是这种写法，那么闭合登录查询的方式就是在用户名里注入单引号，注释掉密码校验的部分。但题目如果对单引号做了过滤，或者对 #、-- 这类注释符做了处理，这条路可能走不通。
我通常会在脑子里同时准备几个版本的SQL拼接模型，比如：
sql复制SELECT username, password FROM users WHERE username='$username' LIMIT 1;
或者：
sql复制SELECT * FROM admin WHERE username = "$username" AND pass = "$password"
不同语言、不同框架、不同引号风格，直接决定了我们接下来用什么姿势去闭合语句。这也是为什么第一步“正常请求”那么重要——如果你发的请求响应时间、回显内容有细微差异，其实已经暴露了后端的写法。
3. 注入点确认：让数据库替你说出真相
环境摸清了，接下来才是真正的注入探测。这一阶段的目标不是直接拿数据，而是回答几个核心问题：这里能不能注入？能注入的话，注入点藏在哪里？能不能利用回显把数据带出来？
3.1 单引号测试与报错观察
我习惯在用户名参数上先放一个英文单引号，其他参数保持正常，然后提交。如果后端是直接把字符串拼进SQL且开启了报错显示，响应里大概率会看到类似“SQL语法错误”的信息，甚至直接把SQL片段暴露出来。这一步非常关键，因为它能告诉我们两件事：一是确认存在SQL注入，二是盲猜数据库类型（MySQL、Oracle还是SQLite）。
但在这类比赛题里，比赛方通常不会这么好心让你直接看到SQL结构，更常见的是做了关键词过滤。比如你输入单引号，页面返回“请求被拒绝”或“非法输入”。面对这种情况也别慌，过滤规则本身就是情报，后面可以逐一测试哪个位置被过滤了。
3.2 恒真恒假条件：用逻辑一把尺子量出注入点
如果不想只靠报错，更稳妥的验证方式是用条件恒真和条件恒假来对比响应差异。给个例子，用户名参数传 admin' and 1=1# 和 admin' and 1=2#，如果前者返回“登录成功”或者页面正常渲染，后者返回“用户名不存在”或者渲染异常，那么这里基本可以判定是字符型注入了。原理很简单：1=1 恒真，不影响查询条件；1=2 恒假，导致查询结果为空，页面表现就会跟着不一样。
之所以推荐这种对比法，是因为它不依赖报错信息，也不依赖明显的回显位置，即使后端做了日志记录或简单过滤，只要过滤不彻底，我们仍然能通过“是否登录成功”来分辨状态。
3.3 让数据库字段数量开口
确定了注入点之后，下一步是探字段数。联合查询需要提前知道目标查询返回多少列，否则union后面的select会因为列数不匹配而报错。用 ORDER BY n 是最经典的方式。例如 admin' ORDER BY 1#、admin' ORDER BY 2#……直到排序失败，说明前面的查询只有 n-1 列。
不过这种题大概率会对 ORDER、BY 这些词做过滤，所以后面得动态调整。我打CTF的体会是，不要把所有希望都压在一条万能payload上，而是把探字段数、测过滤、找回显这三步穿插着来。卡住了就换一条思路，别和某个关键词死磕。
4. 摸清“关键词消失术”的边界
到了这一步，很多人才开始真正体会到这道题为什么要叫“BabySQL”。表面上是入门题，实际上它对关键字和符号做了非常精细的过滤。常见的时间过滤方式有：
- 过滤
空格 - 过滤
select/union/where/from/information_schema - 过滤
单引号/双引号 - 过滤
=/--/#等注释符 - 把过滤后的字符串替换成空字符串，但不做严格校验
值得注意的是“替换成空”和“拦截并报错”是两种完全不同的策略。如果后台用的是 preg_replace('/select/i', '', $input) 这种直接把匹配到的内容删掉的写法，那么表面上你发 select，后台实际执行的SQL里根本没有这个词。这也是很多新手卡住的核心原因：明明payload看起来没毛病，但注入死活不执行。
4.1 空格被吃掉后的替代方案
在SQL语法里，空格只是分隔符，并不是必须的。MySQL尤其支持用内联注释 /**/ 代替空格，比如：
sql复制union/**/select/**/1,2,3
在某些过滤规则只拦截空格、不拦截注释符的场景下，这个写法能直接绕过。如果 /**/ 也被过滤了，还可以试试用 %0a、%0b、%0c 等URL编码控制字符当空格用，MySQL对这类空白符的容忍度比想象中高。不过具体能否生效取决于数据库版本和过滤规则，还是要实际试。
4.2 关键字被过滤后的双写绕过
这题给我印象最深的其实是双写绕过。原理非常直白：如果过滤规则是把 select 替换成空字符串，那么我在输入里写 seselectlect，替换逻辑把中间的 select 删掉后，剩下的内容正好是 select。这就像一个层层剥皮的过程，关键在于你写进去的“外皮”多包了一次目标词。
比如：
sql复制ununionion/**/selselectect/**/1,2,3
经过一次“删除敏感词”的处理后，union 中间保留 union，select 中间保留 select，最终到达数据库执行层时仍是一条有效的联合查询语句。这种方式在比赛里极其常见，因为开发者贪方便，用一次简单的正则替换就以为万事大吉，却忽略了多重替换的漏洞。
4.3 摸规则的正确姿势
我建议新手准备一个“过滤器探针列表”，一个一个地试。每次只发一个敏感词，观察响应是报错、闪退还是返回非法输入，记录下来。比如我今天试了这些词：
unionselectfromwhereinformation_schemaandor空格#--'
当你把完整列表跑完，你会发现过滤器的“样子”基本就出来了。它过滤了什么、怎么过滤的、换一种写法能不能绕过，全部有了依据。盲试payload是最容易浪费时间的事情，因为这个试错空间是在计算机规则，而不是盲猜答案。
5. 联合查询被卡死？转堆叠注入才是关键
探测做完以后，真正棘手的问题浮出水面：联合查询虽然能绕开部分关键词，但 information_schema 这个库名大概率被过滤得很死，而且页面可能根本不回显“列位置”的数据。如果你尝试 union select 半天都得不到回显，那就该把思路从联合注入转向堆叠注入。
5.1 为什么联合查询会失效
联合查询失效的原因通常有三类。第一，目标查询的列数和你 select 的列数对不上，导致整条语句直接报错；第二，后台把参数拼接到了两条查询里，比如用户名和密码分别查询，你把payload塞进username，但后端先执行的是另一个查询；第三，过滤规则把 union 或者 select 替换成空字符串后，语句被搞碎了，根本走不到数据库。
这里就要提醒一句：回显位置是联合查询的生命线。如果页面只有“登录成功/失败”两种形态，没有把数据库里的内容渲染出来，那联合查询通常派不上用场，因为它默认要求“前面的查询结果和后面的查询结果能合并展示”。这才是堆叠注入存在的意义。
5.2 堆叠注入的基本前提
所谓堆叠注入（Stacked Injection），本质就是在原始被拼接的SQL语句后面加上分号，然后继续执行另一条独立的SQL语句。比如：
sql复制'; show databases;#
如果后台使用的是支持多语句执行的数据库操作接口（比如MySQL的 mysqli_multi_query 或PDO的某些配置不当的情况），分号后面的语句就会被原样执行。很多人打CTF时忽略这一点，是因为他们在普通业务系统里很难遇到“同时执行多条SQL”的情况，但比赛环境往往会故意提供这种窗口。
堆叠注入的好处是，它不依赖union查询的列数对齐，也不依赖回显位置，只要能执行，就能通过 show、set、select 等语句完成一系列操作。坏处是它对数据库版本、连接方式、框架配置比较敏感，如果后台禁止多语句执行，堆叠注入就完全走不通。
5.3 show 语句在 MySQL 里的妙用
既然堆叠注入能执行多条语句，那我第一步就是用show语句把数据库结构摸出来。重点不是 select，而是这些：
sql复制show databases;
show tables;
show columns from 表名;
show databases 能列出所有数据库名，show tables 能列出当前数据库的所有表，show columns from xxx 能看表的字段结构。整个流程可以完全绕开 information_schema，对过滤 information_schema 的题目来说，简直是救命稻草。
我当时在实际环境里走了一条“关键词列表替代路线”：敏感词被过滤，那就尽量用show家族的语法去替代select查询。show语句本身不查表数据，只查表结构，但CTF题目的flag往往就藏在某个数据库的某张表里的某个字段中，知道表结构和字段名后，用一个简单的select就拿到了。
6. 一步步把 Flag 从数据库里“拉”出来
踩坑归踩坑，流程还是要走得清清楚楚。这里正好把完整的操作链路串起来，从注入到出flag从头到尾过一遍。
6.1 判断数据库名
我先用堆叠注入执行 show databases，如果页面没有直接回显，就用条件判断配合延时，或者想办法把结果带进报错信息里。一个简单的思路是，把查询结果插入到一个自己可控的语句里，再通过报错信息泄露出来。不过在这道题中，我用的是更朴素的方式——让查询结果与某个字段值做比较，通过登录成功/失败的布尔状态判断库名。
库名出来了，通常是一个看起来很随意的名字，比如 ctf、web 或者与题目相关的单词。锁定库名之后，下一步就得想办法把 show tables 限定在这个数据库里执行。可以先执行 use 数据库名，再执行 show tables。别小看 use 语句，它是堆叠注入里非常关键的一步，因为并不是所有数据库操作都默认指向目标库。
6.2 猜表名和字段名
拿到表名后，下一步就是看表结构。经典的思路是：
sql复制show columns from 表名;
如果你的 表名 是敏感词，被过滤了，那就再尝试双写或者用反引号包裹。这里还有一个细节：在MySQL里，反引号 是标识符的引用符号，很多过滤规则不会去检查反引号内部的内容。假设表名是flag，过滤规则把 flag逮住了，你直接写 ``flag` 之类的写法，能不能过去就看规则严格程度了。
我用上面的方法，看到目标表名和字段名后，脑子里基本上已经有了一张“数据地图”。这时候距离最终的结果只差一步——把字段里的值取出来。
6.3 定位目标字段并取出关键数据
拿到了表名和字段名之后，下一步就不能再靠show语句了。因为show毕竟是拿“结构”的，想要具体的数据，还得回到select。这时候我会尝试把 select、from 这些词用双写绕过拼回去，或者结合注释符绕过空格限制。比如：
sql复制'; seselectlect group_concat(flag) from flagtable;#
这里用到了 group_concat() 函数，把多行结果合并到一行里，减少回显调试的工作量。当然，如果过滤规则把函数名也拦截了，那就再试试 concat()、concat_ws()，反正条条大路通罗马。
真正顺利拿flag时的心情反而不怎么激动，因为中间的推理过程已经很明确了：先确定注入点，再摸清过滤规则，然后转到堆叠注入，用show语句侦察结构，最后用select提取数据。一套下来，你会发现这个“BabySQL”其实只是把整个利用链走通了一遍，并没有额外的难题。它真正教会你的，是如何在面对“关键词被吞”时保持冷静、按规则行事。
7. 常见报错与排查速查表
打多了就会发现，这类题目翻来覆去就那么几个坑。我把自己踩过的和身边人常遇到的问题整理成一张表，方便后面快速定位。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 输入单引号后页面空白 | 后台开启了安全模式或异常未处理 | 尝试用布尔盲注替代报错注入，别死等报错信息 |
| union 关键字神秘消失 | 正则匹配并替换空字符串 | 使用 ununionion 双写绕过 |
| 空格被过滤，SQL语句被截断 | 敏感字符拦截，未保持完整语法 | 用 /**/ 或 %0a 代替空格 |
| 堆叠注入执行了但无回显 | 页面不渲染show结果 | 将show结果结合到条件判断中，用布尔状态传导 |
| information_schema 被禁 | 关键字黑名单 | 转而使用show databases / show tables / show columns |
| 表名或字段名被过滤 | 过滤了flag等常见词 | 使用反引号包裹、双写或编码组合尝试 |
| 延时注入始终无效 | 数据库连接不支持sleep或时间被隔离 | 改用大查询量或benchmark()函数，注意数据库版本差异 |
| select 被禁但show能用 | 黑名单不覆盖show语句 | 优先用show，再尝试绕过select，别把所有希望押在union上 |
这张表同样适用于很多相似的登录型注入题目。很多时候卡住的问题，不是因为你不会SQL，而是你把自己锁在了一条固定思路上。换个角度，用另一种SQL语法去探测，难题可能很快就迎刃而解。
8. 复盘时的一点个人体会
打完“BabySQL 1”，我最大的收获不是记住了一串payload，而是养成了一套应对“过滤型注入”的思考习惯。以后再遇到类似的题目，我会先问自己三个问题：后台过滤了哪些词？过滤规则是“替换成空”还是“拦截报错”？有没有绕开过滤后依然可达的SQL通道？只要这三个问题有答案，所谓的“变态过滤”其实都只是纸老虎。
还有一个不太起眼但很实用的经验：准备一个shorter的探测序列，别在一个盲区里反复撞墙。比如我每次先花五分钟把空格、union、select、单引号、注释符这几个关键元素全测一遍，记录下来，再决定用哪一套绕过方案。很多人一开始就把时间浪费在写复杂payload上，结果连最基本的过滤规则都没摸清。还不如先做一遍“体检”，后面每一步都顺畅得多。
最后再分享一个小技巧：这类题做完以后，把完整的利用过程从侦察到取flag写成笔记，保存好payload和过滤规则的变化过程。下一次再遇到“BabySQL 2”“BabySQL 3”这类系列题，直接翻笔记找规律，往往比现场硬推导快得多。CTF这东西，经验就是在一次次复盘里滚出来的，没有捷径。