In one of my projects, mybatis-plus is used in the dao layer. Since the query conditions are randomly selected and combined by the user, xml uses <if test=""> to stitch the query conditions. Let’s talk about the scene first. At the beginning, there are 3 random combinations of conditions, that is, there are 3 <if test=""> in the xml. The last condition is like fuzzy query. There is no task problem when the project goes online. Later, the business changes, and the first The two <if test=""> are also changed to fuzzy queries.
As shown in the figure below: catName is a fuzzy query, which is spliced in % in xml. Now that the business has changed, the second condition catAddr should also be changed to like module query.
This looks relatively simple, just modify it according to the third condition, and the second condition is changed to
t.cat_addr like '%'||#{catAddr}||'%'
As a result, a problem arises. When the query conditions catAddr and catName appear at the same time, SQL injection will be reported.
It's a ghost~~~~~~~~~
what's going on! ! !
It turns out that when the like fuzzy query splices % in xml, when the fuzzy query condition is spliced in the middle (there is also a query condition after like, for example: select * from tab_cat where cat_age='18' and cat_addr like '%Beijing' and cat_name like '%flower'), mybatis thinks there is sql injection. If the fuzzy query like appears at the end of where, there is no problem.
The solution is also simple, put all the like fuzzy query splicing % into some java code, not splicing in xml.
The splicing% in java is as follows:
params.put("catAddr","%"+catName+"%");//params is a map
In the past, the project code was basically spliced in the java code, and I didn’t think about why. It wasn’t until this time that I found out that there was a reason. Record what happened, warn yourself and remind other friends