How to Detect and Exploit MyBatis SQL Injection Vulnerabilities: A Step‑by‑Step Guide

Introduction

SQL injection is a frequent web‑security problem. In Java, prepared statements (<#>) and ORM frameworks reduce the risk, but MyBatis can still be misused. This summary describes the typical vulnerable patterns in MyBatis XML mappers, a concrete audit workflow, and remediation techniques.

Common MyBatis Injection Patterns

1. Fuzzy query (LIKE)

Developers sometimes replace the safe # placeholder with $ to concatenate a user‑supplied value directly into the SQL string, e.g.

SELECT * FROM news WHERE title LIKE '%${title}%'

This enables injection because the value is not escaped. The safe form keeps the # placeholder and uses CONCAT for the wildcard:

SELECT * FROM news WHERE title LIKE CONCAT('%', #{title}, '%')

2. Multiple parameters after IN

Using # inside an IN clause produces a syntax error, and developers may be tempted to build the list with string concatenation. The correct approach is MyBatis’s <foreach> element, which safely iterates over a collection and generates a comma‑separated list of # placeholders.

<select id="queryByIds" resultMap="resultMap">
    SELECT * FROM news WHERE id IN
    <foreach collection="ids" item="id" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

3. ORDER BY clause

Column names cannot be parameterised with #. If a user‑controlled value is inserted with $, an attacker can inject arbitrary SQL. The mitigation is to whitelist allowed column names in Java and map the user‑provided index to a safe column string before passing it to MyBatis.

Practical Audit Steps (Example: MCMS Open‑Source CMS)

Clone the target project and let Maven resolve dependencies: git clone https://gitee.com/mingSoft/MCMS.git Search all XML mapper files for the $ character (e.g., IntelliJ Find in Path with the *.xml filter). Typical files include IContentDao.xml.

Open each candidate mapper and look for statements that concatenate user input, especially those containing LIKE, IN, or ORDER BY.

Trace the mapper ID to the corresponding DAO interface (e.g., IContentDao.java), then to the service implementation ( ContentBizImpl) and finally to the controller ( McmsAction).

Identify how the parameter reaches the mapper. In the example, the request parameter categoryIds is obtained via BasicUtil.getString → SpringUtil.getRequest() without any sanitisation.

Confirm the vulnerability by sending a crafted request. For MySQL the following payload extracts the database version:

http://localhost:8080/ms-mcms/mcms/search.do?categoryId=1') OR updatexml(1,CONCAT(0x7e,(SELECT @@version),0x7e),1)#

The response contains 5.7.27, proving that injection is possible.

Remediation Checklist

Audit MyBatis XML and annotation mappers for the three risky patterns: LIKE with $, IN built by string concatenation, and ORDER BY using $.

When a LIKE is needed, keep the # placeholder and use CONCAT('%', #{param}, '%') instead of manual concatenation.

Replace manual list construction with the <foreach> element to generate safe # placeholders for each element of a collection.

For ORDER BY, maintain a static whitelist of column names in Java and map the user‑supplied index to a safe column string before passing it to MyBatis.

Validate and whitelist all user‑supplied parameters at the Java layer; assume they are malicious.

Pay special attention to SQL generated by MyBatis‑Generator, as it may use $ for ORDER BY clauses.