Db2数据库手工SQL注入实战：从原理到靶场复现

1. 项目概述与核心价值

最近在整理安全测试的笔记，发现关于Db2数据库手工注入的资料相对Oracle、MySQL这些“明星选手”要少得多。正好借着“墨者学院”这个经典的靶场环境，咱们来一次深度的Db2手工注入实战复盘。这不仅仅是复现一个漏洞，更重要的是理解Db2数据库在SQL注入场景下的“脾气秉性”——它的系统表结构、查询语法特性、以及那些与常见数据库截然不同的绕过技巧。如果你对SQL注入的原理已经有所了解，但一遇到Db2就感觉无从下手，或者想系统性地掌握针对不同数据库的差异化测试手法，那这篇从环境搭建到手工注入全流程的详解，应该能给你带来不少实操层面的启发。我们不会依赖任何自动化工具，纯粹用最原始的手工方式，一步步拆解、探测、利用，把每个步骤背后的原理和为什么这么做讲清楚。

2. Db2数据库注入环境与靶场搭建解析

2.1 靶场环境核心架构理解

“墨者学院”提供的这个Db2注入靶场，本质上是一个模拟了真实漏洞场景的Web应用。其核心架构通常是一个前端页面（比如一个搜索框或用户登录框）将用户输入拼接进后端SQL语句中，而该SQL语句最终在IBM Db2数据库上执行。与搭建完整的Db2环境相比，靶场做了简化，但它完整保留了Db2特有的信息模式（SYSCAT/SYSIBM模式下的系统表）、查询语法以及错误回显机制，这对于学习手工注入至关重要。理解这个模拟环境，有助于我们将技巧迁移到真实的Db2数据库测试中。

2.2 Db2与常见数据库的语法关键差异

在动手之前，必须厘清Db2的几个独特之处，这是后续所有注入步骤的基石：

1. 系统表与视图：这是最大的不同。MySQL用information_schema，Oracle用ALL_TABLES，而Db2的核心信息存储在SYSCAT或SYSIBM模式下的视图中。例如，查询表名通常访问SYSCAT.TABLES，查询列名访问SYSCAT.COLUMNS。这些视图的字段名也很有特点，如TABNAME（表名）、TABSCHEMA（模式名）、COLNAME（列名）。
2. 字符串连接符：Db2使用双竖线||进行字符串连接，而不是MySQL的CONCAT()或Oracle的||（虽然Oracle也是||，但函数库不同）。例如，'a'||'b'在Db2中结果是'ab'。
3. 子查询与别名要求：Db2对子查询的语法要求非常严格。在SELECT语句的FROM子句中使用子查询时，必须为子查询结果集赋予一个别名（Alias），否则会报错。这是很多注入新手在Db2上折戟的第一个坑。
4. 错误回显：Db2的错误信息通常比较详细，可能直接暴露出有问题的SQL片段、表名或列名，这对于基于错误注入（Error-based Injection）是非常有利的。
5. 注释符号：Db2支持两种注释：--（两个减号加一个空格）用于单行注释，/* */用于多行注释。在注入拼接时需要注意。

注意：在实际测试中，Db2的版本（如Db2 for LUW, Db2 for iSeries等）和具体配置可能会影响系统视图的可访问性和名称。SYSCAT视图通常包含当前用户有权访问的对象信息，而SYSIBM是更底层的系统基表。大多数情况下，从SYSCAT入手更稳妥。

3. SQL手工注入漏洞测试全流程拆解

手工注入是一个逻辑严密的推理过程，其通用流程可以概括为：探测 -> 判断类型 -> 确定字段数 -> 寻找回显点 -> 获取信息 -> 提取数据。下面我们结合Db2特性，详细分解每个环节。

3.1 初始探测与注入点确认

首先，我们需要找到一个与数据库有交互的功能点，比如URL参数、搜索框、登录框。假设靶场是一个新闻展示页面，URL为http://target/page?id=1。

第一步：基础探测我们尝试提交id=1'（在参数值后添加一个单引号）。观察页面反应：

• 正常：页面显示正常。可能不存在注入，或者注入点不在这里，也可能被过滤了。
• 错误：页面返回数据库错误，例如包含“SQLxxxx”或“未预期的符号”等字样。这强烈暗示存在SQL注入漏洞，且输入被直接拼接到SQL语句中。Db2的错误信息可能直接显示在页面上，这是宝贵的信息源。
• 页面空白或异常：也可能存在注入，触发了语法错误导致应用处理异常。

