引用
microsoft activeX Data objects 2.X library
microsoft activeX Data objects recordset 2.X
Set conn = New ADODB.Connection
Set rs = New ADODB.Recordset
conn.ConnectionString = "Driver=;server=(local);uid=sa;pwd=;database=賬戶管理"
conn.ConnectionTimeout = 30
conn.Open
rs.Open "select * from 賬戶信息", conn, adOpenStatic, adLockReadOnly, adCmdText
text1=rs.fields("列")'實現顯示功能
...
要實現查詢就在rs.open的時候把條件代入
下一個上一個用rs.movenext這種方式
添加新記錄的代碼
with rs
.addnew
.fields("列")=text1
...
.update
end with
刪除:
rs.Delete adAffectCurrent
② 試解釋 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內容，因為這里觸發了第二個重寫規則
③ sql注入實驗
一般是or 1=1，使得該語句必定成立，但是目前都是用'?'，傳參方式放入，因此不會再出現這種現象了
④ SQL的實驗報告怎麼寫
實驗報告要點
一、扉頁
並非所有的實驗報告都有標題頁，但是如果講師想要標題頁，那麼它應該是一個單獨的頁面，包括：實驗的題目、自己的名字和實驗室夥伴的名字、導師的名字、進行實驗或提交報告的日期。
二、標題
標題寫著做了什麼。它應該簡短，並描述實驗或調查的要點。
三、介紹
通常情況下介紹是解釋實驗室目標或目的的一個段落。用一句話陳述假設。有時介紹可能包含背景信息，簡要總結實驗是如何進行的，陳述實驗的發現，並列出調查的結論。
四、步驟
描述在調查過程中完成的步驟。要足夠詳細，任何人都可以閱讀這一部分並復制實驗。提供一個圖表來描述實驗設置可能會有所幫助。
五、數據
從過程中獲得的數字數據通常以表格的形式呈現。數據包括進行實驗時記錄的內容。
六、結果
用語言描述數據的含義。有時「結果」部分會與「討論」部分結合在一起。
七、討論或分析
數據部分包含數字，「分析」部分包含根據這些數字進行的任何計算。這是解釋數據和確定假設是否被接受的地方，也是討論在進行調查時可能犯的任何錯誤的地方。
八、結論
大多數情況下，結論是一個段落，總結了實驗中發生的事情，假設是被接受還是被拒絕，以及這意味著什麼。
九、圖形和圖表
圖表和圖形都必須標有描述性的標題。在圖表上標注軸，確保包含測量單位。一定要參考報告正文中的圖和圖表。
十、參考
如果研究是基於別人的文獻，或者引用了需要文檔的事實，那麼應該列出這些參考文獻。
⑤ 舉例說明SQL注入的一般過程！
如果你以前沒試過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錯誤提示時的驗證。
第一節、SQL注入的一般步驟
首先，判斷環境，尋找注入點，判斷資料庫類型，這在入門篇已經講過了。
其次，根據注入參數類型，在腦海中重構SQL語句的原貌，按參數類型主要分為下面三種：
(A) ID=49 這類注入的參數是數字型，SQL語句原貌大致如下：
Select * from 表名 where 欄位=49
注入的參數為ID=49 And [查詢條件]，即是生成語句：
Select * from 表名 where 欄位=49 And [查詢條件]
(B) Class=連續劇 這類注入的參數是字元型，SQL語句原貌大致概如下：
Select * from 表名 where 欄位=』連續劇』
注入的參數為Class=連續劇』 and [查詢條件] and 『』=』 ，即是生成語句：
Select * from 表名 where 欄位=』連續劇』 and [查詢條件] and 『』=』』
(C) 搜索時沒過濾參數的，如keyword=關鍵字，SQL語句原貌大致如下：
Select * from 表名 where 欄位like 』%關鍵字%』
注入的參數為keyword=』 and [查詢條件] and 『%25』=』， 即是生成語句：
Select * from 表名 where欄位like 』%』 and [查詢條件] and 『%』=』%』
接著，將查詢條件替換成SQL語句，猜解表名，例如：
ID=49 And (Select Count(*) from Admin)>=0
如果頁面就與ID=49的相同，說明附加條件成立，即表Admin存在，反之，即不存在（請牢記這種方法）。如此循環，直至猜到表名為止。
表名猜出來後，將Count(*)替換成Count(欄位名)，用同樣的原理猜解欄位名。
有人會說：這里有一些偶然的成分，如果表名起得很復雜沒規律的，那根本就沒得玩下去了。說得很對，這世界根本就不存在100%成功的黑客技術，蒼蠅不叮無縫的蛋，無論多技術多高深的黑客，都是因為別人的程序寫得不嚴密或使用者保密意識不夠，才有得下手。
有點跑題了，話說回來，對於SQLServer的庫，還是有辦法讓程序告訴我們表名及欄位名的，我們在高級篇中會做介紹。
最後，在表名和列名猜解成功後，再使用SQL語句，得出欄位的值，下面介紹一種最常用的方法－Ascii逐字解碼法，雖然這種方法速度很慢，但肯定是可行的方法。
我們舉個例子，已知表Admin中存在username欄位，首先，我們取第一條記錄，測試長度：
http://www.19cn.com/showdetail.asp?id=49 and (select top 1 len(username) from Admin)>0
先說明原理：如果top 1的username長度大於0，則條件成立；接著就是>1、>2、>3這樣測試下去，一直到條件不成立為止，比如>7成立，>8不成立，就是len(username)=8
當然沒人會笨得從0,1,2,3一個個測試，怎麼樣才比較快就看各自發揮了。在得到username的長度後，用mid(username,N,1)截取第N位字元，再asc(mid(username,N,1))得到ASCII碼，比如：
id=49 and (select top 1 asc(mid(username,1,1)) from Admin)>0
同樣也是用逐步縮小范圍的方法得到第1位字元的ASCII碼，注意的是英文和數字的ASCII碼在1-128之間，可以用折半法加速猜解，如果寫成程序測試，效率會有極大的提高。
第二節、SQL注入常用函數
有SQL語言基礎的人，在SQL注入的時候成功率比不熟悉的人高很多。我們有必要提高一下自己的SQL水平，特別是一些常用的函數及命令。
Access：asc(字元) SQLServer：unicode(字元)
作用：返回某字元的ASCII碼
Access：chr(數字) SQLServer：nchar(數字)
作用：與asc相反，根據ASCII碼返回字元
Access：mid(字元串,N,L) SQLServer：substring(字元串,N,L)
作用：返回字元串從N個字元起長度為L的子字元串，即N到N+L之間的字元串
Access：abc(數字) SQLServer：abc (數字)
作用：返回數字的絕對值（在猜解漢字的時候會用到）
Access：A between B And C SQLServer：A between B And C
作用：判斷A是否界於B與C之間
第三節、中文處理方法
在注入中碰到中文字元是常有的事，有些人一碰到中文字元就想打退堂鼓了。其實只要對中文的編碼有所了解，「中文恐懼症」很快可以克服。
先說一點常識：
Access中，中文的ASCII碼可能會出現負數，取出該負數後用abs()取絕對值，漢字字元不變。
SQLServer中，中文的ASCII為正數，但由於是UNICODE的雙位編碼，不能用函數ascii()取得ASCII碼，必須用函數unicode ()返回unicode值，再用nchar函數取得對應的中文字元。
⑥ 求SQL資料庫實驗報告
*****系實驗（上機）報告
課程名稱 資料庫系統基礎
實驗名稱 數據查詢與存儲過程
學號 33
學生姓名 嘻習喜戲
成績
年 月 日
序號 5 實驗名稱 SQL數據查詢
實驗目的：
熟練掌握SQL SELECT 語句，能夠運用該語句完成各種查詢。
實驗內容：
用SQL SELECT 語句完成下列查詢：
1． 查詢客戶表中的所有記錄。
2． 從訂購單表中查詢客戶號信息（哪些客戶有訂購單）。
3． 查詢單價在20元以上（含）的產品信息。
4． 查詢單價在20元以上（不含）的產品名稱為牛奶的產品信息。
5． 查詢單價在20元以上（不含）的產品名稱為牛奶或德國乳酪的產品信息。
6． 查詢有2003年7月訂購單的客戶名稱、聯系人、電話號碼和訂單號信息。
7． 查詢有德國乳酪訂貨的客戶的名稱、聯系人和電話號碼信息。
8． 查詢有德國乳酪訂購需求的訂單名細記錄。
9． 查詢所有訂購數量（即訂單名細中每個訂購項目的數量）都在10個以上的訂購單的信息。
10． 找出和德國乳酪同等價位的所有產品信息。
11． 查詢單價范圍在10元到30元范圍內的產品信息（使用BETWEEN…AND）。
12． 從客戶表中查詢出客戶名稱中有「公司」二字的客戶信息（使用LIKE運算符）。
13． 從客戶表中查詢出客戶名稱中沒有「公司」二字的客戶信息（使用NOT LIKE運算符）。
14． 按產品的單價升序列出全部產品信息。
15． 先按產品名稱排序，再按單價排序列出全部產品信息。
16． 從產品表中查詢共有幾種產品。
17． 從訂購名細表中查詢德國乳酪的訂購總數。
18． 計算德國乳酪所有訂購的總金額。
19． 求所有訂購單的平均金額，在查詢結果中列出訂購單的個數和平均金額。
20． 求每個訂購單訂購的項目數和總金額。
21． 求每個客戶包含了德國乳酪訂購的訂單號及其最高金額和最低金額。
22． 求至少有兩個訂購項目的訂購單的平均金額。
23． 找出尚未最後確定訂購單（即訂購日期為空值的記錄）的有關客戶信息（客戶的名稱、聯系人和電話號碼）和訂單號。
24． 找出在2000年1月1日之後簽訂的訂購單的客戶信息（客戶的名稱、聯系人和電話號碼）、訂單號和訂購日期。
25． 列出每類產品（相同名稱）具有最高單價的產品信息（產品號、名稱、規格說明和單價，提示：使用內外層互相關嵌套查詢）。
26． 確定哪些客戶目前沒有訂購單（使用謂詞NOT EXISTS）。
27． 查詢目前有訂購單的客戶的信息（使用謂詞EXISTS）。
28． 查詢符合條件的產品信息，要求該產品的單價達到了任意一款產品名稱為牛奶的單價的一半（使用ANY或SOME量詞）。
29． 查詢符合條件的產品信息，要求該產品的單價大於任何一款產品名稱為牛奶的單價（使用ALL量詞）。
30． 設計如下的連接操作，並分析各自的特點：
•廣義笛卡兒積
•內連接
•外連接
•左連接
•右連接
•全連接
掌握存儲過程的創建命令，按照題目要求創建存儲過程，理解存儲過程的作用。
（1） 建立存儲過程。查詢單價范圍在x元到y元范圍內的產品信息。
（2） 建立存儲過程。查詢在某年某月某日之後簽訂的訂購單的客戶信息（客戶的名稱、聯系人和電話號碼）、訂單號和訂購日期。
（3） 建立存儲過程。將某產品的訂購日期統一修改為一個指定日期。
（4） 建立存儲過程。刪除沒有簽訂單的客戶信息。
實驗要求：
用SELECT語句完成本次實驗，並提交上機報告。
（1） 掌握存儲過程的創建命令，按照實驗內容的要求創建存儲過程，理解存儲過程的作用。
（2） 用CREATE PROCEDURE和EXECUTE 語句完成本次實驗，並提交上機報告。
實驗准備(本實驗預備知識和為完成本實驗所做的准備)：
仔細閱讀課本第五章關於SQL的數據查詢功能的內容
實驗過程(實驗的操作過程、遇到的問題及其解決辦法或未能解決的問題)：
用SQL SELECT 語句完成以上30題查詢
實驗總結(總結本次實驗的收獲、未解決的問題以及體會和建議等)：
熟練掌握SQL SELECT 語句，能夠運用該語句完成各種查詢
附錄（SQL語句）：
--1． 查詢客戶表中的所有記錄。
select * from 客戶
--2． 從訂購單表中查詢客戶號信息（哪些客戶有訂購單）
select 客戶號from 訂單where 訂單號!=null
--3． 查詢單價在元以上（含）的產品信息。
select *from 產品where 單價> 20 or 單價=20
--4． 查詢單價在元以上（不含）的產品名稱為牛奶的產品信息。
select *from 產品where 單價>20 and 產品名稱='牛奶'
－－． 查詢單價在元以上（不含）的產品名稱為牛奶或德國乳酪的產品信息
select *from 產品where 單價>20 and (產品名稱='牛奶'or 產品名稱='德國乳酪')
--6． 查詢有年月訂購單的客戶名稱、聯系人、電話號碼和訂單號信息
select 客戶名稱,聯系人, 電話,訂單號from 客戶,訂單where (year(訂購日期)=2003 and month (訂購日期)=7)and (訂單.客戶號=客戶.客戶號)
--7． 查詢有德國乳酪訂貨的客戶的名稱、聯系人和電話號碼信息。
select 客戶名稱,聯系人, 電話from 客戶
where
(客戶號= (select 客戶號from 訂單where(訂單號 =(select 訂單號from 訂單明細
where 產品號= ( select 產品號from 產品where 產品名稱= ' 德國乳酪' )))))
--8． 查詢有德國乳酪訂購需求的訂單名細記錄。
select * from 訂單明細where (數量!=null and 產品號=(select 產品號from 產品where 產品名稱= '德國乳酪'))
--9． 查詢所有訂購數量（即訂單名細中每個訂購項目的數量）都在個以上的訂購單的信息。
select * from 訂單where (訂單號in (select 訂單號from 訂單明細where (數量>10)))
--10． 找出和德國乳酪同等價位的所有產品信息。
select * from 產品where (
--11． 查詢單價范圍在元到元范圍內的產品信息（使用BETWEEN…AND）。
select * from 產品where (單價between 10 and 30)
--12． 從客戶表中查詢出客戶名稱中有「公司」二字的客戶信息（使用LIKE運算符）
select * from 客戶where 客戶名稱like '%公司%'
--13． 從客戶表中查詢出客戶名稱中沒有「公司」二字的客戶信息（使用NOT LIKE運算符）。
select * from 客戶where 客戶名稱not like '%公司%'
--14． 按產品的單價升序列出全部產品信息。
select *from 產品order by 單價
--15． 先按產品名稱排序，再按單價排序列出全部產品信息。
select * from 產品order by 產品名稱,單價
--16． 從產品表中查詢共有幾種產品。
select count ( distinct 產品名稱) as 產品總數from 產品
--17． 從訂購名細表中查詢德國乳酪的訂購總數
select sum (數量) as '訂購乳酪數量'
from 訂單明細
where 產品號in(select 產品號from 產品where 產品名稱='德國乳酪')
--18． 計算德國乳酪所有訂購的總金額
declare @a money
select @a=(select 單價from 產品where 產品名稱='德國乳酪')
declare @b int
select @b=(select sum (數量) as '訂購乳酪數量'
from 訂單明細
where 產品號in(select 產品號from 產品where 產品名稱='德國乳酪'))
declare @c int
select @c=@a*@b
select @c as 總金額
--19． 求所有訂購單的平均金額，在查詢結果中列出訂購單的個數和平均金額。
select 訂單均值= avg(單價*數量) ,訂單個數=count ( 訂單號)
from 訂單明細,產品
where 產品.產品號=訂單明細.產品號
--20． 求每個訂購單訂購的項目數和總金額。
select 訂單號, count (產品.產品號) as 項目數,sum(數量*單價) as 總金額
from 產品,訂單明細
where (產品.產品號=訂單明細.產品號)
group by 訂單號
--21．求每個客戶包含了德國乳酪訂購的訂單號及其最高金額和最低金額
select 客戶.客戶號,產品.產品號,數量*單價as 總金額
from 客戶,訂單,訂單明細,產品
where 客戶.客戶號=訂單.客戶號and 訂單.訂單號=訂單明細.訂單號and 訂單明細.產品號=產品.產品號and
產品名稱='德國乳酪'
order by 客戶號
compute max(數量*單價),min (數量*單價) by 客戶號
--22．求至少有兩個訂購項目的訂購單的平均金額
select 訂單號,avg(數量*單價),count(產品.產品號)
from 訂單明細,產品
where 訂單明細.產品號=產品.產品號
group by 訂單號
having count(產品.產品號)>=2
--23．找出尚未最後確定訂購單（即訂購日期為空值的記錄）的有關客戶信息
-- （客戶的名稱、聯系人和電話號碼）和訂單號
select 客戶名稱,聯系人,電話,訂單明細.訂單號
from 客戶, 訂單明細,訂單
where(客戶.客戶號= 訂單.客戶號) and 訂購日期=null
--24．找出在年月日之後簽訂的訂購單的客戶信息
--（客戶的名稱、聯系人和電話號碼）、訂單號和訂購日期
select 客戶名稱,聯系人,電話,訂單號,訂購日期
from 客戶,訂單
where 客戶.客戶號=訂單.客戶號
and year(訂購日期)>1996 and month(訂購日期)>4 and day(訂購日期)>2
--25．列出每類產品（相同名稱）具有最高單價的產品信息
--（產品號、名稱、規格說明和單價，提示：使用內外層互相關嵌套查詢）
select A.產品號, A.產品名稱, A.規格說明, A.單價
from 產品A
where 單價= (SELECT MAX(單價)
FROM 產品B
WHERE A.規格說明= B.規格說明)
--26．確定哪些客戶目前沒有訂購單（使用謂詞NOT EXISTS）
select *
from 客戶
where not exists (select* from 訂單where 客戶號=訂單.客戶號)
--27．查詢目前有訂購單的客戶的信息（使用謂詞EXISTS）
select *
from 客戶
where exists (select* from 訂單where 客戶號=訂單.客戶號)
--28．查詢符合條件的產品信息，要求該產品的單價達到了任
--意一款產品名稱為牛奶的單價的一半（使用ANY或SOME量詞）
select *
from 產品a
where(單價>any(select 單價/2 from 產品b where b.產品名稱='牛奶'))
--29．查詢符合條件的產品信息，要求該產品的單價大於任何
-- 一款產品名稱為牛奶的單價（使用ALL量詞）
select *
from 產品a
where(單價>all(select 單價from 產品b where b.產品名稱='牛奶'))
--30．設計如下的連接操作，並分析各自的特點：
-- •廣義笛卡兒積
SELECT *
FROM 客戶CROSS JOIN 訂購單
WHERE 客戶.客戶號= 訂購單.客戶號
-- •內連接
SELECT *
FROM 客戶INNER JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
-- •外連接
-- •左連接
SELECT *
FROM 客戶LEFT JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
-- •右連接
SELECT *
FROM 客戶RIGHT JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
-- •全連接
SELECT *
FROM 客戶FULL JOIN 訂購單
ON 客戶.客戶號= 訂購單.客戶號
說明：
1. 上機報告上傳到211.68.36.251的資料庫文件夾中的上傳目錄
2. 文件名的命名規則為：學號+姓名+實驗+序號。如：9724101汪偉的第二次上機報告名為：9724101汪偉實驗2
3. 封面由學生填寫；
4. 正文的實驗名稱、實驗目的、實驗內容、實驗要求已經由教師指定；
5. 實驗准備由學生在實驗或上機之前填寫；
6. 實驗過程由學生記錄實驗的過程，包括操作過程、遇到哪些問題以及如何解決等；
7. 實驗總結由學生在實驗後填寫，總結本次實驗的收獲、未解決的問題以及體會和建議等；
8. 將相關的語句粘貼到附錄中。
你自己改改吧。想要word原版的話再說一聲。
⑦ 關於sql注入
"select * from tb where col='"+value+"'";
一般可能就是這么拼接的，value="1』or '1'='1";那麼拼接出來的就是
"select * from tb where col='1' or '1'='1'"，這樣拼接出來的前面不管值為什麼都會因為後面的or '1'='1'恆等成立然後去查詢全表。
SQL注入是你已經知道有哪些注入點，在已知的注入點上再去猜解未知的列，盲注是反復嘗試不同數據請求根據伺服器的響應來判斷並逐漸分析欄位。
⑧ SQL注入的特點與危害分別有哪些
1、廣泛性：任何一個基於SQL語言的資料庫都可能被攻擊，很多開發人員在編寫Web應用程序時未對從輸入參數、Web表單、Cookie等接收到的值進行規范性驗證和檢測，通常會出現SQL注入漏洞。
2、隱蔽性：SQL注入語句一般都嵌入在普通的HTPP請求中，很難與正常語句區分開，所以當前許多防火牆都無法識別予以警告，而且SQL注入變種極多，攻擊者可以調整攻擊的參數，所以使用傳統的方法防禦SQL注入效果非常不理想。
3、危害大：攻擊者可以通過SQL注入獲取到伺服器的庫名、表名、欄位名，從而獲取到整個伺服器中的數據，對網站用戶的數據安全有極大的威脅。攻擊者也可以通過獲取到的數據，得到後台管理員的密碼，然後對網頁頁面進行惡意篡改。這樣不僅對資料庫信息安全造成嚴重威脅，對整個資料庫系統安全也有很大的影響。
4、操作方便：互聯網上有很多SQL注入工具，簡單易學、攻擊過程簡單，不需要專業的知識也可以自如運用。
⑨ sql語言實驗報告
1>
select
*
from
教師表
where
系別
='cs';
2>
select
姓名,2011-年齡
as
出生日期
from
學生表
3>
select
*
from
學生表
where
年齡<=20
and
系別='cs';
4>
select
*
from
學生表
where
年齡
not
between
18
and
20;
5>
select
姓名,年齡
from
教師表
where
系別
in('cs','is');
6>
select
*
from
教師表
where
姓名
like
'%敏';
7>
select
*
from
選課表
where
先修課
is
null;
8>
select
count(*)
from
教師表
9>
select
avg(成績),max(成績),min(成績)
from
選課表
where
課程號=5;
10>
select
count(*)
from
選課表
group
by
課程號