聊聊SQL注入 _生活百科_經(jīng)驗總結

SQL注入問題

概述：
- 首先SQL注入是一個非常危險的操作，很可能被一些不懷好意的人鉆空導致我們系統(tǒng)出現(xiàn)異常等狀況，比如數(shù)據(jù)庫遭到破壞或被入侵。
原因：使用JDBC的Statement語句添加SQL語句
- 由于我們的JDBC在對數(shù)據(jù)庫進行操作時，需要客戶端傳入一些參數(shù) 。我們在日常中的處理是將字符串參數(shù)作為SQL語句進行拼接，但是加入客戶端傳入SQL語句關鍵字惡意篡改SQL語句就會改變服務端SQL語義發(fā)生系統(tǒng)異常。嚴重時就會導致系統(tǒng)和數(shù)據(jù)庫破壞，這時的攻擊方式就叫SQL注入了。
- 實例：模擬登錄請求傳入用戶id和密碼參數(shù)，使用字符串拼接導致的SQL注入。
  - 【聊聊SQL注入】拼接SQL語句，就會出現(xiàn)SQL注入的安全問題，拼接代碼如下：
    String sql = "select * from user where username='" + uid + "' and password='" + passwd + "'";
  - 若此時傳入?yún)?shù)如下：永真式或封號結束注釋后面條件驗證（只能說人的腦洞真大哈哈）
    params.put("uid", "malongfei");params.put("passwd", "111' or '1' = '1");// 或者params.put("uid", "malongfei'; -- ")// 或者params.put("uid", "malongfei'; # ")
  - 此時JDBC還沒意識到安全問題，依舊將以上參數(shù)拼接到我們的SQL原語中，如下：
    select * from user where uid = 'malongfei' and passwd = '111' or '1' = '1';select * from user where uid = 'malongfei'; -- ' and passwd = '111' or '1' = '1';select * from user where uid = 'malongfei'; # ' and passwd = '111' or '1' = '1';
預防SQL注入：使用PreparedStatement代替Statement可以有效防止SQL注入。
- PreparedStatement利用預編譯的機制將sql語句的主干和參數(shù)分別傳輸給數(shù)據(jù)庫服務器，這樣即使參數(shù)中攜帶數(shù)據(jù)庫關鍵字，也不能作為SQL中真正的關鍵字而起作用。
// 后端登錄驗證密碼接口的SQL語句select * from user where uid = ? and passwd = ?;
- 設置黑名單也可提前預防，單純針對于用戶輸入中含有SQL關鍵字的攔截方法，比如在注冊賬號時，用戶名和密碼中不能含有SQL語句關鍵字；
- 或者說在進行SQL拼接時加入邏輯處理，對傳入?yún)?shù)含有SQL關鍵字的進行報輸入異常。
PreparedStatement與 Statment 區(qū)別:
1. 語法不同：PreparedStatement 使用預編譯的sql，而 Statment 使用靜態(tài)的sql
2. 效率不同： PreparedStatement 具有 sql緩存區(qū)，效率比 Statment 高
3. 安全性不同：PreparedStatement 可以有效防止sql注入，而 Statment 不能