所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令，比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊．
sql注入
什么時候最易受到sql注入攻擊
當應用程序使用輸入內容來構造動態sql語句以訪問數據庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的 字符串來傳遞，也會發生sql注入。sql注入可能導致攻擊者使用應用程序登陸在數據庫中執行命令。如果應用程序使用特權過高的帳戶連接到數據庫，這種問 題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造動態sql命令，或者作為存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多 網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變量處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段數據庫查詢的代碼， 根據程序返回的結果，獲得一些敏感的信息或者控制整個服務器，於是sql注入就發生了。
如何防止SQL注入
歸納一下，主要有以下幾點：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和
雙"-"進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫連接，為每個應用使用單獨的權限有限的數據庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6.sql注入的檢測方法一般采取輔助軟件或網站平台來檢測，軟件一般采用sql注入檢測工具jsky,網站平台就有億思網站安全平台檢測工具。
例子一、SQL注入實例詳解(以上測試均假設服務器未開啟magic_quote_gpc)
1) 前期准備工作
先來演示通過SQL注入漏洞，登入后台管理員界面
首先，創建一張試驗用的數據表：
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(64) NOT NULL,
`password` varchar(64) NOT NULL,
`email` varchar(64) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `username` (`username`)
) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=latin1;
添加一條記錄用於測試：
INSERT INTO users (username,password,email)
VALUES('MarcoFly',md5('test'),'marcofly@test.com');
接下來，貼上登錄界面的源代碼：
<html>
<head>
<title>Sql注入演示</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
</head>
<body >
<form action="validate.php" method="post">
<fieldset >
<legend>Sql注入演示</legend>
<table>
<tr>
<td>用戶名：</td>
<td><input type="text" name="username"></td>
</tr>
<tr>
<td>密 碼：</td>
<td><input type="text" name="password"></td>
</tr>
<tr>
<td><input type="submit" value="提交"></td>
<td><input type="reset" value="重置"></td>
</tr>
</table>
</fieldset>
</form>
</body>
</html>
附上效果圖：
當用戶點擊提交按鈕的時候，將會把表單數據提交給validate.php頁面，validate.php頁面用來判斷用戶輸入的用戶名和密碼有沒有都符合要求(這一步至關重要，也往往是SQL漏洞所在)
代碼如下：
<html>
<head>
<title>登錄驗證</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
</head>
<body>
<?php
$conn=@mysql_connect("localhost",'root','') or die("數據庫連接失敗！");;
mysql_select_db("injection",$conn) or die("您要選擇的數據庫不存在");
$name=$_POST['username'];
$pwd=$_POST['password'];
$sql="select * from users where username='$name' and password='$pwd'";
$query=mysql_query($sql);
$arr=mysql_fetch_array($query);
if(is_array($arr)){
header("Location:manager.php");
}else{
echo "您的用戶名或密碼輸入有誤，<a href=\"Login.php\">請重新登錄！</a>";
}
?>
</body>
</html>
注意到了沒有，我們直接將用戶提交過來的數據(用戶名和密碼)直接拿去執行，並沒有實現進行特殊字符過濾，待會你們將明白，這是致命的。
代碼分析：如果，用戶名和密碼都匹配成功的話，將跳轉到管理員操作界面(manager.php)，不成功，則給出友好提示信息。
登錄成功的界面：
登錄失敗的提示：
到這里，前期工作已經做好了，接下來將展開我們的重頭戲：SQL注入
2) 構造SQL語句
填好正確的用戶名(marcofly)和密碼(test)后，點擊提交，將會返回給我們“歡迎管理員”的界面。
select * from users where username='marcofly' and password=md5('test')
很明顯，用戶名和密碼都和我們之前給出的一樣，肯定能夠成功登陸。但是，如果我們輸入一個錯誤的用戶名或密碼呢?很明顯，肯定登入不了吧。恩，正常情況下是如此，但是對於有SQL注入漏洞的網站來說，只要構造個特殊的“字符串”，照樣能夠成功登錄。
比如：在用戶名輸入框中輸入:’ or 1=1#,密碼隨便輸入，這時候的合成后的SQL查詢語句為：
select * from users where username='' or 1=1#' and password=md5('')
語義分析：“#”在mysql中是注釋符，這樣井號后面的內容將被mysql視為注釋內容，這樣就不會去執行了，換句話說，以下的兩句sql語句等價：
select * from users where username='' or 1=1#' and password=md5('')
等價於
select * from users where username='' or 1=1
SQL注入采用的' OR 1=1 # 是什么意思呢？
最后一個#號有什么意義呢？
SELECT * FROM test WHERE name='' OR 1=1 #' AND age='20'
這后面寫的 #' 是什么意思呢？ 求指教
# 可以注釋掉后面的一行SQL代碼
相當於去掉了一個where條件
MySQL 注釋, 過濾掉后面的SQL語句，使其不起作用
因為1=1永遠是都是成立的，即where子句總是為真，將該sql進一步簡化之后，等價於如下select語句：
select * from users 沒錯，該sql語句的作用是檢索users表中的所有字段
小技巧：一個經構造后的sql語句竟有如此可怕的破壞力，相信你看到這后，開始對sql注入有了一個理性的認識了吧~
有漏洞的腳本才有機會給你攻擊，比如一個帶參數的刪除腳本a.asp?action=del&id=2你可以改為a.asp?action=del&id=2 or 1這樣就有可能刪除全部數據------sql注入就是通過類似的手段來破壞數據
嘗試:在我的畢業設計首頁搜索中輸入【123' or 1=(select count(1) from tb_users)--】會查詢不出人和數據 並且不會報錯 通過這樣可以判斷是否存在表tb_users
原文地址：http://www.cnblogs.com/rush/archive/2011/12/31/2309203.html
1.1.1 摘要
日前，國內最大的程序員社區CSDN網站的用戶數據庫被黑客公開發布，600萬用戶的登錄名及密碼被公開泄露，隨后又有多家網站的用戶密碼被流傳於網絡，連日來引發眾多網民對自己賬號、密碼等互聯網信息被盜取的普遍擔憂。
網絡安全成為了現在互聯網的焦點，這也恰恰觸動了每一位用戶的神經，由於設計的漏洞導致了不可收拾的惡果，驗證了一句話“出來混的，遲早是要還的”，所以我想通過專題博文介紹一些常用的攻擊技術和防范策略。
SQL Injection也許很多人都知道或者使用過，如果沒有了解或完全沒有聽過也沒有關系，因為接下來我們將介紹SQL Injection。
1.1.2 正文
SQL Injection：就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。
具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到后台數據庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。
首先讓我們了解什么時候可能發生SQL Injection。
假設我們在瀏覽器中輸入URL www.sample.com，由於它只是對頁面的簡單請求無需對數據庫動進行動態請求，所以它不存在SQL Injection，當我們輸入www.sample.com?testid=23時，我們在URL中傳遞變量testid，並且提供值為23，由於它是對數據庫進行動態查詢的請求（其中?testid＝23表示數據庫查詢變量），所以我們可以該URL中嵌入惡意SQL語句。
現在我們知道SQL Injection適用場合，接下來我們將通過具體的例子來說明SQL Injection的應用，這里我們以pubs數據庫作為例子。
我們通過Web頁面查詢job表中的招聘信息，job表的設計如下：
圖1 jobs表
接着讓我們實現Web程序，它根據工作Id（job_id）來查詢相應的招聘信息，示意代碼如下：
/// <summary>
/// Handles the Load event of the Page control. /// </summary> /// <param name="sender">The source of the event.</param> /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // Gets departmentId from http request. string queryString = Request.QueryString["departmentID"]; if (!string.IsNullOrEmpty(queryString)) { // Gets data from database. gdvData.DataSource = GetData(queryString.Trim()); // Binds data to gridview. gdvData.DataBind(); } } }
現在我們已經完成了Web程序，接下來讓我們查詢相應招聘信息吧。
圖2 job表查詢結果
如圖所示，我們要查詢數據庫中工作Id值為1的工作信息，而且在頁面顯示了該工作的Id，Description，Min Lvl和Max Lvl等信息。
現在要求我們實現根據工作Id查詢相應工作信息的功能，想必大家很快可以給出解決方案，SQL示意代碼如下：
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE (job_id = 1)
假設現在要求我們獲取Department表中的所有數據，而且必須保留WHERE語句，那我們只要確保WHERE恆真就OK了，SQL示意代碼如下：
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE (job_id = 1) OR 1 = 1
上面我們使得WHERE恆真，所以該查詢中WHERE已經不起作用了，其查詢結果等同於以下SQL語句。
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs
SQL查詢代碼實現如下：
string sql1 = string.Format( "SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='{0}'", jobId);
現在我們要通過頁面請求的方式，讓數據庫執行我們的SQL語句，我們要在URL中嵌入惡意表達式1=1（或2=2等等），如下URL所示：
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1
等效SQL語句如下：
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = '1' OR '1' = 1'
圖3 job表查詢結果
現在我們把job表中的所有數據都查詢出來了，僅僅通過一個簡單的恆真表達式就可以進行了一次簡單的攻擊。
雖然我們把job表的數據都查詢出來了，但數據並沒有太大的價值，由於我們把該表臨時命名為job表，所以接着我們要找出該表真正表名。
首先我們假設表名就是job，然后輸入以下URL：
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or 1=(select count(*) from job)--
等效SQL語句如下：
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='1'or 1=(select count(*) from job) --'
圖4 job表查詢結果
當我們輸入了以上URL后，結果服務器返回我們錯誤信息，這證明了我們的假設是錯誤的，那我們該感覺到挫敗嗎？不，其實這里返回了很多信息，首先它 證明了該表名不是job，而且它還告訴我們后台數據庫是SQL Server，不是MySQL或Oracle，這也設計一個漏洞把錯誤信息直接返回給了用戶。
接下假定表名是jobs，然后輸入以下URL：
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or1=(select count(*) from jobs) --
等效SQL語句如下：
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='1'or 1=(select count(*) from jobs) --'
圖5 job表查詢結果
現在證明了該表名是jobs，這可以邁向成功的一大步，由於我們知道了表名就可以對該表進行增刪改操作了，而且我們還可以猜測出更多的表對它們作出修改，一旦修改成功那么這將是一場災難。
現在大家已經對SQL Injection的攻擊有了初步的了解了，接下讓我們學習如何防止SQL Injection。
總的來說有以下幾點：
1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，可以通過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。
2.永遠不要使用動態拼裝SQL，可以使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫連接，為每個應用使用單獨的權限有限的數據庫連接。
4.+ @"\s?sysobjects\s?|\s?xp_.*?|\s?syslogins\s?|\s?sysremote\s?|\s?sysusers\s?|\s?sysxlogins\s?|\s?sysdatabases\s?|\s?aspnet_.*?|\s?exec\s?", RegexOptions.Compiled | RegexOptions.IgnoreCase);
上面我們定義了一個正則表達式對象RegSystemThreats，並且給它傳遞了校驗用戶輸入的正則表達式。
由於我們已經完成了對用戶輸入校驗的正則表達式了，接下來就是通過該正則表達式來校驗用戶輸入是否合法了，由於.NET已經幫我們實現了判斷字符串是否匹配正則表達式的方法——IsMatch()，所以我們這里只需給傳遞要匹配的字符串就OK了。
示意代碼如下：
/// <summary> /// A helper method to attempt to discover [known] SqlInjection attacks. /// </summary> /// <param name="whereClause">string of the whereClause to check</param> /// <returns>true if found, false if not found </returns> public static bool DetectSqlInjection(string whereClause) { return RegSystemThreats.IsMatch(whereClause); } /// <summary> /// A helper method to attempt to discover [known] SqlInjection attacks. /// </summary> /// <param name="whereClause">string of the whereClause to check</param> /// <param name="orderBy">string of the orderBy clause to check</param> /// <returns>true if found, false if not found </returns> public static bool DetectSqlInjection(string whereClause, string orderBy) { return RegSystemThreats.IsMatch(whereClause) || RegSystemThreats.IsMatch(orderBy); }現在我們完成了校驗用的正則表達式，接下來讓我們需要在頁面中添加校驗功能。
/// <summary> /// Handles the Load event of the Page control. /// </summary> /// <param name="sender">The source of the event.</param> /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // Gets departmentId from http request. string queryString = Request.QueryString["jobId"]; if (!string.IsNullOrEmpty(queryString)) { if (!DetectSqlInjection(queryString) && !DetectSqlInjection(queryString, queryString)) { // Gets data from database. gdvData.DataSource = GetData(queryString.Trim()); // Binds data to gridview. gdvData.DataBind(); } else { throw new Exception("Please enter correct field"); } } } }當我們再次執行以下URL時，被嵌入的惡意語句被校驗出來了，從而在一定程度上防止了SQL Injection。
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1
圖6 添加校驗查詢結果
但使用正則表達式只能防范一些常見或已知SQL Injection方式，而且每當發現有新的攻擊方式時，都要對正則表達式進行修改，這可是吃力不討好的工作。
通過參數化存儲過程進行數據查詢存取
首先我們定義一個存儲過程根據jobId來查找jobs表中的數據。
-- ============================================= -- Author: JKhuang -- Create date: 12/31/2011 -- Description: Get data from jobs table by specified jobId. -- ============================================= ALTER PROCEDURE [dbo].[GetJobs] -- ensure that the id type is int @jobId INT AS BEGIN -- SET NOCOUNT ON; SELECT job_id, job_desc, min_lvl, max_lvl FROM dbo.jobs WHERE job_id = @jobId GRANT EXECUTE ON GetJobs TO pubs END接着修改我們的Web程序使用參數化的存儲過程進行數據查詢。
using (var com = new SqlCommand("GetJobs", con)) { // Uses store procedure. com.CommandType = CommandType.StoredProcedure; // Pass jobId to store procedure. com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId; com.Connection.Open(); gdvData.DataSource = com.ExecuteScalar(); gdvData.DataBind(); }現在我們通過參數化存儲過程進行數據庫查詢，這里我們把之前添加的正則表達式校驗注釋掉。
圖7 存儲過程查詢結果
大家看到當我們試圖在URL中嵌入惡意的SQL語句時，參數化存儲過程已經幫我們校驗出傳遞給數據庫的變量不是整形，而且使用存儲過程的好處是我們還可以很方便地控制用戶權限，我們可以給用戶分配只讀或可讀寫權限。
但我們想想真的有必要每個數據庫操作都定義成存儲過程嗎？而且那么多的存儲過程也不利於日常的維護。
參數化SQL語句
還是回到之前動態拼接SQL基礎上，我們知道一旦有惡意SQL代碼傳遞過來，而且被拼接到SQL語句中就會被數據庫執行，那么我們是否可以在拼接之前進行判斷呢？——命名SQL參數。
string sql1 = string.Format("SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = @jobId"); using (var con = new SqlConnection(ConfigurationManager.ConnectionStrings["SQLCONN1"].ToString())) using (var com = new SqlCommand(sql1, con)) { // Pass jobId to sql statement. com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId; com.Connection.Open(); gdvData.DataSource = com.ExecuteReader(); gdvData.DataBind(); }
圖8 參數化SQL查詢結果
這樣我們就可以避免每個數據庫操作（尤其一些簡單數據庫操作）都編寫存儲過程了，而且當用戶具有數據庫中jobs表的讀權限才可以執行該SQL語句。
添加新架構
數據庫架構是一個獨立於數據庫用戶的非重復命名空間，您可以將架構視為對象的容器（類似於.NET中的命名空間）。
首先我們右擊架構文件夾，然后新建架構。
圖9 添加HumanResource架構
上面我們完成了在pubs數據庫中添加HumanResource架構，接着把jobs表放到HumanResource架構中。
圖 10 修改jobs表所屬的架構
當我們再次執行以下SQL語句時，SQL Server提示jobs無效，這是究竟什么原因呢？之前還運行的好好的。
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs
圖 11 查詢輸出
當我們輸入完整的表名“架構名.對象名”（HumanResource.jobs）時，SQL語句執行成功。
SELECT job_id, job_desc, min_lvl, max_lvl FROM HumanResource.jobs
為什么之前我們執行SQL語句時不用輸入完整表名dbo.jobs也可以執行呢？
這是因為默認的架構（default schema）是dbo，當只輸入表名時，Sql Server會自動加上當前登錄用戶的默認的架構（default schema）——dbo。
由於我們使用自定義架構，這也降低了數據庫表名被猜測出來的可能性。
LINQ to SQL
前面使用了存儲過程和參數化查詢，這兩種方法都是非常常用的，而針對於.NET Framework的ORM框架也有很多，如：NHibernate，Castle和Entity Framework，這里我們使用比較簡單LINQ to SQL。
圖 12 添加jobs.dbml文件
var dc = new pubsDataContext(); int result; // Validates jobId is int or not. if (int.TryParse(jobId, out result)) { gdvData.DataSource = dc.jobs.Where(p => p.job_id == result); gdvData.DataBind(); }相比存儲過程和參數化查詢，LINQ to SQL我們只需添加jobs.dbml，然后使用LINQ對表進行查詢就OK了。
1.1.3 總結
我們在本文中介紹了SQL Injection的基本原理，通過介紹什么是SQL Injection，怎樣進行SQL Injection和如何防范SQL Injection。通過一些程序源碼對SQL的攻擊進行了細致的分析，使我們對SQL Injection機理有了一個深入的認識，作為一名Web應用開發人員，一定不要盲目相信用戶的輸入，而要對用戶輸入的數據進行嚴格的校驗處理，否則的 話，SQL Injection將會不期而至。
最后，祝大家新年快樂，身體健康，Code with pleasure。
