SQL注入攻擊是你需要擔心的事情，不管你用什麼web編程技術，再說所有的web框架都需要擔心這個的。你需要遵循幾條非常基本的規則：
1、在構造動態SQL語句時，一定要使用類安全(type-safe)的參數加碼機制。大多數的數據API，包括ADO和ADO.NET，有這樣的支持，允許你指定所提供的參數的確切類型(譬如，字符串，整數，日期等)，可以保證這些參數被恰當地escaped/encoded了，來避免黑客利用它們。一定要從始到終地使用這些特性。
例如，在ADO.NET裏對動態SQL，你可以象下面這樣重寫上述的語句，使之安全：
Dim SSN as String = Request.QueryString(“SSN”)
Dim cmd As new SqlCommand(“SELECT au_lname, au_fname FROM authors WHERE au_id = @au_id”)
Dim param = new SqlParameter(“au_id”, SqlDbType.VarChar)
param.Value = SSN
cmd.Parameters.Add(param)
這將防止有人試圖偷偷注入另外的SQL表達式(因爲ADO.NET知道對au_id的字符串值進行加碼)，以及避免其他數據問題(譬如不正確地轉換數值類型等)。注意，VS 2005內置的TableAdapter/DataSet設計器自動使用這個機制，ASP.NET 2.0數據源控件也是如此。
一個常見的錯誤知覺(misperception)是，假如你使用了存儲過程或ORM，你就完全不受SQL注入攻擊之害了。這是不正確的，你還是需要確定在給存儲過程傳遞數據時你很謹慎，或在用ORM來定製一個查詢時，你的做法是安全的。
2、在部署你的應用前，始終要做安全審評(security review)。建立一個正式的安全過程(formal security process)，在每次你做更新時，對所有的編碼做審評。後面一點特別重要。很多次我聽說開發隊伍在正式上線(going live)前會做很詳細的安全審評，然後在幾周或幾個月之後他們做一些很小的更新時，他們會跳過安全審評這關，推說，“就是一個小小的更新，我們以後再做編碼審評好了”。請始終堅持做安全審評。
3、千萬別把敏感性數據在數據庫裏以明文存放。我個人的意見是，密碼應該總是在單向(one-way )hashed過後再存放，我甚至不喜歡將它們在加密後存放。在默認設置下，ASP.NET 2.0 Membership API 自動爲你這麼做，還同時實現了安全的SALT 隨機化行爲(SALT randomization behavior)。如果你決定建立自己的成員數據庫，我建議你查看一下我們在這裏發表的我們自己的Membership provider的源碼。同時也確定對你的數據庫裏的信用卡和其他的私有數據進行了加密。這樣即使你的數據庫被人入侵(compromised)了的話，起碼你的客戶的私有數據不會被人利用。
4、確認你編寫了自動化的單元測試，來特別校驗你的數據訪問層和應用程序不受SQL注入攻擊。這麼做是非常重要的，有助於捕捉住 (catch)“就是一個小小的更新，所有不會有安全問題”的情形帶來的疏忽，來提供額外的安全層以避免偶然地引進壞的安全缺陷到你的應用裏去。
5、鎖定你的數據庫的安全，只給訪問數據庫的web應用功能所需的最低的權限。如果web應用不需要訪問某些表，那麼確認它沒有訪問這些表的權限。如果web應用只需要只讀的權限從你的account payables表來生成報表，那麼確認你禁止它對此表的 insert/update/delete 的權限。
6、很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用 來防止別人進行手動注入測試。
可是如果通過SQL注入分析器就可輕鬆跳過防注入系統並自動分析其注入點。然後只需要幾分鐘，你的管理員賬號及密碼就會被分析出來。
7、對於注入分析器的防範，筆者通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟件並不是衝着“admin”管理員賬號去的，而是衝着權限（如flag=1）去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。
第三步：既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，爲什麼這麼說呢？筆者想，如果找一個權限最大的賬號製造假象，吸引軟件的檢測，而這個賬號裏的內容是大於千字以上的中文字符，就會迫使軟件對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改數據庫吧。
1、對錶結構進行修改。將管理員的賬號字段的數據類型進行修改，文本型改成最大字段255（其實也夠了，如果還想做得再大點，可以選擇備註型），密碼的字段也進行相同設置。
2、對錶進行修改。設置管理員權限的賬號放在ID1，並輸入大量中文字符（最好大於100個字）。
3、把真正的管理員密碼放在ID2後的任何一個位置
由於SQL注入攻擊針對的是應用開發過程中的編程不嚴密，因而對於絕大多數防火牆來說，這種攻擊是“合法”的。問題的解決只有依賴於完善編程。專門針對SQL注入攻擊的工具較少，Wpoison對於用asp，php進行的開發有一定幫助…。