如何阻止SQL injection

    網絡安全成為了現在網際網路的焦點，這也恰恰觸動了每一位使用者的神經，由于設計的漏洞導緻了不可收拾的惡果，驗證了一句話“出來混的，遲早是要還的”，是以我想通過專題博文介紹一些常用的攻擊技術和防範政策。

    具體來說，它是利用現有應用程式，将(惡意)的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架構