2024年7月10日11:35:10评论23 views字数 6026阅读20分5秒阅读模式

从一道CTF题浅谈MyBatis与Ognl的那些事

原文由作者授权，首发在奇安信攻防社区

https://forum.butian.net/share/1749

MyBatis 默认是支持OGNL 表达式的，尤其是在动态SQL中，通过OGNL 表达式可以灵活的组装 SQL 语句，从而完成更多的功能。在特定的情况下可能会存在RCE的风险。

0x01引言

前段时间看了一道CTF题目ezsql

传送门：http://www.yongsheng.site/2022/03/29/d3ctf/
里面的解题过程大概是Mybatis调用时存在SQL注入，然后还存在OGNL注入。

从一道CTF题浅谈MyBatis与Ognl的那些事

看完文章后有一些疑惑：

为什么SQL注入能解析ognl表达式达到RCE的效果？
题目中是通过Provider注解进行sql配置的，xml配置和类似@Select配置也会存在类似的问题吗？
使用#{}预编译后也会存在类似的风险吗？

带着这些疑惑，下面从mybatis的解析流程入手，分析这个case的成因并且看看能不能解决上述提出的疑惑。

从一道CTF题浅谈MyBatis与Ognl的那些事

0x02 mybatis封装SQL流程

提到Mybatis很自然的会想到${}和#{}，看看具体是怎么解析的。

2.1 相关过程

Mybatis的工作流程首先是构建，也就是解析我们写的配置(xml，注解等),将其变成它所需要的对象。然后就是执行，通过前面的配置信息去执行对应的SQL，完成与Jdbc的交互。
简单的分析下具体的流程，案例代码如下：
对应的mapper方法：

从一道CTF题浅谈MyBatis与Ognl的那些事

相关的xml配置：

<select id="getUserByUserName" parameterType="String" resultMap="User">
    select * from users where username like ${username}
</select>

以mybatis 3.5.1为例，将断点下在调用的mybatis mapper方法上，简单的梳理对应的执行流程：

从一道CTF题浅谈MyBatis与Ognl的那些事

首先是org.apache.ibatis.binding.MapperProxy#invoke方法，主要的执行逻辑都在MapperMethod的execute()方法：

从一道CTF题浅谈MyBatis与Ognl的那些事

跟进org.apache.ibatis.binding.MapperMethod#execute方法，首先是SQL类型的判断（INSERT/UPDATE/DELETE/SELECT）:

从一道CTF题浅谈MyBatis与Ognl的那些事

mapper的方法是SELECT的，具体看看SELECT的流程，这里会通过method的返回值的不同调用不同的方法。例如前面的mapper method返回值是List<User>，会返回多行，那么就会调用executeForMany()方法：

从一道CTF题浅谈MyBatis与Ognl的那些事

在org.apache.ibatis.binding.MapperMethod#executeForMany中，核心的是sqlSession.selectList()，具体的sql执行应该是在这里，rowBounds参数从名称上看应该是跟分页有关的：

从一道CTF题浅谈MyBatis与Ognl的那些事

继续跟进，通过MappedStatement#getBoundSql()来获取要执行的sql语句，这里应该会对相关的SQL进行组装：

从一道CTF题浅谈MyBatis与Ognl的那些事

这里主要是通过SqlSource来组装，继续跟进相关的代码：

从一道CTF题浅谈MyBatis与Ognl的那些事

sqlSource主要是个接口，有四个实现类：

StaticSqlSource静态SQL，DynamicSqlSource、RawSqlSource处理过后都会转成StaticSqlSource
DynamicSqlSource处理包含${}、动态SQL节点的
RawSqlSource处理不包含${}、动态SQL节点的
ProviderSqlSource动态SQL，看名称应该是跟类似@SelectProvider注解有关

前面xml里配置的是${username}，如果包含${}的话一般会调用DynamicSqlSource进行解析，跟进具体的代码：

从一道CTF题浅谈MyBatis与Ognl的那些事

在rootSqlNode.apply(context)会对相关的sql节点进行组装，那么就会对root节点进行遍历，调用对应class的apply方法进行解析：

从一道CTF题浅谈MyBatis与Ognl的那些事

这里会遍历所有的SqlNode,然后根据对应的type再次调用对应的apply方法：

从一道CTF题浅谈MyBatis与Ognl的那些事

例如当前mapper的节点的类型为TextSqlNode，会调用其apply方法进行进一步的解析：

从一道CTF题浅谈MyBatis与Ognl的那些事

继续跟进，这里调用了org.apache.ibatis.parsing.GenericTokenParser#parse方法进行处理，主要是删除反斜杠并处理相关的参数(${})：

从一道CTF题浅谈MyBatis与Ognl的那些事

最后把${}包裹的内容提取出来，然后调用BindingTokenParser#handleToken方法进行解析：

从一道CTF题浅谈MyBatis与Ognl的那些事