第二步：逻辑测试进一步确认，使用逻辑判断：

• id=1 and 1=1： 这是一个永真条件。如果页面正常返回与id=1相同的内容，说明and被数据库执行了。
• id=1 and 1=2： 这是一个永假条件。如果页面返回异常（如空白、错误、或无数据），则再次确认了注入点的存在，并且我们可以通过逻辑控制查询结果。

对于Db2，我们还需要测试字符串连接，以验证我们对语法的判断：id=1'||'1。如果原查询是SELECT ... FROM ... WHERE id='$input'，那么拼接后变成WHERE id='1'||'1'，等价于WHERE id='11'。如果页面返回了id=11（假设存在）的内容或正常显示，则证明注入成功且连接符有效。

3.2 确定查询字段数与回显位置

在确认注入点后，我们需要知道当前执行的SQL查询SELECT了多少个字段，以便后续使用UNION查询将我们想要的数据“并”出来。

使用 ORDER BY 确定字段数ORDER BY子句用于根据指定列索引排序。我们可以利用它来探测字段数。

1. 提交：id=1 order by 1。页面正常。
2. 提交：id=1 order by 2。页面正常。
3. 提交：id=1 order by 3。页面正常。
4. 提交：id=1 order by 4。页面返回错误：“ERROR: ORDER BY 位置 4 不在选择列表中”。 这个错误告诉我们，当前查询的字段数小于4。我们最后一次成功的数字是3，因此字段数为3。

实操心得：ORDER BY探测时，数字可以跳跃式增长以提高效率，比如1,5,10,20...当报错后，再在最后一个成功和第一个失败的数字之间进行二分查找，快速定位精确字段数。

使用 UNION SELECT 定位回显点知道字段数是3后，我们构造UNION SELECT语句，将我们可控的数据插入到查询结果中，并观察它们在页面的哪个位置显示出来（即回显点）。

1. 首先，需要使原查询结果为空，以便UNION的结果能显示出来。常用方法是让原查询条件为假：id=-1或id=1 and 1=2。
2. 构造Payload：id=-1 union select 1,2,3 from sysibm.sysdummy1
   • sysibm.sysdummy1是Db2中的一个特殊单行单列表，常用于测试查询而不影响实际数据，类似于Oracle的DUAL表。
   • 如果页面正常显示，并且页面中的某个位置出现了数字“1”、“2”或“3”，那么该位置就是一个回显点。例如，如果页面标题处显示了“2”，正文处显示了“3”，那么第二个和第三个字段就是回显点。

3.3 提取数据库结构信息（库、表、列）

这是注入的核心阶段，目标是获取当前数据库的用户、库名、表名和列名。Db2的系统视图是我们的地图。

获取当前数据库用户和库名在Db2中，“数据库名”的概念有时不如“模式名”（SCHEMA）和“当前用户”直观。我们可以先获取当前会话的授权ID（用户）。

• Payload:id=-1 union select current user, 2, 3 from sysibm.sysdummy1
  • CURRENT USER是Db2内置函数，返回当前会话的授权标识。这个值会显示在第一个回显点（如果我们把它放在select的第一个位置）。
• 获取当前模式：id=-1 union select current schema, 2, 3 from sysibm.sysdummy1
  • CURRENT SCHEMA返回当前默认模式名。在Db2中，表通常属于某个模式。

获取所有表名关键系统视图：SYSCAT.TABLES。它存储了当前用户有权限访问的所有表的信息。

• Payload:id=-1 union select tabname, tabschema, 3 from syscat.tables where tabschema = current schema
  • TABNAME: 表名。
  • TABSCHEMA: 表所属的模式名。这里我们通过where tabschema = current schema过滤出当前模式下的表，避免列出大量系统表。
  • 这个查询会将当前模式下的表名和模式名分别显示在第一个和第二个回显点。

注意事项：SYSCAT.TABLES视图可能包含大量系统表。在实际测试中，我们更关注用户创建的应用表。可以通过观察表名特征（如user,admin,news,product等）来猜测。有时需要结合TYPE字段（'T'表示表，'V'表示视图）进行过滤。

获取指定表的列名假设我们通过上一步，发现了一个可疑的表USERS。接下来要获取它的所有列名。 关键系统视图：SYSCAT.COLUMNS。

