sql注入式攻擊實例_sql注入攻擊方法有哪些

1. 如何防範sql注入攻擊

2. SQL注入攻擊與防範

關於SQL注入攻擊與防範

隨著網路的普及，關系資料庫的廣泛應用，網路安全越來越重要。下面是我為大家搜索整理了關於SQL注入攻擊與防範，歡迎參考閱讀，希望對大家有所幫助。想了解更多相關信息請持續關注我們應屆畢業生培訓網!

一、 SQL注入攻擊

簡言之，SQL注入是應用程序開發人員未預期地把SQL代碼傳入到應用程序的過程。它由於應用程序的糟糕設計而成為可能，並且只有那些直接使用用戶提供的值構建SQL語句的應用程序才會受影響。

例如：用戶輸入客戶ID後，GridView顯示客戶的全部行記錄。在一個更加真實的案例中，用戶還要輸入密碼之類的驗證信息，或者根據前面的登錄頁面得到用戶ID，可能還會有一些用戶輸入關鍵信息的文本框，如訂單的日期范圍或產品名稱。問題在於命令是如何被執行的。在這個示例中，SQL語句通過字元串構造技術動態創建。文本框txtID的值被直接復制到字元串中。下面是代碼：

在這個示例中，攻擊者可以篡改SQL語句。通常，攻擊的第一個目標是得到錯誤信息。如果錯誤沒有被恰當處理，底層的信息就會暴露給攻擊者。這些信息可用於進一步攻擊。

例如，想像一下在文本一下在文本框中輸入下面的字元串會發生什麼?

ALFKI'OR '1'='1

再看看因此生成的完整SQL語句：

這條語句將返回所有的訂單記錄，即便那些訂單不是由ALFDI創建，因為對每一行而言而有信1=1總是true。這樣產生的後果是沒有顯示當前用戶特定信息，卻向攻擊者顯示了全部資料，如果屏幕上顯示的是敏感信息，如社會保險號，生日或信用卡資料，就會帶來嚴重的問題。事實上，這些簡單的SQL注入往往是困擾那些大型電子商務公司的麻煩。一般而言，攻擊點不在於文本框而在於查詢字元串(可被用於向資料庫傳送值，如列表頁向詳細信息頁面傳送唯一標識符)。

