wireshark抓包分析mybatis的sql参数化查询

  • 2019 年 10 月 3 日
  • 筆記

  我们使用jdbc操作数据库的时候,都习惯性地使用参数化的sql与数据库交互。因为参数化的sql有两大有点,其一,防止sql注入;其二,提高sql的执行性能(同一个connection共用一个的sql编译结果)。下面我们就通过mybatis来分析一下参数化sql的过程,以及和非参数化sql的不同。

  注意:

    ①本次使用wireshark来监听网卡的请求,测试过程中,如果使用的是本地的mysql的话,java和mysql的交互是不需要经过wireshark的,所以如果是想用wireshark监听网卡的请求,推荐是链接远程的数据库。

    ②本文的项目源代码在文章末尾有链接(项目源代码中也有设计的表的sql)。

    ③可以结合wiereshark的抓包和mysql的general_log一起来查看sql的参数化过程,文章末尾会贴上从mysql的general_log角度检测到useServerPrepStmts=true/false两种执行方式的区别。

  

  一开始,项目中我的db配置如下,我们就先用这个配置来测试一下。

  

jdbc:mysql://xxx.xxx.xxx.xxx:3306/test?characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai

  mapper.xml如下

<?xml version="1.0" encoding="UTF-8" ?>  <!DOCTYPE mapper          PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"          "http://mybatis.org/dtd/mybatis-3-mapper.dtd">  <mapper namespace="mapper.UserMapper">
  <select id="findByName" resultType="domain.User">
  select *
  from `user`
  where user_id = #{name}
  </select>
</mapper>

  测试用例如下:

public class UserMapperTest {        @Test      public void findByPk() throws IOException {          String resource = "mybatis-config.xml";          InputStream inputStream = Resources.getResourceAsStream(resource);          SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);          try (SqlSession session = sqlSessionFactory.openSession()) {              UserMapper mapper = session.getMapper(UserMapper.class);              User user = mapper.findByName("SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG8");              System.out.println(user);          }      }  }

 

  执行测试用例,通过wireshak监听请求,如下:

  从上图wireshark抓到的数据来看,执行查询并没有使用preparestatement,也不是参数化的sql,都是把拼装好参数的sql发送到mysql执行引擎去执行,为什么呢?经过查资料发现,db配置的url配置,漏了一个属性配置分别是useServerPrepStmts,修改后的db的url配置如下:

jdbc:mysql://xxx.xxx.xxx.xxx:3306/test?characterEncoding=utf-8&amp;useSSL=false&amp;serverTimezone=Asia/Shanghai&amp;useServerPrepStmts=true

  增加了useServerPrepStmts属性配置之后,再来执行测试用例,看wireshark抓到的数据如下:

  (ps.如果useServerPrepStmts=true,是通过wireshark抓包结果可以看到,先是发送Request Prepare Statement–sql模板(同一connection第一次执行改sql模板才会发送,后面就不会在发送该Request),再发送Request Execute Statement–sql参数。而useServerPrepStmts=false的话,都是清一色的Request Query,其实就是没用到mysql server的预编译功能,所以是推荐配置useServerPrepStmts=true,提高参数化sql的执行性能)

  上图就是先发送待执行的sql模板(不带参数)到mysql服务端进行预编译,并且会在该请求的response中返回该sql编译之后的id,名曰:Statement ID,wireshark抓到的response数据如下:

  

 

  发送完sql模板之后,从response中拿到statement id之后,紧跟着就发送参数和statement id到mysql执行引擎,wireshark抓到的数据如下:

 

  如此,便可实现sql的参数化查询。按照理解,如果此时再用此sql模板查询另外一个user_id的数据,理论上是不需要再发送sql模板到mysql服务器了的,只需要发送参数和statement ID就可以了的,下面我就试一下,测试用例如下:

    @Test      public void findByPk() throws IOException {          String resource = "mybatis-config.xml";          InputStream inputStream = Resources.getResourceAsStream(resource);          SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);          try (SqlSession session = sqlSessionFactory.openSession()) {              UserMapper mapper = session.getMapper(UserMapper.class);              User user = mapper.findByName("SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG8");              if (user != null || user == null) {                  user = mapper.findByName("SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG8");              }              System.out.println(user);          }      }

  执行测试用例,用wireshark抓包,如下:

  通过上图发现,怎么第二个findByName,压根就没发请求到mysql服务器,原来是因为本地的jdbc发现是相同的查询,直接返回了上一个查询的结果,所以不需要重新到mysql服务器去请求数据。那我在第二个findByName改一个和第一个不一样的参数,测试用例如下:

    @Test      public void findByPk() throws IOException {          String resource = "mybatis-config.xml";          InputStream inputStream = Resources.getResourceAsStream(resource);          SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);          try (SqlSession session = sqlSessionFactory.openSession()) {              UserMapper mapper = session.getMapper(UserMapper.class);              User user = mapper.findByName("SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG8");              if (user != null || user == null) {                  user = mapper.findByName("SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG9");              }              System.out.println(user);          }      }

  执行上面这个测试用例,wireshark抓包结果如下:

  上图发现,竟然两次请求都重复发送了模板sql到mysql服务器预编译,为何呢?原来db的url配置里面还漏了一个属性配置(cachePrepStmts),增加cachePrepStmts配置之后,db的url配置如下:

