網絡安全成爲了現在互聯網的焦點，這也恰恰觸動了每一位用戶的神經，由於設計的漏洞導致了不可收拾的惡果，驗證了一句話“出來混的，遲早是要還的”，所以我想通過專題博文介紹一些常用的***技術和防範策略。
具體來說，它是利用現有應用程序，將(惡意)的SQL命令注入到後臺數據庫引擎執行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。
記住下面幾條：
1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，可以通過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。
2.永遠不要使用動態拼裝SQL，可以使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫連接，爲每個應用使用單獨的權限有限的數據庫連接。
4.不要把機密信息明文存放，請加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出儘可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝，把異常信息存放在獨立的表中。
通過正則表達校驗用戶輸入
首先我們可以通過正則表達式校驗用戶輸入數據中是包含：對單引號和雙"-"進行轉換等字符。
然後繼續校驗輸入數據中是否包含SQL語句的保留字，如：WHERE，EXEC，DROP等。
通過參數化存儲過程進行數據查詢存取
當我們試圖在URL中嵌入惡意的SQL語句時，參數化存儲過程已經幫我們校驗出傳遞給數據庫的變量不是整形，而且使用存儲過程的好處是我們還可以很方便地控制用戶權限，我們可以給用戶分配只讀或可讀寫權限。
但我們想想真的有必要每個數據庫操作都定義成存儲過程嗎?而且那麼多的存儲過程也不利於日常的維護。
參數化SQL語句
我們知道一旦有惡意SQL代碼傳遞過來，而且被拼接到SQL語句中就會被數據庫執行，那麼我們是否可以在拼接之前進行判斷呢?命名SQL參數。這樣我們就可以避免每個數據庫操作(尤其一些簡單數據庫操作)都編寫存儲過程了，而且當用戶具有數據庫中jobs表的讀權限纔可以執行該SQL語句。
添加新架構
數據庫架構是一個獨立於數據庫用戶的非重複命名空間，您可以將架構視爲對象的容器,也降低了數據庫表名被猜測出來的可能性。
ORM框架
現在開發都採用了框架，很多框架自帶的有一些ORM模塊，可以使用，如果沒使用框架那就過了！
我們在本文中介紹了SQL Injection的基本原理，通過介紹什麼是SQL Injection，怎樣進行SQL Injection和如何防範SQL Injection。 作爲一名Web應用開發人員，一定不要盲目相信用戶的輸入，而要對用戶輸入的數據進行嚴格的校驗處理，否則的 話，SQL Injection將會不期而至。