wireshark抓包分析mybatis的sql引數化查詢
我們使用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&useSSL=false&serverTimezone=Asia/Shanghai&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&useSSL=false&serverTimezone=Asia/Shanghai&useServerPrepStmts=true&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
&n