Code examples on how Mybatis prevents SQL injection

This article introduces to you the relevant information of Mybatis to prevent sql injection through examples. It is very good and has reference value. Friends in need can refer to it.

SQL injection is familiar to everyone and is a common method. The attack method is that the attacker enters some strange SQL fragments in the form information or URL of the interface, such as statements such as "or '1'='1'", which may invade applications with insufficient parameter verification. Therefore, we need to do some work in our applications to prevent such attacks. In some security applications, such as banking software, it is often used to replace all sql statements with stored procedures to prevent sql injection. This is of course a It's a very safe method, but in our daily development, we may not need this rigid method.

mybatisFrameworkAs a semi-automated persistence layer framework, we have to manually write its SQL statements ourselves. Of course, we need to prevent SQL injection at this time. In fact, Mybatis's sql is a structure with "input + output" function, similar to function, as follows:

<select id="getBlogById" resultType="Blog" parameterType=”int”>
  select id,title,author,content
  from blog where id=#{id}
 </select>

Here, parameterType marks the input The parameter type, resultType indicates the output parameter type. In response to the above, if we want to prevent sql injection, it is natural for us 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 looks like this:

select id,title,author,content from blog where id = ?

No matter what parameters are entered, the sql printed out will be like this. This is because mybatis has enabled the pre-compilation function. Before the sql is executed, the above sql will be sent to the database for compilation. During execution, the compiled sql will be used directly and the placeholder "?" will be replaced. Because sql injection can only affect the compilation process, this method can effectively avoid the problem of sql injection.

How does mybatis achieve sql pre-compilation? 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 very familiar with. Its object contains compiled sql statements. This "ready" approach not only improves security, but also improves efficiency when executing a SQL multiple times. The reason is that the SQL has been compiled and does not need to be compiled again when executed again.

Having said that, can we definitely prevent SQL injection by using mybatis? Of course not, please look at the following code:

<select id="orderBlog" resultType="Blog" parameterType=”map”>
  select id,title,author,content
  from blog order by ${orderParam}
 </select>

Look carefully, the format of the inline parameter has changed from "#{xxx}" to ${xxx}. If we assign the value of "id" to the parameter "orderParam" and print out the sql, it will look like this:

select id,title,author,content from blog order by id

Obviously, this is the case There is no way to prevent sql injection. In mybatis, parameters in the format of "${xxx}" will directly participate in SQL compilation, so injection attacks cannot be avoided. But when it comes to dynamic table names and column names, only parameter formats such as "${xxx}" can be used. Therefore, such parameters need to be processed 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 manually filter them to prevent SQL injection attacks.

The above is the detailed content of Code examples on how Mybatis prevents SQL injection. For more information, please follow other related articles on the PHP Chinese website!