用java PreparedStatement就不用擔心sql注入了嗎？

     先感慨下，好久沒寫博客了，一是工作太忙，二是身體不太給力，好在終於查清病因了，趁着今天閑下來，迫不及待與讀者交流，最后忠告一句：身體是活着的本錢！

     言歸正傳，對java有了解的同學基本上都體驗過JDBC，基本都了解PreparedStatement，PreparedStatement相比Statement基本解決了SQL注入問題，而且效率也有一定提升。

     關於PreparedStatement和Statement其他細節我們不討論，只關心注入問題。無論讀者是老鳥還是菜鳥，都需要問一下自己，PreparedStatement真的百分百防注入嗎？

     接下來我們研究一下PreparedStatement如何防止注入，本文以MySQL數據庫為例。

     為了避免篇幅過長，我這里只貼代碼片段，希望讀者能有一定的基礎。

String sql = "select * from goods where min_name = ?";  // 含有參數
PreparedStatement st = conn.prepareStatement(sql);
st.setString(1, "兒童"); // 參數賦值
System.out.println(st.toString()); //com.mysql.jdbc.JDBC4PreparedStatement@d704f0: select * from goods where min_name = '兒童'

     這段代碼屬於JDBC常識了，就是簡單的根據參數查詢，看不出什么端倪，但假如有人使壞，想注入一下呢？

String sql = "select * from goods where min_name = ?";  // 含有參數
PreparedStatement st = conn.prepareStatement(sql);
st.setString(1, "兒童'"); // 參數賦值
System.out.println(st.toString()); //com.mysql.jdbc.JDBC4PreparedStatement@d704f0: select * from goods where min_name = '兒童\''

     簡單的在參數后邊加一個單引號，就可以快速判斷是否可以進行SQL注入，這個百試百靈，如果有漏洞的話，一般會報錯。

     之所以PreparedStatement能防止注入，是因為它把單引號轉義了，變成了\'，這樣一來，就無法截斷SQL語句，進而無法拼接SQL語句，基本上沒有辦法注入了。

     所以，如果不用PreparedStatement，又想防止注入，最簡單粗暴的辦法就是過濾單引號，過濾之后，單純從SQL的角度，無法進行任何注入。

     其實，剛剛我們提到的是String參數類型的注入，大多數注入，還是發生在數值類型上，幸運的是PreparedStatement為我們提供了st.setInt(1, 999);這種數值參數賦值API，基本就避免了注入，因為如果用戶輸入的不是數值類型，類型轉換的時候就報錯了。

     好，現在讀者已經了解PreparedStatement會對參數做轉義，接下來再看個例子。

String sql = "select * from goods where min_name = ?";  // 含有參數
PreparedStatement st = conn.prepareStatement(sql);
st.setString(1, "兒童%"); // 參數賦值
System.out.println(st.toString()); //com.mysql.jdbc.JDBC4PreparedStatement@8543aa: select * from goods where min_name = '兒童%'

     我們嘗試輸入了一個百分號，發現PreparedStatement竟然沒有轉義，百分號恰好是like查詢的通配符。

     正常情況下，like查詢是這么寫的：

String sql = "select * from goods where min_name like ?";  // 含有參數
st = conn.prepareStatement(sql);
st.setString(1, "兒童" + "%"); // 參數賦值
System.out.println(st.toString()); //com.mysql.jdbc.JDBC4PreparedStatement@8543aa: select * from goods where min_name like '兒童%'

     查詢min_name字段以"兒童"開頭的所有記錄，其中"兒童"二字是用戶輸入的查詢條件，百分號是我們自己加的，怎么可能讓用戶輸入百分號嘛！等等！如果用戶非常聰明，偏要輸入百分號呢？

String sql = "select * from goods where min_name like ?";  // 含有參數
st = conn.prepareStatement(sql);
st.setString(1, "%兒童%" + "%"); // 參數賦值
System.out.println(st.toString()); //com.mysql.jdbc.JDBC4PreparedStatement@8543aa: select * from goods where min_name like '%兒童%%'

     聰明的用戶直接輸入了"%兒童%"，整個查詢的意思就變了，變成包含查詢。實際上不用這么麻煩，用戶什么都不輸入，或者只輸入一個%，都可以改變原意。

     雖然此種SQL注入危害不大，但這種查詢會耗盡系統資源，從而演化成拒絕服務攻擊。

     那如何防范呢？筆者能想到的方案如下：

        

          ·直接拼接SQL語句，然后自己實現所有的轉義操作。這種方法比較麻煩，而且很可能沒有PreparedStatement做的好，造成其他更大的漏洞，不推薦。

          ·直接簡單暴力的過濾掉%。筆者覺得這方案不錯，如果沒有嚴格的限制，隨便用戶怎么輸入，既然有限制了，就干脆嚴格一些，干脆不讓用戶搜索%，推薦。

        

     目前做搜索，只要不是太差的公司，一般都有自己的搜索引擎(例如著名的java開源搜索引擎solr)，很少有在數據庫中直接like的，筆者並不是想在like上鑽牛角尖，而是提醒讀者善於思考，每天都在寫着重復的代碼，卻從來沒有停下腳步細細品味。

     有讀者可能會問，為什么我們不能手動轉義一下用戶輸入的%，其他的再交給PreparedStatement轉義？這個留作思考題，動手試一下就知道為什么了。

     注意，JDBC只是java定義的規范，可以理解成接口，每種數據庫必須有自己的實現，實現之后一般叫做數據庫驅動，本文所涉及的PreparedStatement，是由MySQL實現的，並不是JDK實現的默認行為，也就是說，不同的數據庫表現不同，不能一概而論。