還可以進行更復雜的攻擊。例如，攻擊者可以使用兩個連接號(--)注釋掉SQL語句的剩餘部分。這樣的攻擊只限於SQL Server，不過對於其他類型的資料庫也有等效的辦法，如MySql使用(#)號，Oracle使用(;)號。另外攻擊者還可以執行含有任意SQL語句的批處理命令。對於SQL Server提供程序，攻擊者只需在新命令前加上分號(;)。攻擊者可以採用這樣的方式刪除其他表的內容，甚至調用SQL Server的系統存儲過程xp_cmdshell在命令執行任意的程序。

下面是攻擊者在文本框中輸入的，它的攻擊目標是刪除Customers表的全部行。

LUNCHUN』;DELETE*FROM Customers--

二、防範

如何預防SQL注入攻擊呢?需要記住幾點。首先，使用TextBox.MaxLength屬性防止用戶輸入過長的字元是一個好辦法。因為它們不夠長，也就減少了貼入大量腳本的可能性。其次，要使用ASP.NET驗證控制項鎖定錯誤的數據(如文本、空格、數值中的特殊字元)。另外，要限制錯誤信息給出的提示。捕獲到資料庫異常時，只顯示一些通用的信息(如「數據源錯誤」)而不是顯示Exception.Message屬性中的信息，它可能暴露了系統攻擊點。

更為重要的是，一定要小心去除特殊字元。比如，可以將單引號替換為兩個單引號，這樣它們就不會和SQL語句的分隔符混淆：

string ID=txtID.Text().Replace(「』」，」』』」);

當然，如果文本確實需要包含單引號，這樣做就引入了其他麻煩。另外，某些SQL注入攻擊還是可行的。替換單引號可以防止用戶提前結束一個字元串，然而，如果動態構建含有數值的SQL語句，SQL注入攻擊又有發揮的空間了。這個漏洞常被(這是很危險的)忽視。更好的解決辦法是使用參數化的命令或使用存儲過程執行轉義以防止SQL注入攻擊。

另一個好建議是限制用於訪問資料庫的賬號的許可權。這樣該賬號將沒有許可權訪問其他資料庫或執行擴展的存儲過程。不過這樣並不能解決SQL腳本注入的問題，因為用於連接資料庫的進程幾乎總是需要比任意單個用戶更大的許可權。通過限制許可權，可以預防刪除表的攻擊，但不能阻止攻擊者偷看別人的.信息

三、POST注入攻擊

精明的用戶可能會知道還有另外一個Web控制項攻擊的潛在途徑。雖然參數化的命令防止了SQL注入攻擊，但它們不能阻止攻擊者向回發到伺服器的數據添加惡意的值。如果不檢查這些值，就使得攻擊者可以提交本來不可能存在的控制項值。

例如，假設你有一個顯示當前用戶訂單的列表。狡詐的攻擊者可能保存該頁面的一個本地副本，修改HTML內容向列表添加更多的項目，然後選擇某個「假」的項目。如果攻擊成功，攻擊者就能夠看到其他用戶訂單，這顯然是一個問題。幸好，ASP.NET使用一個很少被提及的叫做「事件驗證」的特性來防止這種攻擊。事件驗證檢查回發到伺服器的數據並驗證其中值的合法性。例如，如果回發的數據表明用戶選擇了一個沒有意義的數據(因為它在控制項中並不存在)，ASP.NET就產生一個錯誤並停止處理。可以在Page指令中設置EnableEventValidation特性為false來禁用事件驗證。創建使用客戶端腳本動態改變內容的頁面時，需要執行這一步。不過，此時在使用這些值之前要注意檢查潛在的POST注入攻擊。

;

3. 輕松理解什麼是 SQL 注入

所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字元串，欺騙伺服器執行惡意的SQL命令。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。
舉個簡單的例子：
從理論上說，一個驗證用戶名和密碼的功能，會有如下的SQL語句：
String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";
然後在這個語句的username=」後面注入 or 1=1 用戶名等於」或1=1 這個條件，上面的SQL語句變成：
SELECT * FROM user_table WHERE username=
'』or 1 = 1 -- and password='』
那麼不用輸入用戶名和密碼，就可以登陸了。

4. sql注入攻擊方法有哪些

所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字元串，欺騙伺服器執行惡意的SQL命令。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。常見的SQL注入式攻擊過程類如：
⑴ 某個ASP.NET Web應用有一個登錄頁面，這個登錄頁面控制著用戶是否有權訪問應用，它要求用戶輸入一個名稱和密碼。
⑵ 登錄頁面中輸入的內容將直接用來構造動態的SQL命令，或者直接用作存儲過程的參數。

5. 什麼是sql注入攻擊，請結合實例簡述其原理

作為一名學生，大家都經歷過考試，既然有考試，那將需要時間地點科目：
____月____日____時____分，第____教學樓____層____教室，考________，時長____分。
一個考試應該是這樣的：
6月23日9時30分，第13教學樓6層601教室，考高等數學，時長120分。
你是一個學生，你按照學校安排執行：到了6月23號9.30，然後拿著證件和筆去13教學樓6層601考高等數學。
但是如果空格里填寫了不正常的值，甚至包含了指令：
6月23日9時30分，第13教學樓6層601教室，考英語，時長90分鍾。6月24日9時30分，第13教學樓6層601教室高等數學，時長120分。
作為一名人類，可以輕易發現科目處添了一串指令，但是如果是機器呢？

6. 什麼是SQL注入式攻擊如何防範

7. 什麼是SQL注入，如何防止SQL注入

所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊．x0dx0a防護x0dx0a歸納一下，主要有以下幾點：x0dx0a1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和x0dx0a雙"-"進行轉換等。x0dx0a2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。x0dx0a3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。x0dx0a4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。x0dx0a5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝x0dx0a6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測，軟體一般採用sql注入檢測工具jsky，網站平台就有億思網站安全平台檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入，XSS攻擊等。

8. 什麼是SQL注入攻擊

SQL 注入是注入式攻擊中的常見類型。 SQL 注入式攻擊是未將代碼與數據進行嚴格的隔離，導致在讀取用戶數據的時候，錯誤地把數據作為代碼的一部分執行，從而導致一些安全問題。

SQL 注入自誕生以來以其巨大的殺傷力聞名。典型的 SQL 注入的例子是當對 SQL 語旬進行字元串拼接操作時，直接使用未加轉義的用戶輸入內容作為變數，比如：

實例

在上面的例子中，如果用戶輸入的 ID 只是一個數字是沒有問題的，可以執行正常的查詢語句。但如果直接用「；」隔開，在 testCondition 里插入其他 SQL 語旬，會帶來意想不到的結果，比如輸入 drop 、 delete 等。

9. 試解釋 SQL 注入攻擊的原理，以及對資料庫可能產生的不利影響。

SQL注入就是攻擊者通過正常的WEB頁面,把自己SQL代碼傳入到應用程序中,從而通過執行非程序員預期的SQL代碼,達到竊取數據或破壞的目的。

當應用程序使用輸入內容來構造動態SQL語句以訪問資料庫時，會發生SQL注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生SQL注入。SQL注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態SQL命令，或者作為存儲過程的輸入參數，這些表單特別容易受到SQL注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是SQL注入就發生了。

一般SQL注入

在Web 應用程序的登錄驗證程序中,一般有用戶名(username) 和密碼(password) 兩個參數,程序會通過用戶所提交輸入的用戶名和密碼來執行授權操作。我們有很多人喜歡將SQL語句拼接起來。例如：

Select * from users where username =』 txtusername.Text 』 and password =』 txtpassword.Text 』

其原理是通過查找users 表中的用戶名(username) 和密碼(password) 的結果來進行授權訪問, 在txtusername.Text為mysql，txtpassword.Text為mary，那麼SQL查詢語句就為：

Select * from users where username =』 mysql 』 and password =』 mary 』

如果分別給txtusername.Text 和txtpassword.Text賦值』 or 『1』 = 『1』 --和abc。那麼,SQL 腳本解釋器中的上述語句就會變為:

Select * from users where username =』』or 『1』 = 『1』 -- and password =』abc』

該語句中進行了兩個條件判斷,只要一個條件成立,就會執行成功。而'1'='1'在邏輯判斷上是恆成立的,後面的"--" 表示注釋,即後面所有的語句為注釋語句這樣我們就成功登錄。即SQL注入成功.

如果我們給txtusername.Text賦值為:』;drop table users--即:

Select * from users where username =』』;drop table users-- and password =』abc』

整個用戶表就沒有了，當然這里要猜出數據表名稱。想想是多麼可怕的事情。

好我想大家在這里已經大致明白了一般SQL注入了，試想下您的登錄程序會不會出現我上述的情況。

防範SQL注入

那麼現在大家都在思考怎麼防範SQL注入了這里給出一點個人的建議

1.限制錯誤信息的輸出

這個方法不能阻止SQL注入，但是會加大SQL注入的難度，不會讓注入者輕易得到一些信息，讓他們任意破壞資料庫。SQL Server有一些系統變數，如果我們沒有限制錯誤信息的輸出，那麼注入著可以直接從出錯信息獲取，例如（假定這里用的string即字元類型並可以發生SQL注入）：http://www.xxx.com/showdetail.aspx?id=49 and user>0 這句語句很簡單，但卻包含了SQL Server特有注入方法的精髓，。首先看看它的含義：首先，前面的語句是正常的，重點在and user>0，我們知道，user是SQL Server的一個內置變數，它的值是當前連接的用戶名，類型為nvarchar。拿一個nvarchar的值跟int的數0比較，系統會先試圖將nvarchar的值轉成int型，當然，轉的過程中肯定會出錯，SQL Server的出錯提示是：將nvarchar值」abc」轉換數據類型為 int 的列時發生語法錯誤，呵呵，abc正是變數user的值，這樣，注入著就拿到了資料庫的用戶名。

眾所周知，SQL Server的用戶sa是個等同Adminstrators許可權的角色，拿到了sa許可權，幾乎肯定可以拿到主機的Administrator了。上面的方法可以很方便的測試出是否是用sa登錄，要注意的是：如果是sa登錄，提示是將」dbo」轉換成int的列發生錯誤，而不是」sa」。

當然注入者還可以輸入不同的信息來得到他們想要的信息，上面只是其中一個例子，所以我們要限制錯誤信息的輸出，從而保護我們的資料庫數據，這里我給出.NET限制錯誤信息的方法：

在Web.Config文件中設置

<customErrors mode="On" defaultRedirect="error.aspx">

</customErrors>

這樣當發生錯誤時候就不會講信息泄露給外人。

2.限制訪問資料庫帳號的許可權

對於資料庫的任何操作都是以某種特定身份和相應許可權來完成的,SQL語句執行前,在資料庫伺服器端都有一個用戶許可權驗證的過程,只有具備相應許可權的帳號才可能執行相應許可權內的SQL語句。因此,限制資料庫帳號許可權,實際上就阻斷了某些SQL語句執行的可能。不過,這種方法並不能根本解決SQL注入問題,因為連接資料庫的帳號幾乎總是比其他單個用戶帳號擁有更多的許可權。通過限制貼帳號許可權,可以防止刪除表的攻擊,但不能阻止攻擊者偷看別人的信息。

3.參數化使用命令

參數化命令是在SQL文本中使用佔位符的命令。佔位符表示需要動態替換的數據,它們通過Command對象Parameters集合來傳送。能導致攻擊的SQL代碼可以寫成:

Select * from employee where userID=@userID;

如果用戶輸入: 09105022』OR 『1』=』1,將得不到何記錄,因為沒有一個用戶ID與文本框中輸入的』 09105022』OR 『1』=』1』相等。參數化命令的語法隨提供程序的不同略有差異。對於SQL SERVER提供程序,參數化命令使用命名的佔位符(具有唯一的名字),而對於OLE DB提供程序,每個硬編碼的值被問號代替。使用OLE DB提供程序時,需要保證參數的順序和它們出現在SQL字元串中的位置一致。SQL SERVER提供程序沒有這樣的需求,因為它們用名字和佔位符匹配。

4.調用存儲過程

存儲過程是存儲在資料庫伺服器上的一系列SQL代碼,存儲過程與函數相似,有良好的邏輯封裝結構,可以接收和返回數據。使用存儲過程可以使代碼更易於維護,因為對存儲過程的更改不會導致應用程序的重新編譯,使用存儲過程還可以節省帶寬,提高應用程序性能。因為存儲過程是存儲在資料庫服務端的獨立的封裝體,調用存儲過程可以保證應用程序只執行存儲過程中的固定代碼,從而杜絕SQL語句注入的可能。結合上述所講的參數化命令,可以實現SQL代碼可以實現的任何功能,並進一步提高應用程序的安全等級。

5.限制輸入長度

如果在Web頁面上使用文本框收集用戶輸入的數據,使用文本框的MaxLength屬性來限制用戶輸入過長的字元也是一個很好的方法,因為用戶的輸入不夠長,也就減少了貼入大量腳本的可能性。程序員可以針對需要收集的數據類型作出一個相應的限制策略。

6.URL重寫技術

我們利用URL重寫技術過濾一些SQL注入字元，從而達到防禦SQL注入。因為許多SQL注入是從URL輸入發生的。

7.傳遞參數盡量不是字元

假設我們顯示一篇新聞的頁面，從URL傳遞參數中獲得newid我們可能會隨手寫下下面的代碼：

string newsid = Request.QueryString["newsid"];
string newssql = "select * from news where newsid=" + newsid;

如果傳遞過來的參數是數字字元就沒有問題。但是如果傳遞過來的newsid是「1 delete from table 」的話，那麼sql的值就變成了「select * from table where newsid=1 delete from news」。發生注入成功。但是這里改為

int newsid=int.Parse(Request.QueryString["newsid"].ToString());

string newssql = "select * from news where newsid=" + newsid.Tostring();

這里如果還是上面"1 delete from table "會發生錯誤，因為在轉換時候出現了錯誤

從上面的一個小例子，我們得出在傳遞參數時候盡量不要用字元，免得被注入。

最後是我想擴展下利用URL重寫技術來過濾一些SQL注入字元，首先這里有一篇關於URL重寫的文章，我的基本思想是可以利用它，屏蔽一些危險的SQL注入字元串，這些字元串我們可以人為的設定，畢竟我們還是根據特定的環境設定我們防禦措施。首先我們在MoleRewriter類中的Rewrite函數得到絕對的URL判斷其中是否有危險字元，如果有我們就將它鏈接到一個提示用戶您輸入危險的URL地址。如果不是我們繼續判斷是否觸發了其他的URL重寫的規則，觸發了就重寫。這樣就大致上能在URL上防禦危險字元。

代碼
<configSections>
<section name="RewriterConfig" type="URLRewriter.Config., URLRewriter" />
</configSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default_sql_error.aspx</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default2.aspx</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
<httpMoles>
<add type="URLRewriter.MoleRewriter, URLRewriter" name="MoleRewriter" />
</httpMoles>

上面是要在web.config配置文件加上的內容，這里我加上了兩個重寫規則，第一個規則是專門針對滿足這個正則表達式的頁面URL查看是否有危險字元，有危險字元就會發送到Default_sql_error.aspx頁面，來示警。這里我假定會發生危險字元注入的頁面時以"d"字元開頭並加上數字的頁面（這里我們可以根據實際情況自己定義，看哪些頁面URL容易發生我們就制定這些頁面的正則表達式），第二個是一般URL重寫。因為這里我採用的是HTTP模塊執行URL重寫，所以加上<httpMoles></httpMoles>這一塊。

第二步就是要在重寫Rewrite函數了

代碼
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// 獲得配置規則
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;

//獲得絕對的URL
Uri url = app.Request.Url;

// 判斷url 中是否含有SQL 注入攻擊敏感的字元或字元串,如果存在,sqlatFlag = 1 ;
string urlstr = url.AbsoluteUri;
int sqlatFlag = 0;

//這里我們根據實際情況隨便編寫，我這里這是隨便列舉了幾個
string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";

string[] split = words.Split(',');
foreach (string s in split)
{
if (urlstr.IndexOf(s.ToUpper()) > 0)
{
sqlatFlag = 1;
break;
}
}
if (sqlatFlag == 1)
{
// 創建regex
Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
// 找到匹配的規則,進行必要的替換
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
// 重寫URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
}
else
{
// 遍歷除rules[0 ]以外的其他URL 重寫規則
for (int i = 1; i < rules.Count; i++)
{
// 獲得要查找的模式,並且解析URL (轉換為相應的目錄)
string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// 創建regex
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的規則
if (re.IsMatch(requestedPath))
{
// 找到了匹配的規則, 進行必要的替換
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// 重寫URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;
// 退出For 循環
}
}
}
}