再往下跟进，这里会调用OgnlCache.getValue方法，从名称看应该是对sql中ognl表达式进行解析，然后替换SQL中对应的${xxx}：

从一道CTF题浅谈MyBatis与Ognl的那些事

完成对应sql的封装后，最终会调用selectList方法完成sql执行的操作，从下图中的Exception信息也可以知道该方法与数据库进行了交互：

从一道CTF题浅谈MyBatis与Ognl的那些事

mybatis的整个封装SQL的流程大体上就是这样子了。
#{}的解析流程类似，主要不同的是BindingTokenParser变成了ParameterMappingTokenHandler，然后在handleToken对将#{}替换成占位符？。

0x03 可能的缺陷

结合前面的CTF题目以及对应的疑惑，这里做一个猜想，mybatis使用不当的话存在sql注入(即输入直接拼接${})的情况，那么根据上面的分析，会调用DynamicSqlSource然后通过OgnlCache进行相应的解析，如果parseExpression方法中解析的expression是一个恶意的ognl表达式的话，那么有可能存在风险：

从一道CTF题浅谈MyBatis与Ognl的那些事

那么如何找到一处可以输入${恶意ognl表达式}，同时能调用DynamicSqlSource通过OgnlCache进行相应的解析的利用点呢？题目里的Provider注解有什么关联呢？

3.1 分析过程

MyBatis 默认是支持OGNL 表达式的，尤其是在动态SQL中，通过OGNL 表达式可以灵活的组装 SQL 语句，从而完成更多的功能。从MyBatis的常见使用方式开始梳理，逐个进行分析：

3.1.1 XML配置

XML配置是比较常用的一种方式。

假设xml配置如下：

<select id="test" parameterType="String" resultMap="User">
    select * from users where username like ${@java.lang.Runtime@getRuntime().exec("open /System/Applications/Calculator.app")}
</select>

根据前面的分析MyBatis处理${}的时候，会使用OGNL计算这个结果值，然后替换SQL中对应的${xxx}。

很明显在调用这个mapper method时，OGNL会计算@java.lang.Runtime@getRuntime().exec("open /System/Applications/Calculator.app")的结果，然后再拼接到原始的SQL中。那么对应的恶意OGNL表达式就会被执行，这里简单写一个controller调用验证猜想。

可以看到提取了${}里的内容，然后OGNL进行了解析，很明显会调用Runtime执行对应的命令：

从一道CTF题浅谈MyBatis与Ognl的那些事

以上是一种比较理想的情况，实际上也不会有人在xml里写恶意的ognl表达式，替换跟覆盖已有的XML也不太现实。

更常见的场景一般是如下配置：

<select id="getUserByUserName" parameterType="String" resultMap="User">
    select * from users where username like ${username}
</select>

如果整个解析顺序如下：

用户输入username->拼接到${}中->调用OGNL解析器解析新的expression

那么确实这里除了SQL注入以外，还可以通过OGNL注入达到上面RCE的效果。显然Mybatis的设计者在设计之初就考虑到了这一个风险，下断点调试，可以看到实际情况在解析时只会解析原有的${username},解析完毕后再把用户输入的值赋予给他。避免了RCE的利用。

从一道CTF题浅谈MyBatis与Ognl的那些事

3.1.2 普通注解

mybatis3提供了注解的方式，常见的有@Select、@Insert、@Update、@Delete，他们跟xml配置中对应的标签语法是类似的。这里一般sql配置是不可控的，跟xml一样没办法操作。

3.1.3 Provider注解

除了上述两种方式以外，MyBatis3提供了使用Provider注解指定某个工具类的方法来动态编写SQL。也就是题目里的注解，常见的注解有：

@SelectProvider
@InsertProvider
@UpdateProvider
@DeleteProvider

本质上Provider指定的工具类只需要返回一个SQL字符串，通过在外部定义好 sql直接引用。

跟进下其封装SQL的过程，前面的过程都是一样的，最后都会通过MappedStatement#getBoundSql()来获取要执行的sql语句，进行相应的组装。

然后会调用org.apache.ibatis.builder.annotation.ProviderSqlSource#getBoundSql进一步组装：

从一道CTF题浅谈MyBatis与Ognl的那些事

相比xml配置，多了一个org.apache.ibatis.builder.annotation.ProviderSqlSource#createSqlSource的调用：

从一道CTF题浅谈MyBatis与Ognl的那些事

继续跟进，调用org.apache.ibatis.builder.annotation.ProviderSqlSource#invokeProviderMethod:

从一道CTF题浅谈MyBatis与Ognl的那些事

因为Provider注解是用户自己编辑的，从对应的参数信息可以看出来这里大致应该是解析相应的外部类，得到对应的SQL，然后返回：

从一道CTF题浅谈MyBatis与Ognl的那些事

