1.前言

oasys是一个OA办公自动化系统,使用Maven进行项目管理,基于springboot框架开发的项目。

下载地址自行在github或gitee寻找即可。

部署流程也不做过多讲解,因为是springboot项目,导入数据库即可正常使用。

1642669561_61e925f955b0aedfea170.png!small

默认端口为8088,1642669600_61e92620b13aa3295604c.png!small

之后正常访问即可。

1642669670_61e9266603f435fda5223.png!small

2.漏洞挖掘

2.1存储XSS

其实XSS的话,这个系统有很多。首先是在用户面板的便签处。

在cn\gson\oasys\controller\user\UserpanelController.java中,savepaper该方法将用户输入的内容直接进行了存储,并没有过滤。从157开始的判断,只是进行了非空判断,而且如果为null的话,也会自动设置默认值之后就进入了save进行保存。

1642669991_61e927a78f2baf73cd3b0.png!small?1642670053008

成功触发。

1642670141_61e9283d7509c295c02ca.png!small

2.2 越权+XSS

在usermanagepaging这个controller中,无任何校验。所以会造成越权。同时用了一个Pageable分页的插件,而size默认设置为了10,所以在访问时,将size参数给一个足够大的值,那么所有用户即可遍历出来。

(PS:此处也有xss,可以看到model添加之后,进行了return,而在拦截器和该方法都没有过滤。)

1642670323_61e928f3dcb95e29b30b8.png!small

在用户管理中,可以建低权限的账号,准备一个低权限的账号。

1642670467_61e929839fae3948fd2a2.png!small

之后用低权限账号登录访问,如果不带参数访问该Controller的话,页面有问题,无法进行查看10条以后的数据。

1642685058_61e96282d830ad10edc7f.png!small

所以还是要利用size参数,在传参的时候可以看到这三个参数都有默认值。而默认是每页显示size(10)条数据,所以就造成了上面的用户数据显示不全的问题。

1642670570_61e929ea66d296d6e55c2.png!small

之后利用将size传入一个较大的数值即可。下断点追踪过程如下:

1642685640_61e964c89ed13032a260a.png!small

可以看到Pageable分页插件,随机输入比较大最大值,是没有爆出一些异常的。而是会将全部数据回显。

1642685725_61e9651d05454c77611af.png!small

到该方法最后,model将数据保存之后,并转发到了usermanagepaging.ftl中。因为此OA用的freemarker进行整合的,所以直接去templates寻找即可。

1642686005_61e9663537524fbf6387c.png!small

之后遍历输出到了界面,细心的人是不是也发现了XSS?

1642686169_61e966d9d0c260ecb114f.png!small?1642686231124

1642670515_61e929b37ccdfc8c93f9d.png!small

但在这里逐渐发现了思路,这个方法没有进行用户登录判断或用户session获取等操作。那是不是就可以造成未授权访问呢?

当换一个浏览器之后,再次访问,被弹回了登录界面,那说明可能存在filter或拦截器。

1642670779_61e92abb2dddcba7d6fae.png!small

直接寻找拦截器即可,因为像springboot的项目很少会整合filter。最终在\java\cn\gson\oasys\common\Interceptor\recordInterceptor找到拦截器。

这下就一目了然了,首先获取了Session。之后进行getAttribute来获取userId。

1642670956_61e92b6c4bc3a8b04bd8e.png!small

直接在此处下断,未登录的情况下并在访问127.0.0.1:8088/usermanagepaging?usersearch=1

这下就更清晰了,现在未登录,所以Attribute为空,条件不成立直接跳回登录页。

1642671137_61e92c2122382157de73a.png!small

1642671250_61e92c92ed598ea412c93.png!small

2.3 SQL注入

在resources\mappers中,发现了mapper文件,在第16行用了$拼接,那么会造成SQL注入,但前提是看一下pinyin这个参数是不是可控。

1642671429_61e92d45408cb879bbcbb.png!small

那就一步步往上跟:

cn.gson.oasys.mappers.AddressMapper接口------>allDirector方法 

1642671586_61e92de2918dd6b95d201.png!small

直接全局搜索,定位到Controller中

1642671656_61e92e28810ceb1732b57.png!small

进入到AddrController中outAddress方法,可以确定在Mapper中pinyin这个参数是可以被利用的。

1642671733_61e92e75cb6012526cbfc.png!small

既然是RequestMapping,不用再去找页面中摸索功能点了。那么直接进行get方式访问。

1642672835_61e932c38ffcc6bb7df7f.png!small

直接扔sqlmap跑一下,但是第一次跑的时候,没出来。

1642672957_61e9333d5b9db33d85b77.png!small

想了一下,可能是没有Cookie的原因。

1642673445_61e935253263f8a130b9d.png!small

直接带上cookie,继续跑。

1642673528_61e93578bfc9b054c233b.png!small

看来果然是Cookie的问题,不一会儿就出来了。

1642673571_61e935a32c8eaec311fb8.png!small

3.结尾

感觉收获到了很多技巧,同时有一些漏洞确实是因为疏忽而造成。

本文作者:Met32, 转自FreeBuf