如果乙個普通使用者在使用查詢語句中嵌入另乙個drop table語句，那麼是否允許執行呢?由於drop語句關係到資料庫的基本物件，故要操作這個語句使用者必須有相關的許可權。在許可權設計中，對於終端使用者，即應用軟體的使用者，沒有必要給他們資料庫物件的建立、刪除等許可權。那麼即使在他們使用sql語句中帶有嵌入式的惡意**，由於其使用者許可權的限制，這些**也將無法被執行。故應用程式在設計的時候，最好把系統管理員的使用者與普通使用者區分開來。如此可以最大限度的減少注入式攻擊對資料庫帶來的危害。
對應舉措: 線上資料庫的賬號密碼統一採取新建特定許可權控制的使用者賬號密碼。不讓使用者進行能夠進行刪庫操作。避免注入式攻擊對資料庫帶來的危害。
2、 強迫使用引數化語句。
如果在編寫sql語句的時候，使用者輸入的變數不是直接嵌入到sql語句。而是通過引數來傳遞這個變數的話，那麼就可以有效的防治sql注入式攻擊。也就是說，使用者的輸入絕對不能夠直接被嵌入到sql語句中。與此相反，使用者的輸入的內容必須進行過濾，或者使用引數化的語句來傳遞使用者輸入的變數。引數化的語句使用引數而不是將使用者輸入變數嵌入到sql語句中。採用這種措施，可以杜絕大部分的sql注入式攻擊。不過可惜的是，現在支援引數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用引數化語句。
參考**:
根據是否對應拼接sql用jdbc來執行進行綜合考慮
3、 加強對使用者輸入的驗證。
總體來說，防治sql注入式攻擊可以採用兩種方法，一是加強對使用者輸入內容的檢查與驗證;二是強迫使用引數化語句來傳遞使用者輸入的內容。在sqlserver資料庫中，有比較多的使用者輸入內容驗證工具，可以幫助管理員來對付sql注入式攻擊。測試字串變數的內容，只接受所需的值。拒絕包含二進位制資料、轉義序列和注釋字元的輸入內容。這有助於防止指令碼注入，防止某些緩衝區溢位攻擊。測試使用者輸入內容的大小和資料型別，強制執行適當的限制與轉換。這即有助於防止有意造成的緩衝區溢位，對於防治注入式攻擊有比較明顯的效果。
如可以使用儲存過程來驗證使用者的輸入。利用儲存過程可以實現對使用者輸入變數的過濾，如拒絕一些特殊的符號。如以上那個惡意**中，只要儲存過程把那個分號過濾掉，那麼這個惡意**也就沒有用武之地了。在執行sql語句之前，可以通過資料庫的儲存過程，來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下，應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符，它是sql注入式攻擊的主要**。如注釋分隔符。注釋只有在資料設計的時候用的到。一般使用者的查詢語句中沒有必要注釋的內容，故可以直接把他拒絕掉，通常情況下這麼做不會發生意外損失。把以上這些特殊符號拒絕掉，那麼即使在sql語句中嵌入了惡意**，他們也將毫無作為。
故始終通過測試型別、長度、格式和範圍來驗證使用者輸入，過濾使用者輸入的內容。這是防止sql注入式攻擊的常見並且行之有效的措施。
*例項：jsp使用過濾器防止sql注入*對應參考建議：如果僅在賬號固定輸入 主要是密碼部分可以隨意使用者輸出(1.約束使用者可以輸入密碼的長度(前端後端都加上長度校驗 一般密碼長度在8-10位 後端獲取string型別的長度 如果長度過程就報錯，可以排除後續sql注入的語句) 2.採用post密碼登入方式，get入侵太容易 3.密碼部分進行 特殊字元的替換，密碼經過加鹽 md5加密 密碼層面應該不會導致這樣情況出現
4.如果搜尋查詢 進行字段加上長度校驗 避免很長的字段進行搜尋 (這樣把問題集中在允許長欄位進行搜尋的部分)
4、 多多使用sql server資料庫自帶的安全引數。
為了減少注入式攻擊對於sql server資料庫的不良影響，在sqlserver資料庫專門設計了相對安全的sql引數。在資料庫設計過程中，工程師要盡量採用這些引數來杜絕惡意的sql注入式攻擊。
如在sql server資料庫中提供了parameters集合。這個集合提供了型別檢查和長度驗證的功能。如果管理員採用了parameters這個集合的話，則使用者輸入的內容將被視為字元值而不是可執行**。即使使用者輸入的內容中含有可執行**，則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用parameters集合的另外乙個優點是可以強制執行型別和長度檢查，範圍以外的值將觸發異常。如果使用者輸入的值不符合指定的型別與長度約束，就會發生異常，並報告給管理員。如上面這個案例中，如果員工編號定義的資料型別為字串型，長度為10個字元。而使用者輸入的內容雖然也是字元型別的資料，但是其長度達到了20個字元。則此時就會引發異常，因為使用者輸入的內容長度超過了資料庫字段長度的限制。
一般來說都盡量是預編譯處理
5、 多層環境如何防治sql注入式攻擊?
在多層應用環境中，使用者輸入的所有資料都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的資料應被資料庫拒絕，並向上一層返回乙個錯誤資訊。實現多層驗證。對無目的的惡意使用者採取的預防措施，對堅定的攻擊者可能無效。更好的做法是在使用者介面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程式中驗證資料可以防止簡單的指令碼注入。但是，如果下一層認為其輸入已通過驗證，則任何可以繞過客戶端的惡意使用者就可以不受限制地訪問系統。故對於多層應用環境，在防止注入式攻擊的時候，需要各層一起努力，在客戶端與資料庫端都要採用相應的措施來防治sql語句的注入式攻擊。
參考 主要是長度限制，避免任意長度的輸入 其次是特殊字元的校驗 通常輸入內容不包含特殊字元
6、 必要的情況下使用專業的漏洞掃瞄工具來尋找可能被攻擊的點。
使用專業的漏洞掃瞄工具，可以幫助管理員來尋找可能被sql注入式攻擊的點。不過漏洞掃瞄工具只能發現攻擊點，而不能夠主動起到防禦sql注入攻擊的作用。當然這個工具也經常被攻擊者拿來使用。如攻擊者可以利用這個工具自動搜尋攻擊目標並實施攻擊。為此在必要的情況下，企業應當投資於一些專業的漏洞掃瞄工具。乙個完善的漏洞掃瞄程式不同於網路掃瞄程式，它專門查詢資料庫中的sql注入式漏洞。最新的漏洞掃瞄程式可以查詢最新發現的漏洞。所以憑藉專業的工具，可以幫助管理員發現sql注入式漏洞，並提醒管理員採取積極的措施來預防sql注入式攻擊。如果攻擊者能夠發現的sql注入式漏洞資料庫管理員都發現了並採取了積極的措施堵住漏洞，那麼攻擊者也就無從下手了。
工具沒去尋找
7、設定陷阱賬號：
設定兩個帳號，乙個是普通管理員帳號，乙個是防注入的帳號。將防注入的賬號設定的很象管理員，如 admin，以製造假象吸引軟體的檢測，而密碼是大於千字以上的中文字元，迫使軟體分析賬號的時候進入全負荷狀態甚至資源耗盡而宕機。
8、個人想法：
sql注入分析，起始本質還是前端傳入值到後端去按注入攻擊者的目的去執行對應**。這裡密碼注入，密碼經過特殊字元替換,md5加密，資料庫存放是加密後的密碼。基本不會出現這些情況的發生。那麼例外就是發生在查詢時候，查詢的字段為文字，也就是string型別字段接收。可以採取的措施是底層或者前端進行關鍵字元的替換。另外野路子是最後面加上%，通常這些是模糊查詢。末尾加%不會影響索引以及原先查詢的結果。同時如果是一般型別的sql注入"***x",這種的等於是"***"% 到對應拼接語句就變成"「***x」%",這樣這種語句是報錯的執行失敗。基本欄位是用預編譯也就是#{}，而不是${}
防範sql注入
真沒語言了,公司的 都有這個漏洞,明天趕緊把改了 sql注入式攻擊是利用是指利用設計上的漏洞，在目標伺服器上執行sql命令以及進行其他方式的攻擊 動態生成sql命令時沒有對使用者輸入的資料進行驗證是sql注入攻擊得逞的主要原因。比如 如果你的查詢語句是select from admin where ...
sql 注入防範
關於身份驗證 sql select from user where name name and pwd pwd 假設只知道使用者名稱不知道密碼 1 我們在使用者名稱位置輸入 admin or 1 1 注 內容只有 內的。看看sql會變成什麼 sql select from user where na...
如何防範SQL注入 SQL注入測試
從測試來進行測試sql注入。首先，看看sql注入攻擊能分為以下三種型別 inband 資料經由sql 注入的通道取出，這是最直接的一種攻擊，通過sql注入獲取的資訊直接反映到應用程式的web頁面上 out of band 資料通過不同於sql 注入的方法獲得 譬如通過郵件等 推理 這種攻擊時說並沒有...