0x01 前言
最近在代码审计案例复现中遇到一个sql注入漏洞感觉比较有意思,拿出来和大家一块分享一下。
在奇安信攻防社区看到的en0th师傅的文章https://forum.butian.net/share/2465,其中提到了一个分页插件导致的sql注入漏洞。
tkswifty 师傅也对这个漏洞有了一个详细的解释https://www.sec-in.com/article/1088
0x02 案例
payload:
1 | updatexml(1,concat(0x7e,(select+group_concat(table_name)+from+information_schema.tables+where+table_schema%3ddatabase()),0x7e),1) |
预编译的sql语句:
1 | SELECT id, name, create_by, create_time, update_by, update_time, delete_flag FROM li_goods_unit ORDER BY updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schema=database()),0x7e),1) DESC LIMIT ? |
全局搜索PageUtil.initPage
只要使用到这个插件,都有可能存在说sql注入。
0x03 代码审计
1)全局搜索/manager/goods/goodsUnit
定位到漏洞路由处
这里接受了pageNumber
、pageSize
、sort
、order
这几个参数(漏洞就发生在sort
参数)
2)可以看到这块使用了PageUtil
这个分页插件,我们跟进去。
漏洞原因:其中的initPage
函数处理中使用了addOrder
但是没有对sort
进行SQL语句过滤。
1 | public static <T> Page<T> initPage(PageVO page) { |
0x04 漏洞分析
PaginationInnerInterceptor插件
PaginationInnerInterceptor作为plus的分页插件,提供了通用的参数进行统一配置。可以很方便的完成分页的业务逻辑。
具体的分页是通过配置Page对象相关的参数实现的。com.baomidou.mybatisplus.extension.plugins.pagination.page
因为Orderby动态查询没办法进行预编译,所以不经过安全检查的话会存在注入风险。PaginationInnerInterceptor主要是通过设置com.baomidou.mybatisplus.extension.plugins.pagination.page
对象里的属性来实现orderby的,主要是以下函数的调用,因为Orderby动态查询没办法进行预编译,so一下函数直接使用的是sql拼接
1 | page.setAsc(); |
Spring自动绑定
在 Spring框架中,提交请求的数据是通过方法形参来接收的。从客户端请求的 key/value 数据,经过参数绑定,将 key/value 数据绑定到 Controller 的形参上,然后在 Controller 就可以直接使用该形参。
例如:
查看Page的属性,是直接通过sort参数就可以完成对应的分页排序需求
根据spring自动绑定的特性,若此时加入orders参数的传递,同样的后端会进行对应的实体封装,最终带入到sql查询中,同时因为order by场景下MybatisPlus并没有相关的安全措施 ,会导致SQL注入风险。
案例中中的initPage
函数处理中使用了addOrder
但是没有对sort
进行SQL语句过滤,导致存在SQL注入。
0x05 漏洞修复
1)在使用Page对象前对参数进行安全检查
2)全局过滤器,在参数传递到Controller 前进行安全检查
0x06 参考
https://forum.butian.net/share/2465
https://www.sec-in.com/article/1088
0X07 原文地址
转载自公众号:安服仔Yu9
原文地址:https://mp.weixin.qq.com/s/jHqPwfvKWX3QN5CHJcfJiQ