• Payload:id=-1 union select colname, 2, 3 from syscat.columns where tabname='USERS' and tabschema = current schema
  • COLNAME: 列名。
  • TABNAME和TABSCHEMA用于精确指定我们要查看哪个模式下的哪个表。
  • 执行后，我们可能会得到类似ID,USERNAME,PASSWORD,EMAIL这样的列名。

3.4 最终数据提取与漏洞利用

掌握了表名（USERS）和列名（USERNAME,PASSWORD）后，我们就可以直接查询其中的敏感数据了。

构造最终查询语句Payload:id=-1 union select username, password, 3 from USERS这个语句会从USERS表中取出username和password字段，并显示在页面的第一和第二个回显点。

处理数据过多或格式问题有时数据很多，或者我们想一次性查看多列。Db2的字符串连接符||就派上用场了。

• Payload:id=-1 union select username || '-' || password, 2, 3 from USERS
  • 这样会将用户名、一个短横线、密码连接成一个字符串，显示在第一个位置。
• 如果想查看前N条记录，可以加上FETCH FIRST N ROWS ONLY子句，类似于MySQL的LIMIT。
  • Payload:id=-1 union select username, password, 3 from USERS fetch first 5 rows only

4. 基于LIKE子句的盲注与时间盲注进阶技巧

网络热词中提到了“oracle 手工sql注入like”，这个思路在Db2中同样适用，尤其是在没有明显错误回显和UNION可用的盲注（Blind Injection）场景下。盲注需要我们像“猜谜”一样，通过询问数据库“是或否”的问题，并根据应用的不同响应（页面内容变化、响应时间差异）来推断信息。

4.1 基于布尔逻辑的盲注（Boolean-Based Blind）

当页面不会直接显示数据库错误或查询数据，但会根据查询结果的真假返回不同的正常页面（例如，有数据时显示详情，无数据时显示“未找到”）时，可以使用布尔盲注。

核心原理：利用AND、OR以及LIKE、SUBSTR等函数，构造一个条件判断。如果条件为真，页面呈现一种状态（A）；为假，则呈现另一种状态（B）。

示例：猜测当前用户名的第一个字符假设我们通过其他方式知道存在一个users表，有username列。我们想猜解管理员用户（比如admin）的密码哈希值的第一位。

1. 首先，我们需要一个能区分真假的参照。例如，id=1返回正常页面（状态A），id=1 and 1=2返回空页面或错误（状态B）。
2. 构造Payload，猜测密码哈希第一位是否为字母‘a’：id=1 and (select substr(password,1,1) from users where username='admin') = 'a'
   • SUBSTR(password,1,1): 这是Db2的字符串截取函数，从password字段的第1位开始，截取1个字符。
   • 如果页面返回状态A（正常），说明第一位是‘a’；如果返回状态B，则不是。
3. 如果不是‘a’，则继续测试‘b’、‘c’...‘f’（假设是MD5哈希）、‘0’-‘9’。这是一个非常耗时的过程，通常需要借助脚本自动化。

结合LIKE进行高效猜测LIKE操作符配合通配符%（匹配任意字符序列）和_（匹配单个字符），可以更高效地进行范围猜测。

• Payload:id=1 and (select password from users where username='admin') LIKE 'a%'
  • 如果为真，说明密码哈希以字母‘a’开头。这比用=一个个猜效率高，因为一次可以确定一个字符集。
• 进一步细化：id=1 and (select password from users where username='admin') LIKE 'ab%'
  • 测试前两位是否是‘ab’。

4.2 基于时间延迟的盲注（Time-Based Blind）

这是最隐蔽的注入方式，适用于无论查询真假，页面HTTP状态码和主体内容都完全不变，仅能通过响应时间差异来判断的情况。Db2中可以利用一些耗时函数来制造延迟。

核心原理：构造一个条件，如果为真，则触发一个时间延迟（如睡眠几秒）；如果为假，则立即返回。通过测量响应时间，来判断条件真假。

Db2中的时间延迟技巧Db2没有像MySQL的SLEEP()或PostgreSQL的PG_SLEEP()那样标准的睡眠函数。但我们可以利用一些计算密集型或循环操作来模拟延迟。这是一种需要谨慎测试的方法，因为可能对数据库造成负载。

