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

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

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

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

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

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

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

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

1 String sql = "select * from goods where min_name = ?";  // 含有參數
2 PreparedStatement st = conn.prepareStatement(sql);
3 st.setString(1, "兒童'"); // 參數指派
4 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會對參數做轉義，接下來再看個例子。

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

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

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

1 String sql = "select * from goods where min_name like ?";  // 含有參數
2 st = conn.prepareStatement(sql);
3 st.setString(1, "兒童" + "%"); // 參數指派
4 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實作的預設行為，也就是說，不同的資料庫表現不同，不能一概而論。