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）去的。這樣壹來，無論妳的管理員賬號怎麽變都無法逃過檢測。
第三步：既然無法逃過檢測，那我們就做兩個賬號，壹個是普通的管理員賬號，壹個是防止註入的賬號，為什麽這麽說呢？筆者想，如果找壹個權限最大的賬號制造假象，吸引軟件的檢測，而這個賬號裏的內容是大於千字以上的中文字符，就會迫使軟件對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改數據庫吧。
⒈對表結構進行修改。將管理員的賬號字段的數據類型進行修改，文本型改成最大字段255（其實也夠了，如果還想做得再大點，可以選擇備註型），密碼的字段也進行相同設置。
⒉對表進行修改。設置管理員權限的賬號放在ID1，並輸入大量中文字符（最好大於100個字）。
⒊把真正的管理員密碼放在ID2後的任何壹個位置（如放在ID549上）。
由於SQL註入攻擊針對的是應用開發過程中的編程不嚴密，因而對於絕大多數防火墻來說，這種攻擊是“合法”的。問題的解決只有依賴於完善編程。專門針對SQL註入攻擊的工具較少，Wpoison對於用asp，php進行的開發有壹定幫助...。