那麼下一步就是檢驗例子了

首先我們輸入http://localhost:4563/web/Default.aspx?id=1;--

這樣http://localhost:4563/web/Default.aspx?id=1;-- 沒有改變，就會顯示Default_sql_error.aspx里內容「您輸入了危險字元」。
再輸入http://localhost:4563/web/D11.aspx就會顯示 Default2.aspx內容，因為這里觸發了第二個重寫規則

10. 如何利用sql注入攻擊刪除文件

一、 SQL注入攻擊的簡單示例。
statement := "SELECT * FROM Users WHERE Value= " + a_variable + "
上面這條語句是很普通的一條SQL語句，他主要實現的功能就是讓用戶輸入一個員工編號然後查詢處這個員工的信息。但是若這條語句被不法攻擊者改裝過後，就可能成為破壞數據的黑手。如攻擊者在輸入變數的時候，輸入以下內容SA001』;drop table c_order--。那麼以上這條SQL語句在執行的時候就變為了SELECT * FROM Users WHERE Value= 『SA001』;drop table c_order--。
這條語句是什麼意思呢?『SA001』後面的分號表示一個查詢的結束和另一條語句的開始。c_order後面的雙連字元指示當前行餘下的部分只是一個注釋，應該忽略。如果修改後的代碼語法正確，則伺服器將執行該代碼。系統在處理這條語句時，將首先執行查詢語句，查到用戶編號為SA001 的用戶信息。然後，數據將刪除表C_ORDER(如果沒有其他主鍵等相關約束，則刪除操作就會成功)。只要注入的SQL代碼語法正確，便無法採用編程方式來檢測篡改。因此，必須驗證所有用戶輸入，並仔細檢查在您所用的伺服器中執行構造 SQL命令的代碼。
二、 SQL注入攻擊原理。
可見SQL注入攻擊的危害性很大。在講解其防止辦法之前，資料庫管理員有必要先了解一下其攻擊的原理。這有利於管理員採取有針對性的防治措施。
SQL注入是目前比較常見的針對資料庫的一種攻擊方式。在這種攻擊方式中，攻擊者會將一些惡意代碼插入到字元串中。然後會通過各種手段將該字元串傳遞到SQLServer資料庫的實例中進行分析和執行。只要這個惡意代碼符合SQL語句的規則，則在代碼編譯與執行的時候，就不會被系統所發現。
SQL注入式攻擊的主要形式有兩種。一是直接將代碼插入到與SQL命令串聯在一起並使得其以執行的用戶輸入變數。上面筆者舉的例子就是採用了這種方法。由於其直接與SQL語句捆綁，故也被稱為直接注入式攻擊法。二是一種間接的攻擊方法，它將惡意代碼注入要在表中存儲或者作為原書據存儲的字元串。在存儲的字元串中會連接到一個動態的SQL命令中，以執行一些惡意的SQL代碼。
注入過程的工作方式是提前終止文本字元串，然後追加一個新的命令。如以直接注入式攻擊為例。就是在用戶輸入變數的時候，先用一個分號結束當前的語句。然後再插入一個惡意SQL語句即可。由於插入的命令可能在執行前追加其他字元串，因此攻擊者常常用注釋標記「—」來終止注入的字元串。執行時，系統會認為此後語句位注釋，故後續的文本將被忽略，不背編譯與執行。
三、 SQL注入式攻擊的防治。
既然SQL注入式攻擊的危害這么大，那麼該如何來防治呢?下面這些建議或許對資料庫管理員防治SQL注入式攻擊有一定的幫助。
1、普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句，那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象，故要操作這個語句用戶必須有相關的許可權。在許可權設計中，對於終端用戶，即應用軟體的使用者，沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼，由於其用戶許可權的限制，這些代碼也將無法被執行。故應用程序在設計的時候，最好把系統管理員的用戶與普通用戶區分開來。如此可以最大限度的減少注入式攻擊對資料庫帶來的危害。
2、強迫使用參數化語句。
如果在編寫SQL語句的時候，用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話，那麼就可以有效的防治SQL注入式攻擊。也就是說，用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反，用戶的輸入的內容必須進行過濾，或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施，可以杜絕大部分的SQL注入式攻擊。不過可惜的是，現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。
3、加強對用戶輸入的驗證。
總體來說，防治SQL注入式攻擊可以採用兩種方法，一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中，有比較多的用戶輸入內容驗證工具，可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容，只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入，防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型，強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出，對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾，如拒絕一些特殊的符號。如以上那個惡意代碼中，只要存儲過程把那個分號過濾掉，那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前，可以通過資料庫的存儲過程，來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下，應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符，它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容，故可以直接把他拒絕掉，通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉，那麼即使在SQL語句中嵌入了惡意代碼，他們也將毫無作為。
故始終通過測試類型、長度、格式和范圍來驗證用戶輸入，過濾用戶輸入的內容。這是防止SQL注入式攻擊的常見並且行之有效的措施。
4、多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響，在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中，工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話，則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼，則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查，范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束，就會發生異常，並報告給管理員。如上面這個案例中，如果員工編號定義的數據類型為字元串型，長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據，但是其長度達到了20個字元。則此時就會引發異常，因為用戶輸入的內容長度超過了資料庫欄位長度的限制。
5、多層環境如何防治SQL注入式攻擊?
在多層應用環境中，用戶輸入的所有數據都應該在驗證之後才能被允許進入到可信區域。未通過驗證過程的數據應被資料庫拒絕，並向上一層返回一個錯誤信息。實現多層驗證。對無目的的惡意用戶採取的預防措施，對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的後續點上驗證輸入。如在客戶端應用程序中驗證數據可以防止簡單的腳本注入。但是，如果下一層認為其輸入已通過驗證，則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統。故對於多層應用環境，在防止注入式攻擊的時候，需要各層一起努力，在客戶端與資料庫端都要採用相應的措施來防治SQL語句的注入式攻擊。
6、必要的情況下使用專業的漏洞掃描工具來尋找可能被攻擊的點。
使用專業的漏洞掃描工具，可以幫助管理員來尋找可能被SQL注入式攻擊的點。不過漏洞掃描工具只能發現攻擊點，而不能夠主動起到防禦SQL注入攻擊的作用。當然這個工具也經常被攻擊者拿來使用。如攻擊者可以利用這個工具自動搜索攻擊目標並實施攻擊。為此在必要的情況下，企業應當投資於一些專業的漏洞掃描工具。一個完善的漏洞掃描程序不同於網路掃描程序，它專門查找資料庫中的SQL注入式漏洞。最新的漏洞掃描程序可以查找最新發現的漏洞。所以憑借專業的工具，可以幫助管理員發現SQL注入式漏洞，並提醒管理員採取積極的措施來預防SQL注入式攻擊。如果攻擊者能夠發現的SQL注入式漏洞資料庫管理員都發現了並採取了積極的措施堵住漏洞，那麼攻擊者也就無從下手了。

