文章总结： 本文解析sqli-labs第54关通关技巧，该关卡限制10次请求，考察SQL注入实战效率。作者演示了省略常规探测步骤，直接通过UNION注入测试闭合与回显，并利用information_schema快速获取随机表名与字段，最终在有限次数内提取secretkey。文章强调了实战中用最少请求获取最多信息的攻击思维。 综合评分： 92 文章分类： 渗透测试,WEB安全,漏洞分析

SQL注入实战：sqli-labs第54关通关，只允许 10 次请求？教你用 UNION 一次打穿！（Variation 1）

原创

武文学网安 武文学网安

武文学网安

2026年2月5日 03:40 中国香港

大家好，我是武文。

做到 sqli-labs 第 54 关时，我的第一反应是：

“这不就是个 UNION 注入吗？为什么还要叫 Challenge？”

结果真上手就发现不对劲—— 它最大的坑不是闭合方式，也不是列数，而是一个非常“反人类”的限制：

你只有 10 次查询机会（10 queries allowed）。

也就是说，这关不是考你会不会注入，而是考你：

✅ 能不能在极少的请求次数里，把信息一次性榨干。

一、第 54 关整体说明

官方标题： GET – Challenge – Union – 10 queries allowed – Variation 1

核心信息翻译成人话就是：

• GET 参数注入
• UNION 注入
• 限制最多 10 次请求
• 你不能像以前一样慢慢 order by、慢慢试字段

一句话概括：第 54 关不是“能不能注入”，而是“能不能用最少的请求把注入打完”。

先来看一下关卡情况：

根据页面介绍，是需要我们在‘CHALLENGES’数据库的随机表中，在少于10次尝试内导出（密钥）。每次重置时挑战都会随机生成表名、列名和表数据。

二、核心原理：10 次限制到底限制的是什么？

这关限制的是：请求次数 / 查询次数

你每访问一次页面，它后台就会记录一次计数。 超过 10 次以后，页面会直接给你提示（或者拒绝继续响应正常结果）。

所以以前我们常用的“慢慢探路打法”会直接暴毙：

• order by 1/2/3/4...
• union select 1,2,3...
• 试回显位
• 再查库名
• 再查表名
• 再查字段名
• 最后查数据

这套流程动不动 20～50 次请求起步。

在第 54 关，根本没有这个条件。

三、通关策略：把“探测阶段”压缩到最少

这一关最核心的打法思路就是：

✅ 用最少的请求完成两件事

1）确认 闭合方式 2）直接构造一个 高信息量 UNION payload，一次性回显我们要的数据

也就是说：

这关更像“实战”，而不是“练习”。

四、第 54 关实战通关（从闭合测试开始）

下面我按最稳的方式写：尽量少请求，避免浪费次数。

4.1 闭合方式测试（1～2 次内搞定）

先访问正常页面：

?id=1

