❶ 防止sql注入有什麼比較可靠的方法
要防止SQL注入其實不難，你知道原理就可以了。
所有的SQL注入都是從用戶的輸入開始的。如果你對所有用戶輸入進行了判定和過濾，就可以防止SQL注入了。用戶輸入有好幾種，我就說說常見的吧。
文本框、地址欄里***.asp?中？號後面的id=1之類的、單選框等等。一般SQL注入都用地址欄里的。。。。如果要說怎麼注入我想我就和上面的這位「仁兄」一樣的了。
你只要知道解決對嗎？
對於所有從上一頁傳遞過來的參數，包括request.form 、request.qurrystring等等進行過濾和修改。如最常的***.asp?id=123 ，我們的ID只是用來對應從select 里的ID，而這ID一般對應的是一個數據項的唯一值，而且是數字型的。這樣，我們只需把ID的值進行判定，就可以了。vbs默認的isnumeric是不行的，自己寫一個is_numeric更好，對傳過來的參數進行判定，OK，搞定。演算法上的話，自己想想，很容易了。但是真正要做到完美的話，還有很多要計算的。比如傳遞過來的參數的長度，類型等等，都要進行判定。還有一種網上常見的判定，就是判定傳遞參數的那一頁（即上一頁），如果是正常頁面傳弟過來就通過，否則反之。也有對' or 等等進行過濾的，自己衡量就可以了。注意一點就是了，不能用上一頁的某一個不可見request.form("*")進行判定，因為用戶完全可以用模擬的形式「復制」一個和上一頁完全一樣的頁面來遞交參數。
❷ 如何防止SQL注入
一、存儲程序
在學習資料庫視頻的時候接觸過，它是存儲在資料庫中的一些事先編譯好的指令。在用的時候不用重新編寫，直接調用就好了。所以，使用它可以大大提高程序的執行效率。
那麼，如何創建一個存儲程序並使用它呢？這是我們今天要解決的問題。
1.創建過程
可編程性——下拉菜單——存儲過程——右鍵——查詢菜單———指定模板參數的值——新建查詢——輸入語句——查詢菜單中的分析檢查語法是否正確——執行
2.具體創建語法
在創建存儲程序時，為了應對各種變換的數據，通常會涉及到帶參數的存儲程序，其中參數用@來表示。
Create Procere procerename[:number] --[:number]表示一組存儲程序中的第幾個，如果只有一個，此參數可忽略
[@parameter data_type] [default] [OUTPUT] --@parameter表示存儲過程中的參數，default 表示默認值，OUTPUT表示輸出值即輸出值 as SqlStatement --[]代表可選參數
3.具體執行過程
exec[ute] procerename [參數]
舉例：
--創建
CreateProcere
scores @score1smallint， @score2smallint， @score3smallint，
@score4smallint， @score5smallint， @myAvgsmallint Output
--Output可用return來代替
As select @myAvg=(@score1+@score2+@score3+@score4+@score5)/5 --調用過程
Declare@avgscore smallint --將輸出結果放在avgscore中
Execavgscore Output 5,6,7,8,9, --帶有參數的存儲過程調用時，必須加上Output關鍵字，否則SQL會當做參數來對待
小結：存儲程序的創建可分為帶參數和不帶參數，以及含有默認值和輸出值得存儲程序，但是它們的使用原理是一樣的。只是帶輸出值得存儲程序在調用過程中要使用關鍵字Output來對要輸出的變數進行聲明，否則SQL會將它當做參數來處理。
注意：創建存儲程序後，我們可以在編寫程序時，直接調用存儲程序的名稱來代替復雜的查詢語句：
strSQL="select ............;" strSQL="Execute procereName;"
二、參數化SQL
是指在設計與資料庫鏈接並訪問數據時，在需要填入數值或數據的地方，使用參數 (Parameter) 來給值，用@或？來表示參數。
在使用參數化查詢的情況下，資料庫伺服器不會將參數的內容視為SQL指令的一部份來處理，而是在資料庫完成 SQL 指令的編譯後，才套用參數運行，因此就算參數中含有惡意的指令，由於已經編譯完成，就不會被資料庫所運行,因此，可從一定程度上避免SQL注入。
參數化SQL在不同資料庫中支持的方式有一定的差別。SQL server中二者均支持。
在不用的資料庫上基本語法都是一樣的，但在不同的運行平台上客戶端的書寫有不同之處，在這里就拿現在我正在學習的SQL server在.net上執行來舉例。
--SQL
server中的參數化SQL語句: SELECT * FROM myTable WHERE myID = @myID INSERT INTO
myTable (c1, c2, c3, c4) VALUES (@c1, @c2, @c3, @c4)'.在.NET上執行
SqlCommand sqlcmd = new SqlCommand("INSERT INTO myTable (c1, c2, c3, c4) VALUES (@c1, @c2, @c3, @c4)", sqlconn);
sqlcmd.Parameters.AddWithValue("@c1", 1); ' 設定參數 @c1 的值。
sqlcmd.Parameters.AddWithValue("@c2", 2); ' 設定參數 @c2 的值。
sqlcmd.Parameters.AddWithValue("@c3", 3); ' 設定參數 @c3 的值。
sqlcmd.Parameters.AddWithValue("@c4", 4); ' 設定參數 @c4 的值。
sqlconn.Open();
sqlcmd.ExecuteNonQuery();
sqlconn.Close();
在向command中增加參數時，還有其他的方法，如：
sqlcmd.parameters.Add("@c1",SqlDbType.BigInt) 'BigInt為c1的數據類型
sqlcmd.parameter("@c1").value=1 '設定值
三、Regular Expression
簡稱REs是一種非常強大的文字驗證技術。通常我們在設計程序時，如果要在TEXT中輸入數字的話，那麼我們會用到IsNumberic函數來限制，但是
很多情況，為了用戶方便，我們不止要用到限定數字這一個技術，還有很多關系式需要我們去遵循，如手機號碼要限定成11為，郵箱號碼要限制相應的格式等。這
時候就用到了REs這種技術。它可以為我們要輸入的內容提供一個模板，讓用戶的輸入必須遵循這個模板的格式，如果格式不正確，則程序不能繼續執行。這樣也
可以避免SQL注入。
例如
\d -------代表數字
\d{5} -------代表5位數字
\w+@\w+ -------@前的w+表示要有至少一個的字元，@代表這個模板中必須有一個@字元。
當然在使用這種技術之前，是有條件的，首先，它需要引用一個命名空間，具體如下：
Imports RE=System.Text.RegularExpressions.Regex
這樣還不夠，我們需要一個方法來做驗證用戶輸入是否正確的工作，這里，我們要用到一個方法match，具體使用如下：
Dim input,pattern As String
Input=Me.txtInput.TextTrim()
Pattern=Me.txtPattern.Text
If Re.Mathc(input,pattern).Success Then 『使用Match方法來對用戶輸入的內容與定義好的模板進行驗證
MessageBox.Show("True,input matches pattern") Else MessageBox.Show("False,input does not match pattern") End if
以上，是通過看.net視頻總結出來的避免SQL注入的三種方法，由於對專業知識了解有限，具體原理並不清楚，有待以後深入學習後總結。
❸ 什麼是sql注入sql注入有哪些方式防止sql注入又有哪些方式(.Net下)
所謂SQL注入，其實是程序漏洞，沒有什麼技術，比如下面的語句就可能被注入
SQL="SELECT * FROM ADMIN WHERE USER='" &REQUEST("USER")& "' AND PASS ='" &REQUEST("PASS")& "'"
別人可以精心設計一個PASS參數提交給你，使得你的SQL完成其它功能，例如PASS的值為：
abc' OR USER='admin
這時候SQL語句是什麼樣子，你看看：
SELECT * FROM ADMIN WHERE USER='admin' AND PASS='abc' OR USER='admin'
任何密碼都可以成功登錄。
解決的方法：程序應該判斷USER和PASS這些參數裡面是否有引號等特殊符號。
上面是一個簡單的例子，通過提交精心設計的參數，還可以修改你的資料庫。
❹ 如何徹底防止SQL注入
1、對，限制用戶輸入肯定有效
2、應該也可以做到，但正則不是一種高效的方法，用HtmlEncode的方法可以有效防止空格等被DBMS解釋，但注意別把編碼、解碼搞反了；存儲過程是DBMS執行的一段程序，把數據操縱交給存儲過程執行，而不是提交SQL語句，可以有效防止SQL注入。
3、地址欄的Sql攻擊，下面我引用了一段資料解釋，他關於機制說的較清楚，關於解決，只是從客戶端考慮的，實際上用存儲過程等都可以防範。
資料：
首先，入侵者會對一個網站確定可不可以進行注入，假設一篇文章的地址為：http://www.naohou.cn/show.asp?id=325一般會以提交兩個地址來測試，如：
http://www.naohou.cn/show.asp?id=325 and 1=1
http://www.naohou.cn/show.asp?id=325 and 1=2
第一個地址後面加了 and 1=1，構成的SQL語句也就變為了：Select * from 表單名 where id=1 and 1=1這句話要成立就必須and前後語句都成立。那麼前面的文章地址是可以訪問的，後面的1=1也是客觀成立的，那麼第一個地址就可以正常顯示；相反1=2是顯然不成立的，關鍵就看這步了，如果提交and 1=2頁面還是正常顯示說明他並沒有將and 1=2寫入SQL語句，此站也就不存在注入漏洞；但如果提交and 1=2之後返回了錯誤頁面則說明此站點將後面的語句帶入了SQL語句並執行了，也就說明他可以進行SQL注入。（註：如果地址後面跟的是news.asp?id='1'就得變為news.asp?id=1' and '1'='1來補全引號了）
那麼，知道可以注入後入侵者可以做什麼呢？
這里就簡單的說一下，比如提交這樣的地址：
http://www.naohou.cn/show.asp?id=325 and exists (select * from 表名 where 列名=數據)
根據返回的正確或錯誤頁面來判斷猜的表名和列名是否正確，具體實現時是先猜表名再猜列名。當猜出表名和列名之後還可以用ASC和MID函數來猜出各列的數據。MID函數的格式為：mid(變數名,第幾個字元開始讀取,讀取幾個字元)，比如：mid(pwd,1,2)就可以從變數pwd中的第一位開始讀取兩位的字元。ASC函數的格式為：ASC（"字元串"），如：asc("a")就可以讀出字母a的ASCII碼了。那麼實際應用的時候就可以寫為：asc(mid(pwd,1,1))這樣讀取的就是pwd列的第一個字元的ASCII碼，提交： asc(mid(pwd,1,1))>97以返回的頁面是否為正確頁面來判斷pwd列的第一個字元的ASCII碼是否大於97（a的ASCII碼），如果正確就再試是否小於122（z的ASCII碼）……這樣慢慢縮小字元的ASCII碼的范圍，猜到真實的ASCII碼也只是時間的問題。一位一位的猜就可以得到資料庫中的用戶名和密碼了。還有一種ASP驗證缺陷——就是用戶名和密碼都輸'or '1'='1，構造SQL語句Select * form 表單名 where username='' or '1'='1' and pwd='' or '1'='1'就可以達到繞過密碼驗證的目的。
說了那麼多，其實防範的方法很簡單，我們把特殊字元（如and、or、'、"）都禁止提交就可以防止注入了。ASP傳輸數據分為get和post兩種， get是通過將數據添加到URL後提交的方式，post則是利用郵寄信息數據欄位將數據傳送到伺服器。
❺ sql注入攻擊怎麼解決
網路：
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進行的開發有一定幫助...。
❻ 如何解決SQL注入漏洞(盲注)
這個方法就多了，最基本的修改代碼，也可以給iis/apache添加防注入模塊，也可以用防火牆擋掉。
❼ 如何防止sql注入
對於jsp而言我們一般採取一下策略來應對：
1、PreparedStatement
如果你已經是稍有水平開發者,你就應該始終以PreparedStatement代替Statement.
以下是幾點原因
1)、代碼的可讀性和可維護性.
2)、PreparedStatement盡最大可能提高性能.
3)、最重要的一點是極大地提高了安全性.
到目前為止，有一些人（包括本人）連基本的惡義SQL語法都不知道.
String sql = "select * from tb_name where name= '"+varname+"' and passwd='"+varpasswd+"'";
如果我們把[' or '1' = '1]作為name傳入進來.密碼隨意,看看會成為什麼?
select * from tb_name = 'or '1' = '1' and passwd = '隨意' ;
因為'1'='1'肯定成立,所以可以任何通過驗證.更有甚者:
把['; drop table tb_name; ]作為varpasswd傳入進來,則:
select * from tb_name = '隨意' and passwd = ''; drop table tb_name; 有些資料庫是不會讓你成功的,但也有很多資料庫就可以使這些語句得到執行.
而如果你使用預編譯語句.你傳入的任何內容就不會和原來的語句發生任何匹配的關系.(前提是資料庫本身支持預編譯,但上前可能沒有什麼服務端資料庫不支持編譯了,只有少數的桌面資料庫,就是直接文件訪問的那些只要全使用預編譯語句,你就用不著對傳入的數據做任何過慮.而如果使用普通的 statement,有可能要對drop,; 等做費盡心機的判斷和過慮.
2、正則表達式
2.1、檢測SQL meta-characters的正則表達式 /(\%27)|(\')|(\-\-)|(\%23)|(#)/ix
2.2、修正檢測SQL meta-characters的正則表達式 /((\%3D)|(=))[^\n]*((\%27)|(\')|(\-\-) |(\%3B)|(:))/i
2.3、典型的 SQL 注入攻擊的正則表達式 /\w*((\%27)|(\'))((\%6F)|o|(\%4F))((\%72)|r|(\ ))/ix
2.4、檢測SQL注入，UNION查詢關鍵字的正則表達式 /((\%27)|(\'))union/ix(\%27)|(\') - 單引號和它的hex等值union - union關鍵字。
2.5、檢測MS SQL Server SQL注入攻擊的正則表達式 /exec(\s|\+)+(s|x)p\w+/ix
3、字元串過濾
public static String filterContent(String content){
String flt ="'|and|exec|insert|select|delete|update|count|*|%
|chr|mid|master|truncate|char|declare|; |or|-|+|,";
Stringfilter[] = flt.split("|");
for(int i=0; i {
content.replace(filter[i], "");
}
return content;
}
4、不安全字元屏蔽
本部分採用js來屏蔽，起的作用很小，這樣用屏蔽關鍵字的方法雖然有一定作用，但是在實際應用中這些 SQL的關鍵字也可能成為真正的查詢關鍵字，到那是被你屏蔽了那用戶不是不能正常的使用了。 只要在代碼規范上下點功夫就可以了。
凡涉及到執行的SQL中有變數時，用JDBC（或者其他數據持久層）提供的如：PreparedStatement就可以 ，切記不要用拼接字元串的方法就可以了.
功能介紹：檢查是否含有"'","\\","/"
參數說明：要檢查的字元串
返回值：0：是 1：不是
函數名是
function check(a)
{
return 1;
fibdn = new Array ("'" ,"\\","/");
i=fibdn.length;
j=a.length;
for (ii=0; ii { for (jj=0; jj
{ temp1=a.charAt(jj);
temp2=fibdn[ii];
if (tem'; p1==temp2)
{ return 0; }
}
}
return 1;
}
❽ T-SQL篇如何防止SQL注入的解決方法(2)
/// <summary> ///SqlInject 的摘要說明 /// </summary> public class SqlInject : System.Web.UI.Page { //檢測到注入後的處理方式: 0:僅警告；1：警告+記錄；2：警告+自定義錯誤頁面；3：警告+記錄+自定義錯誤頁面 private const int _type = 0; private const string errRedirectPage = "/err.aspx"; //如果記錄注入信息，那麼請設置：errMDBpath：資料庫路徑 private const string errMDBpath = "/SqlInject.mdb"; //過濾特徵字元 //過濾特徵字元 private static string StrKeyWord = ConfigurationManager.AppSettings["SqlKeyWord"]; //@"select|insert|delete|from|count(|drop table|update|truncate|asc(|mid(|char(|xp_cmdshell|exec|master|net local group administrators|net user|or|and"; private static string StrRegex = ConfigurationManager.AppSettings["SqlRegex"]; //@";|/|(|)|[|]|{|}|%|@|*|'|!"; // 原始過濾條件：【-|;|,|/|(|)|[|]|{|}|%|@|*|'|!】 private HttpRequest request; public SqlInject(System.Web.HttpRequest _request) { this.request = _request; } ///<summary> ///檢測SQL注入及記錄、顯示出錯信息 ///</summary> public void CheckSqlInject() { bool isInject = false; if (CheckRequestQuery() || CheckRequestForm()) { isInject = true; } else { return; } switch (_type) { case 0: ShowErr(); break; case 1: ShowErr(); SaveToMdb(); break; case 2: ShowErr(); string temp; System.Web.HttpContext.Current.Response.Write("<script>setTimeout(\"" + "location.href='" + errRedirectPage + "'" + "\",5000)</script>"); break; case 3: ShowErr(); SaveToMdb(); System.Web.HttpContext.Current.Response.Write("<script>setTimeout(\"" + "location.href='" + errRedirectPage + "'" + "\",5000)</script>"); break; default: break; } System.Web.HttpContext.Current.Response.End(); } private void SaveToMdb() { OleDbConnection conn = new OleDbConnection("Provider=Microsoft.JET.OLEDB.4.0;Data Source=" + Server.MapPath(errMDBpath)); conn.Open(); OleDbCommand cmd = conn.CreateCommand(); cmd.CommandText = "insert into [Record] (sIP,sDate,sPath) values ('" + request.ServerVariables["REMOTE_ADDR"].ToString() + "','" + DateTime.Now + "','" + request.ServerVariables["URL"].ToLower() + RelaceSingleQuotes(request.QueryString.ToString()) + "')"; int code = cmd.ExecuteNonQuery(); if (code == 1) 75: System.Web.HttpContext.Current.Response.Write("<br>****以上信息已記錄至日誌資料庫****"); else System.Web.HttpContext.Current.Response.Write("<br>日誌資料庫出錯"); conn.Close(); } private string RelaceSingleQuotes(string _url) { string URL = _url.Replace("'", "單引號"); return URL; } private void ShowErr() { //string msg = @"<font color=red>請不要嘗試未授權之入侵檢測！');javascript:history.go(-1);</script>"); } ///<summary> /// 特徵字元 ///</summary> public static string KeyWord { get { return StrKeyWord; } } ///<summary> /// 特徵符號 ///</summary> public static string RegexString { get { return StrRegex; } } ///<summary> ///檢查字元串中是否包含Sql注入關鍵字 /// <param name="_key">被檢查的字元串</param> /// <returns>如果包含注入true;否則返回false</returns> ///</summary> private static bool CheckKeyWord(string _key) { string[] pattenString = StrKeyWord.Split('|'); string[] pattenRegex = StrRegex.Split('|'); foreach (string sqlParam in pattenString) { if (_key.Contains(sqlParam + " ") || _key.Contains(" " + sqlParam)) { return true; } } foreach (string sqlParam in pattenRegex) { if (_key.Contains(sqlParam)) { return true; } } return false; } ///<summary> ///檢查URL中是否包含Sql注入 /// <param name="_request">當前HttpRequest對象</param> /// <returns>如果包含注入true;否則返回false</returns> ///</summary> public bool CheckRequestQuery() { if (request.QueryString.Count > 0) { foreach (string sqlParam in this.request.QueryString) { if (sqlParam == "__VIEWSTATE") continue; if (sqlParam == "__EVENTVALIDATION") continue; if (CheckKeyWord(request.QueryString[sqlParam].ToLower())) { return true; }
❾ 如何防止sql注入，常用的方法和優缺點
一般都是用關鍵字對比和正則表達式檢測那些不能出現在當前SQL語句中的關鍵字，因不同的資料庫系統SQL語句有差別，缺乏通用的方法。
❿ 如何徹底解決sql注入
最安全的方法也是最麻煩的方法就是一個一個分析,從而保證字元全部是過濾了的.另外很少有人用手工入注,一般一些小黑都是用 Domain 工具嘛死的很好防範.我也寫過一個
你可以看看: http://tbxy.blog.com.cn/archives/2006/1443348.shtml
另外一般比如動易等大型商業系統漏洞都比較少!