Preface
SQL injection vulnerabilities are one of the most common vulnerabilities in WEB security. With the use of pre-compilation and various ORM frameworks in Java, injection problems are becoming less and less.
Novice code auditors are often intimidated by the combination of multiple frameworks of Java Web applications. They don't know how to start. They hope to use the SQL injection problem caused by improper use of the Mybatis framework as an example to give them ideas.
One, SQL injection of Mybatis
Mybatis SQL statements can be written on the class method based on annotations, and more are written to xml files in xml format.
The SQL statement in Mybatis needs to be manually written by ourselves or automatically generated by a generator. When writing xml files, Mybatis supports two parameter symbols, one is #, the other is $. such as:
<select id="queryAll" resultMap="resultMap"> SELECT * FROM NEWS WHERE ID = #{id}</select>Use pre-compilation and $ use splicing SQL.
The SQL injection vulnerabilities prone to occur under the Mybatis framework are mainly divided into the following three types:
1. Fuzzy query
Select * from news where title like ‘%#{title}%’In this case, using the # program will report an error, and novice programmers will change the # number to $, so if the java code level does not deal with the content of the user input, it will inevitably cause SQL injection vulnerabilities.
Correct writing:
select * from news where tile like concat(‘%’,#{title}, ‘%’)2. Multiple parameters after in
When using multiple ID queries after in, # will also report an error.
Select * from news where id in (#{ids})The correct usage is to use foreach instead of replacing # with $
id in<foreach collection="ids" item="item" open="("separatosr="," close=")">#{ids} </foreach>3. After order by
This scenario should be mapped at the Java level, set up an array of field/table names, and only allow users to pass in index values. This ensures that the incoming fields or table names are in the whitelist. It should be noted that in the SQL statement automatically generated by mybatis-generator, order by also uses $, and like and in are no problem.
2. Actual combat ideas
We use an open source cms to analyze. The java sql injection problem is suitable for reverse inference. First search xml to find possible injection vulnerability points → reverse push to DAO → then to the implementation class → find the front-end URL through the call chain to find the exploit , Don’t say much
1. Idea import project
Click Get from Version Control on the Idea homepage and enter https://gitee.com/mingSoft/MCMS.git
The download is complete, wait for maven to download the project
2. Search for the $ keyword
Ctrl+shift+F brings up Find in Path, filters the suffix xml, and searches for the keyword $
According to the file name, the xml with Dao is what we need. Take IContentDao.xml as an example, double-click to open, ctrl +F search $, find the first three of the 16 for database selection, skip,
Continue down to see the suspected order by temporarily shelved
Continue to look down and find that there are multiple ordinary splicing, which is easier to use. Let's take this as an example to go deeper and only find where the ids are imported from the front end
3. Search for mapping objects
The select id of Mybatis corresponds to the name of the object to be mapped, and we use getSearchCount as the keyword to search for the mapped object
I found IContentDao.java, IContentDaoimpl.java and McmsAction.java, which correspond to the mapped object, the object's implementation class and the front-end controller respectively, and jump directly to the controler class
It is found that only categoryIds is similar to the target parameter ids, and further confirmation is required. Return to IContentDao.java to continue the reverse deduction according to the standard flow
Find ids as the last parameter of getSearchCount, alt+f7 to view the call chain
Transfer to ContentBizImpl, confirm that the foreground parameter is categoryIds
Return to McmsAction, the parameters are received by BasicUtil.getString,
Follow up BasicUtil.getString
Continue to jump to SpringUtil.getRequest(), the front end has not been processed, and SQL is injected into the real hammer
4. Vulnerability confirmation
When the project is running, construct the sql statement http://localhost:8080/ms-mcms/mcms/search.do?categoryId=1%27)%20%20or+updatexml(1,concat(0x7e,(SELECT+%40%40version ),0x7e),1)%23 Get mysql version 5.7.27, verify that the injection exists.
Three, summary
The above is the basic method of Mybatis's SQL injection audit. There are also problems with several points that we did not analyze. Novices can try to analyze different injection points to do it again. I believe there will be more gains. When we encounter similar problems again, we can consider:
1. Audit SQL injection under the Mybatis framework, focusing on three aspects like, in and order by
2. When writing sql in xml mode, you can first filter the xml file to search for $, analyze one by one, pay special attention to the order by injection of mybatis-generator
3. Mybatis annotation method is similar when writing SQL
4. The java level should do a good job of parameter checking, assuming that the user input is malicious input to prevent potential attacks