Everyone is familiar with SQL injection. It is a common attack method. Attackers enter some strange SQL fragments on the form information or URL of the interface, such as "or '1'='1'" statements, which may invade applications with insufficient parameter verification. So we need to do some work in our application to prevent such attack methods. In some applications with high security, such as banking software, we often use the method of replacing all SQL statements with stored procedures to prevent SQL injection. This is of course a very safe way, but we may not need this rigid method in our daily development.
As a semi-automated persistence layer framework, the mybatis framework has to be manually written by ourselves. At this time, of course, it is necessary to prevent SQL injection. In fact, Mybatis' SQL is a structure with "input + output" function, similar to a function, as follows:
<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, we naturally have to work hard on inputting 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 SQL looks 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 precompilation function. Before SQL is executed, the above SQL will be sent to the database for compilation. During execution, you can use the compiled SQL directly and replace the placeholder "?". Because sql injection can only work on the compilation process, this method can avoid the problem of sql injection.
How does mybatis achieve pre-compilation of SQL? 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 one SQL multiple times, because SQL has been compiled and no need to compile when executing again.
Having said that, can we prevent SQL injection by using mybatis? Of course not, please see the following code:
<select id="orderBlog" resultType="Blog" parameterType="map"> select id,title,author,content from blog order by ${orderParam} </select> After careful observation, the format of the inline parameter 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, thus preventing injection attacks. However, when it comes to dynamic table names and column names, we can only use parameter formats like "${xxx}", so we need to manually process such parameters in the code to prevent injection.
Conclusion: When writing mybatis mapping statements, try to use the format "#{xxx}". If you have to use parameters like "${xxx}", you must manually do a good job of filtering to prevent SQL injection attacks.
The above is the full content of the Java persistence layer framework mybatis prevents SQL injection that the editor brings to you. I hope everyone will support Wulin.com more~