Everyone is familiar with sql injection. It is a common attack method. The attacker enters some strange sql fragments on the form information or url of the interface, such as the statement "or '1'='1'", which may invade Applications with insufficient parameter validation. So we need to do some work in our application to prevent such attacks. In some applications with high security, such as banking software, the method of replacing all SQL statements with stored procedures is often used to prevent SQL injection. This is of course a very safe method, but in our usual development, it may be There is no need for this rigid approach.
As a semi-automated persistence layer framework, the mybatis framework requires us to manually write its SQL statements. Of course, we need to prevent SQL injection at this time. In fact, Mybatis's sql is a function with "input + output", similar to the structure of the function, as follows:
|
1
2
3
4
|
<select id=“getBlogById“ resultType=“Blog“ parameterType=”
int
”><br>
select id,title,author,content from blog where id=#{id}
</select>
|
Here, parameterType indicates the input parameter type, and resultType indicates the output parameter type. In response to the above, if we want to prevent sql injection, it is a matter of course to work hard on input parameters. The highlighted part in the above code is the part where the input parameters are spliced in sql. After passing in the parameters, print out the executed sql statement, and you will see that the sql is like this:
select id,title,author,content from blog where id = ?
No matter what parameters are entered, the printed sql is like this. This is because mybatis enables the pre-compilation function. Before sql is executed, the above sql will be sent to the database for compilation. When executing, the compiled sql can be used directly, and the placeholder "?" can be replaced. Because SQL injection can only work on the compilation process, this method can avoid the problem of SQL injection.
How does mybatis do sql precompile? In fact, at the bottom of the framework, the PreparedStatement class in jdbc is at work. PreparedStatement is a subclass of Statement that we are familiar with. Its object contains compiled SQL statements. This "ready" approach can not only improve security, but also improve efficiency when executing an sql multiple times, because the sql has been compiled and does not need to be compiled again when executing it again.
Having said that, can we prevent sql injection by using mybatis? Of course not, see the code below:
|
1
2
3
4
5
|
<select id=“orderBlog“ resultType=“Blog“ parameterType=”map”>
select id,title,author,content from blog order by ${orderParam}
</select>
|
On closer inspection, the format of inline parameters has changed from "#{xxx}" to ${xxx}. If we assign the parameter "orderParam" to "id" and print the sql, it looks like this:
select id,title,author,content from blog order by id
Obviously, this cannot prevent SQL injection. In mybatis, parameters in the format "${xxx}" will directly participate in sql compilation, so injection attacks cannot be avoided. However, when it comes to dynamic table names and column names, only the parameter format "${xxx}" can be used. Therefore, such parameters need to be handled manually in the code to prevent injection.
Conclusion: When writing the mapping statement of mybatis, try to use the format of "#{xxx}". If you have to use parameters such as "${xxx}", you must do the filtering manually to prevent SQL injection attacks.