• 方法一：使用重复计算或函数调用（不推荐，不稳定且版本依赖性强）。例如，早期一些资料会提到dbms_pipe.receive_message（Oracle风格，Db2不一定有）或构造大量数学运算。
• 方法二（更通用）：利用WAIT FOR语句（需在允许的过程或动态SQL中）或CALL一个执行循环的存储过程。但在注入点，我们通常只能执行查询语句（SELECT），这限制了直接使用这些命令。
• 方法三：基于查询的延时。通过构造一个返回大量数据或进行复杂连接的子查询来消耗时间。例如：id=1 and (select count(*) from syscat.tables a, syscat.tables b, syscat.tables c) > 0
  • 这个子查询对系统表进行了三次笛卡尔积，如果系统表数量多，计算量会非常大，从而导致明显的响应延迟。通过对比注入该条件和不注入时的响应时间，可以判断条件真假。

重要警告：时间盲注，特别是利用复杂查询制造延迟的方法，极具破坏性，可能严重消耗数据库服务器资源，导致服务拒绝（DoS）。仅在获得明确授权的渗透测试环境中使用，并严格控制循环次数和查询复杂度。

自动化工具的角色手工进行盲注，尤其是时间盲注，几乎是不现实的。在实际安全测试中，一旦确认存在盲注漏洞，安全研究人员会使用sqlmap、Burp Suite Intruder等工具，通过设置--technique=T（时间盲注）等参数，并指定--dbms=db2来自动化完成猜解过程。手工部分的价值在于理解其原理，并能够验证工具发现的漏洞。

5. 防御策略与安全编码实践

从防御者角度，理解攻击手法是为了更好地防护。针对SQL注入，尤其是Db2环境，以下措施至关重要：

5.1 使用参数化查询（预编译语句）

这是唯一从根本上解决注入问题的方法。原理是将SQL语句的结构（模板）与数据（参数）分开发送至数据库。数据库先编译SQL结构，再将参数作为纯数据处理，无论参数内容如何，都不会改变原语句的语义。

Java (JDBC) 示例：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; PreparedStatement stmt = connection.prepareStatement(sql); stmt.setString(1, userInputUsername); // 参数1，类型安全 stmt.setString(2, userInputPassword); // 参数2 ResultSet rs = stmt.executeQuery();

Python (ibm_db) 示例：

sql = "SELECT * FROM users WHERE username = ? AND password = ?" stmt = ibm_db.prepare(conn, sql) ibm_db.bind_param(stmt, 1, user_input_username) ibm_db.bind_param(stmt, 2, user_input_password) result = ibm_db.execute(stmt)

5.2 实施最小权限原则

为Web应用连接数据库使用的账户分配绝对最小的权限。这个账户通常只需要对特定的业务表有SELECT、INSERT、UPDATE、DELETE权限，而绝对不应该拥有DROP、CREATE TABLE、GRANT等管理权限，更不应能访问SYSCAT、SYSIBM等系统视图。这样即使发生注入，攻击者能造成的破坏也有限。

5.3 输入验证与过滤（辅助手段）

虽然不能替代参数化查询，但严格的输入验证可以作为第二道防线。

• 白名单验证：对于已知有限集合的输入（如状态码、类型），只接受预定义列表内的值。
• 类型强制转换：对于数字型参数（如id），在代码层面将其强制转换为整数类型，非数字输入会导致转换异常而被拦截。
• 谨慎使用过滤：避免使用简单的黑名单过滤（如移除'、--、||），因为存在无数种绕过方式（编码、双写、注释变形等）。如果必须过滤，应在参数化之后，作为额外的安全层。

5.4 避免详细的错误信息

在生产环境中，配置应用程序和Db2数据库，不要将详细的数据库错误信息直接返回给前端用户。应使用统一的、模糊的错误页面（如“服务器内部错误”）。这可以防止攻击者通过错误回显获取数据库结构、路径等敏感信息，大大增加手工注入的难度。

5.5 定期安全审计与漏洞扫描

对代码进行定期的安全代码审查，重点关注所有SQL拼接的地方。使用动态应用安全测试（DAST）工具对线上应用进行定期的漏洞扫描，模拟攻击行为，及时发现潜在的注入点。同时，保持Db2数据库和中间件（如Web服务器、JDBC驱动）的补丁更新，修复已知的安全漏洞。

手工注入测试是一项需要耐心、细心和深厚知识储备的工作。通过对Db2这样一个特定环境的深入剖析，我们不仅学会了一套攻击方法，更重要的是理解了数据库安全机制的薄弱环节在哪里。无论是作为开发者在编写代码时，还是作为安全人员在评估风险时，这种双向的视角都无比珍贵。真正的安全，始于对攻击链路的深刻理解。