如何防範黑客入侵網站的幾種常見安全方法
• 本文的目的是告訴企業在建網站時如何打造一個防範黑客攻擊的安全網站
• 互聯網隨著時間的發展，它的優勢越來越來明顯，世界越來越多的企業通過這二十四小時不間斷的傳波平台，打造自己公司的網站，開展電子商務活動；由於互聯網的特殊性和復雜性，一旦你企業的網站接入互聯網後，你的企業網站便為一個公眾場所，任何人都可以上你的企業網站瀏覽信息，任何人(比如：黑客)都有可能對你的企業網站進行技術上測試，查找你的企業網站在程序設計上的漏洞，不論他目的是惡意還其它原因，你都無法制止他的行為，因為黑客在遠程電腦上實施操作。
• 建設一個有安全系數保證的網站，關系著一個企業的商業信譽問題，面臨日夜猖狂、日益肆虐的網路攻擊事件不斷發生，給自己的網站做一些最基本的安全防範措施是非常必要的。
• 非法字元過濾和轉換
• 黑客攻擊網站之前，先採用探路方式，通過網站的留言、論壇、搜索等系統，注入可執行的web腳本代碼和SQL語法，來達到入侵網站的目的；對網站所有互動式介面的文本輸入框（如：網站留言系統、BBS系統、blog系統、搜索系統、登陸系統等）的地方採取在客戶端非法字元過濾和轉換技術，通過非法字元過濾和轉換將可執行的惡意代碼變為可讀HTML代碼，使它基本失去了暴破網站的威力，又起到了保護網站程序源代碼不受破壞的作用。
• 建一個指定自定義出錯(Error)的信息頁面
• 好處在於防止網站設計源代碼的溢出，黑客在入侵網站的後台管理系統，往往在網頁地址欄輸入可執行的SQL語法和根據程序員為網頁命名的習慣輸入網址的文件名，一旦黑客採用這種方式，就會將黑客帶向指定自定義出錯(Error)的信息頁面。

