0×00 前言
JeePlus是一款基于代码生成器的javaEE快速开发平台，可以帮助解决java项目中绝大部分的的重复工作，让开发者更多关注业务逻辑。Jeeplus支持单表，主附表，一对一，一对多，多对多，左树右表的直接生成，只需简单配置，就可以生成数千行高质量代码。开发者声称该平台使用目前流行的多种web技术，包括Spring mvc4.0+, MyBatis, Apache Shiro, J2cache,qutarz,spring websocket, Jquery ,BootStrap 等等，支持多种数据库MySQL, Oracle等。 分层设计：使用分层设计，分为dao，service，Controller，view层，层次清楚，低耦合，高内聚。 严格遵循了web安全的规范，前后台双重验证，参数编码传输，密码md5加密存储，shiro权限验证，从根本上避免了SQL注入，XSS攻击，CSRF攻击等常见的web攻击手段。既然这么安全，那么我们从网上下载一份源码来看一看。
通过IDEA导入该源码，我们可以发现其为典型的Maven结构
src/main/java：是java的代码目录
src/main/resources：是资源目录，放一些配置文件，如properties、spring-mvc.xml等
src/main/webapp：是传统项目的WebContent目录
0×01:SQL注入
首先该系统要求登录之后才能使用大部分功能。所以我们先来看看那些功能是不需要登录就可以访问的。通过官网的技术手册我们可以知道该系统采用Apache Shiro来控制权限。于是我们查看Apache Shiro的配置文件，寻找过滤器定义的列表。如图所示。
anon 没有参数，表示可以匿名访问。
authc表示需要认证(登录)才能使用，没有参数
通过以上代码我们可以获取到一批不用登陆就可以访问到的URL。我们抽出一个来看看
此处以resetPassword为例
没有任何处理，跟进findUniqueByProperty接口
上述SQL语句并没有采用JDBC的预编译模式。而是采用了${}这样的写法。这种写法就产生了SQL语句的动态拼接。因为”${xxx}”这样格式的参数会直接参与SQL语句的编译，从而不能避免SQL注入攻击。这是造成mybatis注入的标准写法。
我们构造语句注入即可
同理发现多处存在注入。
Payload:
GET:
/a/sys/user/resetPassword?mobile=13588888888′and (updatexml(1,concat(0x7e,(select user()),0x7e),1))%23
/a/sys/user/validateMobileExist?mobile=13588888888′and (updatexml(1,concat(0x7e,(select user()),0x7e),1))%23
/a/sys/user/validateMobile?mobile=13588888888′and (updatexml(1,concat(0x7e,(select user()),0x7e),1))#
POST:
/a/sys/register/registerUser
roleName=wangba&mobile=13300990099′and (updatexml(1,concat(0x7e,(select user()),0x7e),1))%23&randomCode=2131&loginName=test1&password=123123&confirmNewPassword=123123&ck1=on
通过全局搜索发现系统还有很多地方采用了${}这种写法。这里就不一一标注出来了。
0×02:第三方组件导致的敏感信息泄露
前面我们虽然挖掘到了SQL注入，但是该系统采用魔改的算法进行加密，通过注入查出来的密码无法直接在MD5等平台直接进行解密、而且加密不可逆。相关实现方法如下：
那么怎么办呢？根据网上众多案例，我们可以总结发现，由java开发的项目大部分都存在由第三方组件所导致的漏洞。我们来看看这套程序引用了那些第三方组件呢。通过IDEA我们可以快速的列出我们当前工程所引入的第三方组件包。
我们看到了两个熟悉的组件，druid和fastjson。druid是阿里巴巴开源平台上一个数据库连接池实现，它结合了C3P0、DBCP、PROXOOL等DB池的优点，同时加入了日志监控，可以很好的监控DB池连接和SQL的执行情况。而fastjson则不需要介绍了。大家都很熟悉了，主要用来处理json数据。
根据个人了解,Druid目前是不存在相关漏洞的。但是如果开发者配置不当就可以造成未授权访问，从而导致相关敏感信息泄露。我们来看看web.xml文件
url-pattern 标签中的值是要在浏览器地址栏中输入的 url，可以自己命名，这个 url 访问名为 servlet-name 中值的 servlet
开发者直接配置了映射关系。直接访问url+/druid/ 就可以访问到durid的控制台，在控制台可以直接获取到当前的一些session信息，还可以看到一些JDBC连接信息以及其他的敏感信息。
这一堆session并不是所有都是有效的，具体大家可以抓个包。然后用burp爆破一下。
Payload:
0×03:任意文件上传
系统本身提供了一个文件管理的功能，地址为：http://127.0.0.1/a/sys/file。通过该功能可以对上传文件夹内部的文件进行管理，包括移动，复制，上传，删除，重命名等。
我们找到相关代码，看看功能是如何实现的，是否存在安全问题
从代码逻辑我们可以看到上传过程中完全没有限制上传文件类型以及文件后缀，没有任何安全过滤措施。那么我们直接上传webshell文件即可。而且文件名可控，就连我们的写入路径也是可控的。
根据相关参数信息，我们直接构造上传即可，或者登录后直接在文件管理处上传文件也可以。
前面我们挖掘到session信息泄露。在这里我们没有拿到管理员密码的前提下可以替换session来上传我们的shell。达到getshell的目的
0×04:任意文件下载
文件管理功能还提供了文件下载功能，根据以往经验来看此处很有可能存在任意文件下载，我们继续往下看代码。
这里先定义返回数据类型，在实例化对象，最后读取文件
逻辑上并没有做任何安全限制，例如过滤…等，导致我们可以跨目录读任意文件。直接构造参数读就完事了。
0×05:总结
整体来看这套系统存在的安全问题很多，并没有官网所描述的那样安全，还有很多问题。有很多漏洞都是由于业务功能考虑不全所导致的，可能开发者也没有想到这些功能所带来的危害，所以才会出现这些问题。
在日常渗透过程中，所遇到的由SSM框架开发的系统还是有很多的。大家如果拿到源码不妨试着看一下，说不定会有意外的收货及突破。这篇文章有很多不足，写的也很浅显。只做抛砖引玉。欢迎各位大佬多多指正。
*本文原创作者：Freedom