PS：在外部类中一般会通过MyBatis 3 提供的工具类org.apache.ibatis.jdbc.SQL或者StringBuilder拼接来生成SQL。

再往下就跟XML配置的解析过程一样了，通过SqlSource来组装，如果SQL中包含${}的话则调用DynamicSqlSource进行解析，最后封装完SQL后调用selectList方法完成sql执行的操作。

相比XML配置方式，其中间会多了一个获取自定义SQL的过程。可以简单的类比为动态生成了一个xml mapper配置。
同时因为是直接进行拼接的，假设内容用户可控的话，那么就可以尝试写入类似${content}的内容，因为包含${}，SQL会有变动的可能，拼接成SQL后会调用DynamicSqlSource通过OgnlCache进行相应的解析，达到RCE的效果。也就是题目里的效果。

3.2 缺陷利用过程

根据前面的猜想，这里以@SelectProvider为例进行验证。
Controller如下：
通过调用mapper的getUserByUserName方法查询对应的用户名信息：

@GetMapping("/mybatis/ognl")
public List<User> mybatisOgnl(@RequestParam("name") String name) {
   return userMapper.getUserByUserName(name);
}

查看对应的Provider实现，传入的参数name通过SQL拼接进行查询，这里明显是存在SQL注入的，可以任意的拼接内容，写入前面提到的${}：

@SelectProvider(type = FindUserByName.class, method = "getUser")
List<User> getUserByUserName(String name);

class FindUserByName {
    public String getUser(String name) {
        String s = new SQL() {
            {
                SELECT("*");
                FROM("users");
                WHERE("username='" + name+"'");
            }
        }.toString();
        return s;
    }
}

根据前面的分析，这里实现的过程可以类比成xml配置中存在如下的select标签：

<select id="getUserByUserName" parameterType="String" resultMap="User">
    select * from users where username like 用户传入的name
</select>

假设name的值是一个ognl表达式的话，mybatis会进行解析，从而达到RCE的效果。

这里将name设置为如下poc进行请求：

${@java.lang.Runtime@getRuntime().exec("open /System/Applications/Calculator.app")}

可以看到ognl正常解析并且执行了对应的命令：

从一道CTF题浅谈MyBatis与Ognl的那些事

到这里已经把整个CTF题目重新完整的“复现一遍”了。相关的问题也有了答案了。

从一道CTF题浅谈MyBatis与Ognl的那些事

0x04 其他

4.1 相关限制

从mybatis从3.5.4开始，在org.apache.ibatis.ognl.OgnlRuntime#InvokeMethod方法中，有一个黑名单机制，当_useStricterInvocation属性为true时，黑名单中的类将不能被使用，例如执行命令要用到的Runtime和ProcessBuilder都在黑名单内：

从一道CTF题浅谈MyBatis与Ognl的那些事

_useStricterInvocation属性在static代码块进行了赋值，默认是true：

从一道CTF题浅谈MyBatis与Ognl的那些事

同样是上面的案例，此时提交对应的poc会抛出异常：

从一道CTF题浅谈MyBatis与Ognl的那些事

但是这个黑名单应该是存在缺陷的，可以考虑Bypass。也有师傅提出了相关的poc。这里暂时不讨论了。

4.2 修复建议

在Provider定义sql时，采用#{}预编译的方式进行查询即可，如果一定要直接进行拼接的话，需要对用户的输入进行安全检查。

PS：实际上Provider指定的工具类只需要返回一个SQL字符串，所以不论是通过MyBatis3 提供的工具类org.apache.ibatis.jdbc.SQL来生成SQL，还是简单的String拼接，都是可能存在类似的问题的。

0x05 参考资料

http://www.yongsheng.site/2022/03/29/d3ctf/

黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途及盈利等目的，否则后果自行承担！

如侵权请私聊我们删文

END

原文始发于微信公众号（黑白之道）：从一道CTF题浅谈MyBatis与Ognl的那些事

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。

左青龙
微信扫一扫

右白虎
微信扫一扫

从一道CTF题浅谈MyBatis与Ognl的那些事

0x01引言

0x02 mybatis封装SQL流程

2.1 相关过程

0x03 可能的缺陷

3.1 分析过程

3.1.1 XML配置

3.1.2 普通注解

3.1.3 Provider注解

3.2 缺陷利用过程

0x04 其他

4.1 相关限制

4.2 修复建议

0x05 参考资料

【CTFer成长之路】反序列化漏洞

【CTFer成长之路】XSS的魔力

CTF - Pwn题之shellcode&栈迁移

第二届长城杯信息安全铁人三项赛（防护赛）总决赛-逆向题解

ACTF 2025 writeup by Mini-Venom

2025蓝桥杯WP（LRT）

UKFC2024 ACTF WP

ACTF 2025 Writeup by Nepnep

流量分析 - No11(解)

Web3互联网取证-2025FIC晋级赛

发表评论

在线咨询

微信