• 拒絕Cookie驗證方式
• Cookie的好處在於管理員和注冊用戶登陸網站時Cookie會保存登陸信息，下次再登陸時Cookie會自動將這些信息保留在登陸的頁面輸入文本框中，其作用是為了方便登陸者，但也給黑客採集Cookie的信息提供了良機，所以應該拒絕採用客戶端Cookie驗證登陸方式，而改用通過伺服器驗證方式登陸並對賬號和密碼採用單向加密方式保存。
• 不要用自助建網站系統建你的企業網站
• 一些網站設計公司為了增加銷量降低成本（其實大部分客戶喜歡購買廉價的自助建網站系統），開發不同用途的自助建網站系統（如：網站內容管理、BBS、新聞發布、留言、博客等），同時為了爭奪市場、擴大產品知名度，往往兩種方式銷售產品：個人版可以免費下載；商業版則需要購買；其實兩個版本的網站在是同一種程序技術基礎開發出來的，商業版是授權驗證後可作商業用途，有技術支持和維護保證；黑客通過下載個人版，來潛心深研這些自助建網站系統的開放源代碼，從中找出程序漏洞，一旦發現了可攻擊的程序漏洞，通過搜索引擎平台檢索出同一型號版本自建網站系統，然後就發起攻擊；解決方式找有自主能力開發網站公司設計你的企業網站，通過將網站的設計源代碼封裝成「.dll」組件，這樣即保證網站設計上的安全性又保護了源代碼，又提高了網站的安全系數同時也降低了網站被入侵的危害程度，因為黑客攻陷網站往往是從研究網站源代碼開始並中找出程序漏洞。
• 解決Googel「暴庫」問題
• 一些程序員在開發網站喜歡用虛擬路徑方法調用資料庫，這就必須將資料庫保存在開通WWW服務的文件夾下，自然逃不過狡猾黑客的眼睛，一旦黑客破解了資料庫的真實保存位置，便可以從瀏覽器的地址欄打開和下載該資料庫，對網站的後果是非常危險的；要想確保你網站的資料庫不被黑客下載，只要採取將資料庫保存在非WWW服務的文件夾下，通過物理(真實)路徑方法調用資料庫，就可完全防止黑客下載你企業網站的資料庫。

