从CTFHub整数型注入题，聊聊SQL注入那些容易被忽略的细节（MariaDB实战）

从CTFHub整数型注入题剖析SQL注入的深层逻辑与实战技巧

在网络安全领域，SQL注入始终是最具破坏力也最值得深入研究的漏洞类型之一。CTFHub的整数型注入题目看似简单，却蕴含着许多容易被忽视的技术细节。本文将从一个专业渗透测试者的视角，通过这道经典题目，揭示SQL注入中那些鲜为人知的底层原理和实战技巧。

1. 整数型注入与字符型注入的本质差异

许多安全从业者在面对SQL注入时，往往将整数型和字符型注入混为一谈，认为只是引号的区别。实际上，这两种注入类型在Payload构造、绕过技巧和利用方式上存在本质差异。

整数型注入的核心特征在于注入点直接接受数字输入，不需要处理字符串引号和转义问题。这使得Payload构造更加直接，但也带来了一些独特的限制：

-- 典型整数型注入Payload结构 ?id=1 AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)--

相比之下，字符型注入需要处理引号闭合和特殊字符转义：

-- 典型字符型注入Payload结构 ?id=' UNION SELECT null,version(),null-- -

在MariaDB 10.3.22环境中，整数型注入有几个关键优势：

1. 不需要考虑引号闭合问题，Payload更简洁
2. 某些过滤规则对数字型Payload检测较弱
3. 可以直接进行算术运算作为注入向量（如id=1-1）

注意：虽然整数型注入不需要处理引号，但仍需注意注释符号的使用。MariaDB中#和--都是有效注释符，但在URL中#可能被识别为片段标识符。

2. MariaDB特定环境下的information_schema技巧

在CTFHub这道题目中，解题的关键步骤之一是通过information_schema获取数据库结构信息。MariaDB作为MySQL的分支，在information_schema的使用上有一些特殊之处。

2.1 高效查询information_schema的技巧

传统的信息收集方式往往从schemata开始逐层查询，这在实战中效率较低。MariaDB提供了更高效的查询方式：

-- 一次性获取所有数据库、表和列信息 id=-1 UNION SELECT 1, (SELECT GROUP_CONCAT(CONCAT(table_schema,'.',table_name,'.',column_name)) FROM information_schema.columns WHERE table_schema NOT IN ('mysql','information_schema','performance_schema'))

这种方法通过单次查询就能获取整个数据库结构，特别适合在时间受限的CTF比赛中使用。

2.2 MariaDB 10.3.22的特殊行为

在解题过程中，我们发现当使用id=1查询时，UNION SELECT结果不显示，而id=-1却能显示。这是因为：

1. 原查询SELECT * FROM table WHERE id=1返回了结果
2. UNION SELECT的结果集与原查询结果集合并
3. 浏览器通常只显示第一个结果集
4. 当id=-1时，原查询无结果，UNION SELECT的结果自然成为第一个结果集

这个现象揭示了UNION注入的一个重要原则：要让UNION查询的结果显示，必须确保原查询不返回任何结果。

3. UNION查询的深层原理与列数判断技巧

3.1 UNION查询的列数匹配机制

UNION操作要求前后两个SELECT语句的列数相同。传统的ORDER BY判断列数方法虽然有效，但在某些过滤环境下可能被阻断。以下是几种替代方法：

1. UNION SELECT NULL填充法：

   id=-1 UNION SELECT NULL-- id=-1 UNION SELECT NULL,NULL--

   通过逐步增加NULL数量，直到不报错

2. 算术运算推断法：

   id=1/(CASE WHEN (SELECT COUNT(*) FROM information_schema.columns WHERE table_name='users')=5 THEN 1 ELSE 0 END)

   通过除法错误间接判断列数

3. JSON函数利用法（MariaDB 10.2.3+）：

   id=-1 UNION SELECT JSON_ARRAY(1,2,3,4,5)

   通过JSON函数构造特定数量元素

3.2 数据类型匹配的细节

UNION查询不仅要求列数匹配，还要求对应列的数据类型兼容。在解题过程中，我们使用了UNION SELECT 1,version()这样的Payload，这是因为：

1. 第一列通常是整数类型（如自增ID）
2. 第二列可能是字符串类型（如名称、描述）
3. version()返回字符串，因此放在字符串类型的列

在实际渗透测试中，如果数据类型不匹配，可以尝试：

UNION SELECT NULL,CONCAT(1,2,3),NULL--

使用CONCAT或CAST函数确保数据类型兼容。

4. 高级绕过技巧与实战经验分享

4.1 无information_schema的场景应对

在某些加固环境中，information_schema可能被限制访问。MariaDB提供了替代方案：

-- 使用mysql.innodb_table_stats和mysql.innodb_index_stats获取表信息 id=-1 UNION SELECT 1, (SELECT GROUP_CONCAT(table_name) FROM mysql.innodb_table_stats WHERE database_name=DATABASE())

4.2 基于错误的信息提取技术

当UNION注入不可用时，可以考虑基于错误的注入技术：

id=1 AND (SELECT 1 FROM (SELECT COUNT(*),CONCAT(version(),FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a)

这种方法利用MariaDB的重复键错误来泄露信息，特别适合在只有错误回显没有数据回显的场景。

4.3 时间盲注的优化技巧

对于完全无回显的场景，时间盲注是最后的选择。在MariaDB中，可以优化为：

id=1 AND IF(ASCII(SUBSTRING((SELECT password FROM users LIMIT 1),1,1))>100, (SELECT COUNT(*) FROM information_schema.columns A, information_schema.columns B),1)

这种Payload利用了多表连接消耗时间的特性，比简单的SLEEP()更难以被检测。

5. 防御措施与安全开发建议

理解了攻击技术后，我们更应该关注如何有效防御。以下是针对整数型注入的专业防御方案：

1. 参数化查询：

   $stmt = $conn->prepare("SELECT * FROM products WHERE id = ?"); $stmt->bind_param("i", $id);

2. 严格类型转换：

   product_id = int(request.args.get('id'))

3. 最小权限原则：

   CREATE USER 'webapp'@'localhost' IDENTIFIED BY 'password'; GRANT SELECT ON webapp.products TO 'webapp'@'localhost';

4. 深度防御策略：

   • 应用层输入验证
   • 数据库层参数化查询
   • 网络层WAF规则
   • 系统层权限控制

在MariaDB环境中，还可以启用sql_mode=STRICT_ALL_TABLES来强制严格类型检查，防止隐式类型转换导致的注入风险。