![](https://mmbiz.qpic.cn/mmbiz_gif/VFf46TKXLVHlbEcrB5QjElOwPxu0PRvZDKAicZJhEiaMYC5pkcszNDegticAea6wvlJDia1wqXTq680uUic6Imt9AlA/640?wx_fmt=gif&from=appmsg#imgIndex=1)

然后试单引号：

?id=1′

![](https://mmbiz.qpic.cn/mmbiz_gif/VFf46TKXLVHlbEcrB5QjElOwPxu0PRvZ8zyuqiafuC1kMoPOIuXY56niaWMYyG2hOec4LnHhgamuUxk2BxCZxZWA/640?wx_fmt=gif&from=appmsg#imgIndex=2)

页面报错异常，说明单引号可能参与语法。

再加注释符尝试闭合：

?id=1′ –+

![](https://mmbiz.qpic.cn/mmbiz_gif/VFf46TKXLVHlbEcrB5QjElOwPxu0PRvZlw2icmzuNa9hbSKPO2ceek4iaFd86tpWBIria2Pv78Moso02z2pYCJxpg/640?wx_fmt=gif&from=appmsg#imgIndex=3)

恢复正常（或页面变化明显），可以确认：

✅ 闭合方式：单引号 ' + 注释 --+

4.2 直接确认 UNION 是否可用（不要 order by 慢慢试）

很多人会先 order by 探列数，但第 54 关不建议这么做。更推荐直接用 union select null 去试列数，命中就继续，不命中就换。

比如先试 3 列（sqli-labs 很多关卡常见）：

?id=-1′ union select 1,2,3 –+

* 用 -1 是为了让原查询返回空数据
* 这样页面只显示 UNION 的结果，回显更干净

![](https://mmbiz.qpic.cn/mmbiz_gif/VFf46TKXLVHlbEcrB5QjElOwPxu0PRvZxSoUUpJsnddYI435LCFpo3HU9SlEbibLw30icSia2vBTMEQaicibJ2Z0Pfw/640?wx_fmt=gif&from=appmsg#imgIndex=4)

页面有回显位（显示了 2 和 3），说明：

✅ UNION 可用 ✅ 当前查询列数至少是 3（且有回显点）。

五、核心通关：

第 54 关的正确姿势是：

5.1 获取表信息

根据初始页面提示，我们是需要拿到CHALLENGES数据库中的表信息。根据information_schema的介绍，我们需要在information_shcema中查找属于challenges的table_name。

所以需要构建这样的payload：

?id=-1′ union select 1,2,groupconcat(tablename) from informationschema.tables where tableschema=’challenges’ –+

![](https://mmbiz.qpic.cn/mmbiz_png/VFf46TKXLVHlbEcrB5QjElOwPxu0PRvZYgl4MgTq0efd1O8AafcUNicaWktTxSpNlE4xJncicAzqSfDWD4iczUzicg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=5)

可以查询出本次表名为：C1UVYYRNID(这里有个注意点：challenges尝试小写，一般情况下MySQL是大小写不敏感的。但我在刚开始用大写一直测试不出来，导致失败了很多次。原因可能是information的内容数据根据底层系统和配置导致大小写敏感。)这一关表名字段名每次都会变，不能照抄，必须先查 information_schema

5.2 获取表格字段信息

构建payload

?id=-1' union select 1,2,group_concat(column_name) from information_schema.columns where table_name='C1UVYYRNID' --+

成功获取表中字段信息：id,sessid,secret_V3NI,tryy

5.3 获取secret key

?id=-1' union select 1,2,group_concat(secret_V3NI) from challenges.C1UVYYRNID --+

可以获取当前的secret key是：aBgLJWvhZzLjbWuNJx9sYpZ1。将其贴入输入栏提交，可以看到恭喜你搞定了(CONGRATS YOU NAILED IT)

结语

第 54 关之所以叫 Challenge，并不是因为注入语法有多难，而是因为它强行把我们从“练习模式”拉到了“实战模式”。

以前做 UNION 注入，我们习惯了慢慢试： 试闭合、试列数、试回显位、再枚举库表字段、最后拿数据。 但在 10 queries allowed 的限制下，这种“探路型打法”会直接把次数耗光。当然我在实际做的时候耗光了很多次数，本文只是展示了成功通关的最短路径。

所以这一关真正考察的是一个能力：

用最少的请求，输出最多的信息。

通关的关键思路就是三步：

1）先用最少请求确认 闭合方式 + UNION 可用 + 回显位 2）通过 information_schema一次查出随机表名和字段名 3）直接 UNION 查询目标字段，拿到 secret key 完成提交

做到这里，我也明显感觉到： SQL 注入从第 54 关开始，不再只是“会不会 payload”，而是“有没有完整的攻击流程思维”。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：武文学网安 武文学网安 武文学网安《SQL注入实战：sqli-labs第54关通关，只允许 10 次请求？教你用 UNION 一次打穿！（Variation 1）》