jdbc:mysql://xxx.xxx.xxx.xxx:3306/test?characterEncoding=utf-8&amp;useSSL=false&amp;serverTimezone=Asia/Shanghai&amp;useServerPrepStmts=true&amp;cachePrepStmts=true

  更新db的url配置之后,再执行测试用例,wireshark抓包结果如下:

 

   通过上图发现,第二次findByName不再发送模板sql了,直接就是发送Execute Statement了,其实Execute Statement就是执行sql的参数和statement ID(该connection第一次预编译模板sq的时候l返回的)。但是中间还是会发一个Reset Statement的mysql数据包,为什么要发这个Reset Statement数据包,有知道的同学,可以评论回复一下,我也还没去深究~谢谢~

   这里附带再说一下mybatis的参数化sql可以防止sql注入的理解,其实防止sql注入,有两点,其一,mybatis本身会有一个sql参数化的过程,这里涉及到mybatis的#和$的区别,参数化sql是用#引用变量,mybatis会对参数进行特殊字符以及敏感字符的转义以防止sql注入;其二,db的url配置中加了useServerPrepStmts=true之后,mysql服务端会对Execute Statement发送的参数中涉及的敏感字符进行转义,以防止sql注入,所以,如果不加useServerPrepStmts=true的话,会发现,mybatis在本地就已经对参数中涉及的敏感字符进行了转义之后,再发往mysql server,可以使用wireshark抓包看到;但是如果是加了useServerPrepStmts=true之后,会发现client发往mysql server的参数(Execute Statement),mybatis不会对其中的参数进行转义了,参数敏感字符转义这一块交给了mysql server去做,也可以通过wireshark抓包看到。so,这里会有两块地方防止sql注入,一块在client,一块在mysql server(使用存储过程防止sql注入也是使用了mysql server的该功能),就看你是否使用useServerPrepStmts。

 

附录:

 1.useServerPrepStmts=false/true,wireshark抓包结果

  useServerPrepStmts=false,wireshark抓包结果如下:

  

  useServerPrepStmts=true,wireshark抓包结果如下:

  

 

2. mysql server的general_log角度检测到useServerPrepStmts=false/true的执行sql

  useServerPrepStmts=false的general_log

  

2019-08-18T15:19:12.330744Z       38 Query    SET autocommit=0  2019-08-18T15:19:12.345704Z       38 Query    select *          from `user`          where user_id = 'SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG8' or 1 = 1 #'  2019-08-18T15:19:12.358669Z       38 Query    select *          from `user`          where user_id = 'SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG9'  2019-08-18T15:19:12.359666Z       38 Query    SET autocommit=1

 

  useServerPrepStmts=true的general_log  

 

2019-08-18T09:39:42.533289Z       30 Query    SET autocommit=0  2019-08-18T09:39:42.546254Z       30 Prepare    select *          from `user`          where user_id = ?  2019-08-18T09:39:42.550244Z       30 Execute    select *          from `user`          where user_id = 'SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG8' or 1 = 1 #'  2019-08-18T09:39:42.560217Z       30 Reset stmt  2019-08-18T09:39:42.561214Z       30 Execute    select *          from `user`          where user_id = 'SYS_APP_d5bwx8AfZXkKewMkOkaZhBv7MWqjiDX3qIkfPkG9'  2019-08-18T09:39:42.563210Z       30 Query    SET autocommit=1

 

 

  最后,附上上面的测试用例:https://download.csdn.net/download/ismallboy/11577637