1. sql注入攻擊的種類和防範手段有哪些
暈，這不是C#考題嗎。
SQL注入攻擊的種類
知彼知己，方可取勝。首先要清楚SQL注入攻擊有哪些種類。
1.沒有正確過濾轉義字元
在用戶的輸入沒有為轉義字元過濾時，就會發生這種形式的注入式攻擊，它會被傳遞給一個SQL語句。這樣就會導致應用程序的終端用戶對資料庫上的語句實施操縱。比方說，下面的這行代碼就會演示這種漏洞：
statement := "SELECT * FROM users WHERE name = '" + userName + "'; "
這種代碼的設計目的是將一個特定的用戶從其用戶表中取出，但是，如果用戶名被一個惡意的用戶用一種特定的方式偽造，這個語句所執行的操作可能就不僅僅是代碼的作者所期望的那樣了。例如，將用戶名變數(即username)設置為：
a' or 't'='t，此時原始語句發生了變化：
SELECT * FROM users WHERE name = 'a' OR 't'='t';
如果這種代碼被用於一個認證過程，那麼這個例子就能夠強迫選擇一個合法的用戶名，因為賦值't'='t永遠是正確的。
在一些SQL伺服器上，如在SQLServer中，任何一個SQL命令都可以通過這種方法被注入，包括執行多個語句。下面語句中的username的值將會導致刪除「users」表，又可以從「data」表中選擇所有的數據(實際上就是透露了每一個用戶的信息)。
a'; DROP TABLE users; SELECT * FROM data WHERE name LIKE '%
這就將最終的SQL語句變成下面這個樣子：
SELECT * FROM users WHERE name = 'a'; DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%';
其它的SQL執行不會將執行同樣查詢中的多個命令作為一項安全措施。這會防止攻擊者注入完全獨立的查詢，不過卻不會阻止攻擊者修改查詢。
2.Incorrect type handling
如果一個用戶提供的欄位並非一個強類型，或者沒有實施類型強制，就會發生這種形式的攻擊。當在一個SQL語句中使用一個數字欄位時，如果程序員沒有檢查用戶輸入的合法性(是否為數字型)就會發生這種攻擊。例如：
statement := "SELECT * FROM data WHERE id = " + a_variable + "; "
從這個語句可以看出，作者希望a_variable是一個與「id」欄位有關的數字。不過，如果終端用戶選擇一個字元串，就繞過了對轉義字元的需要。例 如，將a_variable設置為:1; DROP TABLE users，它會將「users」表從資料庫中刪除，SQL語句變成：SELECT * FROM DATA WHERE id = 1; DROP TABLE users;
3.資料庫伺服器中的漏洞
有時，資料庫伺服器軟體中也存在著漏洞，如MYSQL伺服器中mysql_real_escape_string()函數漏洞。這種漏洞允許一個攻擊者根據錯誤的統一字元編碼執行一次成功的SQL注入式攻擊。
4.盲目SQL注入式攻擊
當一個Web應用程序易於遭受攻擊而其結果對攻擊者卻不見時，就會發生所謂的盲目SQL注入式攻擊。有漏洞的網頁可能並不會顯示數據，而是根據注入到合法 語句中的邏輯語句的結果顯示不同的內容。這種攻擊相當耗時，因為必須為每一個獲得的位元組而精心構造一個新的語句。但是一旦漏洞的位置和目標信息的位置被確 立以後，一種稱為Absinthe的工具就可以使這種攻擊自動化。
5.條件響應
注意，有一種SQL注入迫使資料庫在一個普通的應用程序屏幕上計算一個邏輯語句的值：
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1
這會導致一個標準的面面，而語句
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2在頁面易於受到SQL注入式攻擊時，它有可能給出一個不同的結果。如此這般的一次注入將會證明盲目的SQL注入是可能的，它會使攻擊者根據另外一個 表中的某欄位內容設計可以評判真偽的語句。
6.條件性差錯
如果WHERE語句為真，這種類型的盲目SQL注入會迫使資料庫評判一個引起錯誤的語句，從而導致一個SQL錯誤。例如：
SELECT 1/0 FROM users WHERE username='Ralph'。顯然，如果用戶Ralph存在的話，被零除將導致錯誤。
7.時間延誤
時間延誤是一種盲目的SQL注入，根據所注入的邏輯，它可以導致SQL引擎執行一個長隊列或者是一個時間延誤語句。攻擊者可以衡量頁面載入的時間，從而決定所注入的語句是否為真。
以上僅是對SQL攻擊的粗略分類。但從技術上講，如今的SQL注入攻擊者們在如何找出有漏洞的網站方面更加聰明，也更加全面了。出現了一些新型的SQL攻 擊手段。黑客們可以使用各種工具來加速漏洞的利用過程。我們不妨看看the Asprox Trojan這種木馬，它主要通過一個發布郵件的僵屍網路來傳播，其整個工作過程可以這樣描述：首先，通過受到控制的主機發送的垃圾郵件將此木馬安裝到電 腦上，然後，受到此木馬感染的電腦會下載一段二進制代碼，在其啟動時，它會使用搜索引擎搜索用微軟的ASP技術建立表單的、有漏洞的網站。搜索的結果就成 為SQL注入攻擊的靶子清單。接著，這個木馬會向這些站點發動SQL注入式攻擊，使有些網站受到控制、破壞。訪問這些受到控制和破壞的網站的用戶將會受到 欺騙，從另外一個站點下載一段惡意的JavaScript代碼。最後，這段代碼將用戶指引到第三個站點，這里有更多的惡意軟體，如竊取口令的木馬。
以前，我們經常警告或建議Web應用程序的程序員們對其代碼進行測試並打補丁，雖然SQL注入漏洞被發現和利用的機率並不太高。但近來攻擊者們越來越多地 發現並惡意地利用這些漏洞。因此，在部署其軟體之前，開發人員應當更加主動地測試其代碼，並在新的漏洞出現後立即對代碼打補丁。
防禦和檢查SQL注入的手段
1.使用參數化的過濾性語句
要防禦SQL注入，用戶的輸入就絕對不能直接被嵌入到SQL語句中。恰恰相反，用戶的輸入必須進行過濾，或者使用參數化的語句。參數化的語句使用參數而不 是將用戶輸入嵌入到語句中。在多數情況中，SQL語句就得以修正。然後，用戶輸入就被限於一個參數。下面是一個使用Java和JDBC API例子：
PreparedStatement prep = conn.prepareStatement("SELECT * FROM USERS WHERE PASSWORD=?");
prep.setString(1, pwd);
總體上講，有兩種方法可以保證應用程序不易受到SQL注入的攻擊，一是使用代碼復查，二是強迫使用參數化語句的。強迫使用參數化的語句意味著嵌入用戶輸入的SQL語句在運行時將被拒絕。不過，目前支持這種特性的並不多。如H2 資料庫引擎就支持。
2.還要避免使用解釋程序，因為這正是黑客們藉以執行非法命令的手段。
3.防範SQL注入，還要避免出現一些詳細的錯誤消息，因為黑客們可以利用這些消息。要使用一種標準的輸入確認機制來驗證所有的輸入數據的長度、類型、語句、企業規則等。
4.使用專業的漏洞掃描工具。但防禦SQL注入攻擊也是不夠的。攻擊者們目前正在自動搜索攻擊目標並實施攻擊。其技術甚至可以輕易地被應用於其它的Web 架構中的漏洞。企業應當投資於一些專業的漏洞掃描工具，如大名鼎鼎的Acunetix的Web漏洞掃描程序等。一個完善的漏洞掃描程序不同於網路掃描程 序，它專門查找網站上的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發現的漏洞。
5.最後一點，企業要在Web應用程序開發過程的所有階段實施代碼的安全檢查。首先，要在部署Web應用之前實施安全測試，這種措施的意義比以前更大、更深遠。企業還應當在部署之後用漏洞掃描工具和站點監視工具對網站進行測試。
Web安全拉警報已經響起，安全形式異常嚴峻，企業絕對不應當草率從事。安全重於泰山!
2. 怎樣防止sqlexp病毒
SQLExp攻擊是什麼攻擊?
「蠕蟲王」蠕蟲文檔:
病毒名稱：Worm.SQLexp.376
危險級別：中
破壞性：中
傳播速度：高
病毒特徵：該蠕蟲攻擊安裝有Microsoft SQL 的NT系列伺服器，該病毒嘗試探測被攻擊機器的1434/udp埠，如果探測成功，則發送376個位元組的蠕蟲代碼。1434/udp埠為Microsoft SQL開放埠。該埠在未打補丁的SQL Server平台上存在緩沖區溢出漏洞，使蠕蟲的後續代碼能夠得以機會在被攻擊機器上運行進一步傳播。
病毒查殺防護
1,直接下載微軟指定的補丁程序 或者 安裝Microsoft SQL Server 2000 SP3。
2,在防火牆或者路由器上阻塞外部對內的和內部對外的UDP/1434埠的訪問。
3,如果由於DoS導致系統反映慢，可先斷開連接，然後在Windows任務管理器里強行終止進程SqlServr.exe，打上相應補丁並重新啟動服務.
3. sql注入如何防止
1、使用參數化篩選語句
為了防止SQL注入，用戶輸入不能直接嵌入到SQL語句中。相反，用戶輸入必須被過濾或參數化。參數語句使用參數，而不是將用戶輸入嵌入語句中。在大多數情況下，SQL語句是正確的。然後，用戶輸入僅限於一個參數。
一般來說，有兩種方法可以確保應用程序不易受到SQL注入攻擊。一種是使用代碼審查，另一種是強制使用參數化語句。強制使用參數化語句意味著在運行時將拒絕嵌入用戶輸入中的SQL語句。但是，目前對此功能的支持不多。
2、避免使用解釋程序，這是黑 客用來執行非法命令的手段。
3、防止SQL注入，但也避免一些詳細的錯誤消息，因為黑客可以使用這些消息。標準的輸入驗證機制用於驗證所有輸入數據的長度、類型、語句和企業規則。
4、使用漏洞掃描工具。
但是，防範SQL注入攻擊是不夠的。攻擊者現在自動搜索和攻擊目標。它的技術甚至可以很容易地應用於其他Web體系結構中的漏洞。企業應該投資於專業的漏洞掃描工具，如著名的Accunetix網路漏洞掃描程序。完美的漏洞掃描器不同於網路掃描器，它專門在網站上查找SQL注入漏洞。最新的漏洞掃描程序可以找到最新發現的漏洞。
5、最後，做好代碼審計和安全測試。
4. 如何防止sql注入攻擊
1，避免將用戶提供的輸入直接放入SQL語句中，最好使用准備好的語句和參數化查詢，這樣更加安全。
2，不要將敏感數據保存在純文本中，加密存儲在資料庫中的私有或機密數據，這樣可以提供另一級保護，以防止攻擊者成功地排出敏感數據。
3，將資料庫用戶的功能設置為最低要求，這將限制攻擊者在設法獲取訪問許可權時可以執行的操作。
4，避免直接向用戶顯示資料庫錯誤，攻擊者可以使用這些錯誤消息來獲取有關資料庫的信息。
5，對訪問資料庫的Web應用程序使用防火牆，這樣可以為面向Web的應用程序提供保護，可以幫助識別SQL注入嘗試;根據設置，還可以幫助防止SQL注入嘗試到達應用程序。
6，定期測試與資料庫交互的Web應用程序，這樣做可以幫助捕獲可能允許SQL注入的新錯誤或回歸。
7，將資料庫更新為最新的可用修補程序，這可以防止攻擊者利用舊版本中存在的已知弱點或錯誤。
5. 防止sql注入的最佳方式
1、利用第三方軟體加固，監控所有傳入的字元串
2、網上有很多防SQL注入代碼，引入到網頁的每一個需要傳值頁里
3、對於每一個傳值，進行數據類型、長度、規則等判斷，比如傳入ID=1，你要判斷ID里的是不是數字，且不會超過多少位，如果不滿足條件就做其它處理
通常就這三種方法
6. 如何徹底防止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則是利用郵寄信息數據欄位將數據傳送到伺服器。
7. 怎麼樣防止Sql注入
(1)對於動態構造SQL查詢的場合，可以使用下面的技術：
第一：替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改SQL命令的含義。再來看前面的例子，「SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'」顯然會得到與「SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'」不同的結果。
第二：刪除用戶輸入內容中的所有連字元，防止攻擊者構造出類如「SELECT * from Users WHERE login = 'mas' -- AND password =''」之類的查詢，因為這類查詢的後半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道用戶的密碼就可以順利獲得訪問許可權。
第三：對於用來執行查詢的資料庫帳戶，限制其許可權。用不同的用戶帳戶執行查詢、插入、更新、刪除操作。由於隔離了不同帳戶可執行的操作，因而也就防止了原本用於執行SELECT命令的地方卻被用於執行INSERT、UPDATE或DELETE命令。
⑵ 用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字元實施攻擊。此外，它還使得資料庫許可權可以限制到只允許特定的存儲過程執行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發生注入式攻擊了。
⑶ 限製表單或查詢字元串輸入的長度。如果用戶的登錄名字最多隻有10個字元，那麼不要認可表單中輸入的10個以上的字元，這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性，確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和伺服器端都執行——之所以要執行伺服器端驗證，是為了彌補客戶端驗證機制脆弱的安全性。
在客戶端，攻擊者完全有可能獲得網頁的源代碼，修改驗證合法性的腳本（或者直接刪除腳本），然後將非法內容通過修改後的表單提交給伺服器。因此，要保證驗證操作確實已經執行，唯一的辦法就是在伺服器端也執行驗證。你可以使用許多內建的驗證對象，例如RegularExpressionValidator，它們能夠自動生成驗證用的客戶端腳本，當然你也可以插入伺服器端的方法調用。如果找不到現成的驗證對象，你可以通過CustomValidator自己創建一個。
⑸ 將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據，然後再將它與資料庫中保存的數據比較，這相當於對用戶輸入的數據進行了「消毒」處理，用戶輸入的數據不再對資料庫有任何特殊的意義，從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個，非常適合於對輸入數據進行消毒處理。
⑹ 檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。
---------------------------------------------------------------------------------------------------------------------------
關鍵是明白原理，其實防範很簡單的，
1.過濾SQL需要的參數中的敏感字元（注意加入忽略大小寫）
2.禁用資料庫伺服器的xp_cmdshell存儲過程，刪除相應用到的dll
3.屏蔽伺服器異常信息
8. 如何從根本上防止 SQL 注入
也許可以這樣回答你，如果能保證應用不使用「用戶輸入的字元串」來拼接成為 「向SQL 伺服器發送的SQL執行字元串」 的話，就可以從根本上防止SQL注入。
一、SQL語言的機理：
1、當前主流的幾大資料庫伺服器的數據存、取、匯總控制，都使用一種文本語句「SQL」語句。
2、當客戶端需要數據，或需要發送數據，或需要匯總數據時，都可以向資料庫發送這種標準的描述性文本，比如向資料庫發送 「select * from bas1.dbo.tab1」就是告訴資料庫，我要取「資料庫bas1」中的「tab1」表中的 所有欄位（用「*」通配來代表）的所有記錄（因為沒有加限制條件）。
二、產生SQL注入的基礎：
1、如果客戶端設計者沒有關注SQL注入方面的問題，就有可能在將用戶輸入進行拼接成SQL語句，並發送到伺服器端時，產生惡意的SQL可執行語句。
2、舉例說明：某個網頁上有個修改用戶密碼口令的功能，正常情況下下，用戶輸入原口令，與將要改成的口令，然後對用戶進行修改。用戶正常情況下輸入簡單的字串作為口令，比如「abcdef」，最終，合成向伺服器發送的語句可能為：
update UserTab set password = 'abcdef' where id=222
3、然而，有個人很淘氣，它輸入的字串為
abcdef' --
那麼，合成的發送給伺服器的語句就成了：
update UserTab set password = 'abcdef' --『 where id=222
這條句語一但發向伺服器，其結果是，所有的人的密碼都將變成 abcdef。
4、當然了，上面只是舉了一個例子，以便於你理解什麼是SQL注入。
（絕大多數應用的口令字串都是要進行加密的，所以，這個例子起僅在：
初級用戶寫的，明文存密碼，沒有注意SQL注入。這些條件合適時才起作用。）
5、同理，你可以想出很多的相關的東西，比如在修改用戶姓名的地方……
三、防止SQL注入的一些辦法：
1、客戶端接收到用戶輸入後，進行一次核查，不讓用戶輸入能產生SQL歧義的字元。比如禁止使用任何英文符號作為密碼、姓名等等。
2、盡可能減少用戶的直接字元的輸入，通配查詢，等。