• 建立robots文件
• 為了防止網站的重要文件夾（如：後台管理）和文件（如：純程序文件）不被搜索引擎所收錄，首先在網站根目錄下建一個「robots.txt」純文本文件，來防止網站的重要文件或其它敏感信息被搜索引擎所收錄；最大多搜索引擎平台都遵守robots協議；搜索引擎機器人訪問網站時，首先找到網站根目錄下robots文件，然後會讀取robots文件的內容，來確定它對網站收錄的范圍；robots文件可以說是對搜索引擎機器人收錄許可權的限制管理，從而避免將網站的重要文件或其它敏感信息暴露在網路上，在網站安全上起一個防禦鎖作用，robots文件可由網站設計者在遵守robots協議下，根據網站的實際情況自由編寫。
• 完全將杜絕黑客的攻擊和入侵是不可能的，完全在網站的每個介面過濾和轉換非法字元串是辦不到，比如，在文件上傳時，狡猾黑客會採取躲過過濾和轉換非法字元串的辦法，將可執行惡意腳本代碼保存「.gif」格式或「.jpg」格式來實施文件上傳漏洞攻擊，解決的方法是對所有上傳的文件先導入到「.txt」純文本文件讀一遍，判斷是否是可執行惡意腳本代碼，如果是就刪除，但是網站管理員要有web程序基礎；黑客入侵網站的方式變化多端，幾千種免費暴破網站的軟體，使你企業網站防不勝防，但是以上介紹幾種防禦措施對菜鳥黑客是可行的，對於一些資深黑客，他也要費一些精力和時間來暴破你企業網站，他會考慮值不值得？畢竟你的網站只是一個企業網站，不是銀行和證券交涉現金交易的網站（它們的程序設計安全系數更高），在大多數下情況，「大俠」黑客不會光顧你企業網站。

