XM file mybatis in is how to prevent SQL injection?

Direct use of JDBC scene, if there is stitching SQL statements in the code, it is likely to produce the injection, such as:

1 String sql = "SELECT * FROM users WHERE name ='"+ name + "'";
2 Statement stmt = connection.createStatement();
3 ResultSet rs = stmt.executeQuery(sql);

The wording is safe to use parameterized queries (parameterized queries), namely SQL statement using parameter binding (? Placeholders) and  PreparedStatement, as

1 // use ? to bind variables
2 String sql = "SELECT * FROM users WHERE name= ? ";
3 PreparedStatement ps = connection.prepareStatement(sql);
4 // 参数 index 从 1 开始
5 ps.setString(1, name);

The advantage of using PreparedStatement are:

Under normal circumstances, as the user input parameter values, and SQL injection in the user instruction input as part of SQL, will be compiled / interpreted database. When used  PreparedStatementwith a placeholder (?) Sql statement it will only be compiled once, after performing only the placeholder is replaced with the user input, and does not compile / interpret again, thus preventing SQL injection from a fundamental problem.

In MyBatis using XML files for configuration or Annotation and mapping, interfaces and Java POJOs (Plain Old Java Objects) are mapped to database records

XML examples

Mapper Interface

1 @Mapper
2 public interface UserMapper{
3     User getById(int id);
4 }

 

XML configuration file

1 <select id="getById" resultType = "org.example.User" >
2     SELECT * FROM user WHERE id = #{id}
3 </select>

Annotation example

1 @Mapper
2 public interface UserMapper {
3     @Select("SELECT * FROM user WHERE id= #{id}")
4     User getById(@Param("id") int id);
5 }

 

Use  #{} syntax, MyBatis will automatically generate  PreparedStatement , using the binding parameters (  ?) in a manner to set values, thus  #{} possible to effectively prevent SQL injection.

Use  ${} syntax, MyBatis directly injecting the original string, string concatenation is equivalent to, and therefore cause SQL injection, such as

<select id="getByName" resultType="org.example.User">
    SELECT * FROM user WHERE name = '${name}' limit 1
</select>

 

name value  ' or '1'='1, the statement is actually executed 

1 SELECT * FROM user WHERE name = ''or '1'='1' limit 1

It is recommended to make use of  #{}.

But sometimes, as order by statement, using the  #{} results in an error, such as

ORDER BY #{sortBy}

sortBy parameter value  name , the replacement can be

ORDER BY "name"

That is the string "name" to sort, not sorted by name field

This situation requires the use of ${}

ORDER BY ${sortBy}

Used  ${}, the user needs to manually enter the filter, such as

<select id="getUserListSortBy" resultType="org.example.User">
  SELECT * FROM user 
  <if test="sortBy == 'name' or sortBy == 'email'">
    order by ${sortBy}
  </if>
</select>

Because Mybatis not supported else, you need to default values, you can use choose(when,otherwise)

<select id="getUserListSortBy" resultType="org.example.User">
  SELECT * FROM user 
  <choose>
    <when  test="sortBy == 'name' or sortBy == 'email'">
      order by ${sortBy}
    </when>
    <otherwise>
      order by name
    </otherwise>
    </choose>
</select>

In addition  orderby, there are a number of symbols may be used  ${} , you can use other methods to avoid, such as

like statement

  • The need to use a wildcard (wildcard characters  % and  _), can

  • In the code layer, and the parameter value, plus on both sides  %, and then use #{}

  • Use  bind labels to construct a new parameter, then use #{}

<select id="getUserListLike" resultType="org.example.User">
    <bind name="pattern" value="'%' + name + '%'"/>
    SELECT * FROM user 
    WHERE name LIKE #{pattern}
</select>

 

<select id="getUserListLikeConcat" resultType="org.example.User">
    SELECT * FROM user WHERE name LIKE concat ('%', #{name}, '%')
</select>

In addition to injection problems, there is also the need for the user's input filter, wildcards are not allowed, otherwise the table in the large amount of data, the assumption that the user input  %%, will conduct a full table fuzzy query.

 

 

 



Link website: https: //www.cnblogs.com/JeeMoze/p/10005501.html

Guess you like

Origin www.cnblogs.com/mingjianchen/p/11249501.html