1、SQL注入漏洞的入侵
這種是ASP+ACCESS的網站入侵方式，通過注入點列出資料庫裡面管理員的帳號和密碼信息，然後猜解出網站的後台地址，然後用帳號和密碼登錄進去找到文件上傳的地方，把ASP木馬上傳上去，獲得一個網站的WEBSHELL。這個是黑鏈使用的前一部分，應該比較常用吧。現在網上賣webshell的太多了。
2、ASP上傳漏洞的利用
這種技術方式是利用一些網站的ASP上傳功能來上傳ASP木馬的一種入侵方式，不少網站都限制了上傳文件的類型，一般來說ASP為後綴的文件都不允許上傳，但是這種限制是可以被黑客突破的，黑客可以採取COOKIE欺騙的方式來上傳ASP木馬，獲得網站的WEBSHELL許可權。
3、後台資料庫備份方式獲得WEBSHELL
這個主要是利用網站後台對ACCESS資料庫進行資料庫備份和恢復的功能，備份資料庫路徑等變數沒有過濾導致可以把任何文件的後綴改成ASP，那麼利用網站上傳的功能上傳一個文件名改成JPG或者GIF後綴的ASP木馬，然後用這個恢復庫備份和恢復的功能把這個木馬恢復成ASP文件，從而達到能夠獲取網站WEBSHELL控制許可權的目的。
4、網站旁註入侵
這種技術是通過IP綁定域名查詢的功能查出伺服器上有多少網站，然後通過一些薄弱的網站實施入侵，拿到許可權之後轉而控制伺服器的其它網站。
下面這幾種我就聽不懂了，不過有點高技術的站長會看懂的。
5、sa注入點利用的入侵技術
這種是ASP+MSSQL網站的入侵方式，找到有SA許可權的SQL注入點，然後用SQL資料庫的XP_CMDSHELL的存儲擴展來運行系統命令建立系統級別的帳號，然後通過3389登錄進去，或者在一台肉雞上用NC開設一個監聽埠，然後用VBS一句話木馬下載一個NC到伺服器裡面，接著運行NC的反向連接命令，讓伺服器反向連接到遠程肉雞上，這樣遠程肉雞就有了一個遠程的系統管理員級別的控制許可權。
6、sa弱密碼的入侵技術
這種方式是用掃描器探測SQL的帳號和密碼信息的方式拿到SA的密碼，然後用SQLEXEC之類的工具通過1433埠連接到遠程伺服器上，然後開設系統帳號，通過3389登錄。然後這種入侵方式還可以配合WEBSHELL來使用，一般的ASP+MSSQL 網站通常會把MSSQL的連接密碼寫到一個配置文件當中，這個可以用WEBSHELL來讀取配置文件裡面的SA密碼，然後可以上傳一個SQL木馬的方式來獲取系統的控制許可權。
7、提交一句話木馬的入侵方式
這種技術方式是對一些資料庫地址被改成asp文件的網站來實施入侵的。黑客通過網站的留言版，論壇系統等功能提交一句話木馬到資料庫裡面，然後在木馬客戶端裡面輸入這個網站的資料庫地址並提交，就可以把一個ASP木馬寫入到網站裡面，獲取網站的WEBSHELL許可權。
8、論壇漏洞利用入侵方式
這種技術是利用一些論壇存在的安全漏洞來上傳ASP木馬獲得WEBSHELL許可權，最典型的就是，動網6.0版本，7.0版本都存在安全漏洞，拿7.0版本來說，注冊一個正常的用戶，然後用抓包工具抓取用戶提交一個ASP文件的COOKIE，然後用明小子之類的軟體採取COOKIE欺騙的上傳方式就可以上傳一個ASP木馬，獲得網站的WEBSHELL。

sql注入式攻擊實例

與sql注入式攻擊實例相關的內容