? ?? 今天看了兩篇關(guān)于存儲(chǔ)過(guò)程SQL注入漏洞的文章:
? ?? 1): 如此高效通用的分頁(yè)存儲(chǔ)過(guò)程是帶有sql注入漏洞的
? ?? 2): 防SQL注入:生成參數(shù)化的通用分頁(yè)查詢語(yǔ)句
???? 怎么看怎么覺(jué)的別扭,在我印象中存儲(chǔ)過(guò)程是不會(huì)存在注入漏洞的啊?起碼我目前的水平還不了解如何注入存儲(chǔ)過(guò)程。如果大家有注入的方法請(qǐng)指教。換句話說(shuō)存儲(chǔ)過(guò)程本身并無(wú)注入漏洞,只不過(guò)有漏洞大多都是因?yàn)槌绦蚵┒磳?dǎo)致。
???? 我們來(lái)簡(jiǎn)化下之前兩位園友討論的分頁(yè)存儲(chǔ)過(guò)程,原代碼太長(zhǎng),我這里呢寫一個(gè)針對(duì)一個(gè)單表查詢的存儲(chǔ)過(guò)程。創(chuàng)建一個(gè)用戶表,表結(jié)構(gòu)如下:有三個(gè)字段,人員ID,姓名字段。
CREATE TABLE [dbo].[person](?? ?[id] [int] NULL,
?? ?[last_name] [varchar](30) COLLATE Chinese_PRC_CI_AS NULL,
?? ?[first_name] [varchar](30) COLLATE Chinese_PRC_CI_AS NULL
) ON [PRIMARY]
???? 然后寫一個(gè)查詢存儲(chǔ)過(guò)程(getPerson):作用,根據(jù)不同的條件讀取用戶信息。
????????????? FROM????? sysobjects
????????????? WHERE???? id = OBJECT_ID(N'[dbo].[getPerson]')
??????????????????????? AND OBJECTPROPERTY(id, N'IsProcedure') = 1 ) )
??? BEGIN
??????? DROP PROCEDURE [dbo].[getPerson]
??? END
Go
CREATE PROC getPerson
??? @strWhere VARCHAR(100) = '' -- 查詢條件 (注意: 不要加 where)
AS
??? BEGIN
??????? DECLARE @strSQL VARCHAR(1000) -- 主語(yǔ)句
??????? SET @strSQL = 'select top 10 * from person where 1=1 '
?? ?--如果存在條件,則加上
??????? IF @strWhere != ''
??????????? BEGIN
??????????????? SET @strSQL = @strSQL + @strWhere?? ? ??? ?
??????????? END
??????? PRINT ( @strSQL )
??????? EXEC ( @strSQL
??????????? )
??? END
? ?? 查詢方式,根據(jù)用戶的姓來(lái)查詢。要想最終的存儲(chǔ)過(guò)程執(zhí)行語(yǔ)法正確,同時(shí)不存在注入漏洞, 此時(shí)條件的正確格式是:and first_name like '%Jim''s dog%'。
? ? 我們可以看到條件Jim's dog組裝成SQL后,中間的單引號(hào)一定要變成兩個(gè)。為了避免注入,我一般這樣處理SQL拼接的安全問(wèn)題:在C#寫程序的時(shí)候應(yīng)該這樣寫:
/// <summary>
??????? /// 屏蔽字符串中的特殊字符
??????? /// by minjiang 07-07-06
??????? /// </summary>
??????? public? string? SafeRequest(string str)
??????? {
??????????? //定義要返回的字符串
??????????? string sReturn;
??????????? //將要處理的字符串轉(zhuǎn)換為小寫字母
??????????? str = str.ToLower();
??????????? //定義特殊字符串
??????????? string SQL_KILL = "'|and|exec|insert|select|delete|update|count|*|%
|chr|mid|master|truncate|char|declare|set|;|from|=|--|drop|<|>";
??????????? char[] separator ={ '|' };
??????????? string[] sql = SQL_KILL.Split(separator);
??????????? for(int i=0;i<sql .Length ;i++)
??????????? {
??????????????? //如果有特殊字符則將它替換成為空
??????????????? if(str.IndexOf (sql [i].ToString ().ToLower ())>-1)
??????????????? {
??????????????????? //把單引號(hào)替換成雙引號(hào)
??????????????????? if (sql[i].ToString() == "'")
??????????????????? { str = str.Replace("'", "''"); }
??????????????????? else
??????????????????? {
??????????????????????? //把敏感字符替換成空
??????????????????????? str = str.Replace(sql[i].ToString().ToLower(), "");
??????????????????? }
?????????????? ?
??????????????? }
?????????? ?
??????????? }
??????????? sReturn = str;
??????????? return sReturn;
?????? ?
??????? }
{
? strWhere +=" and first_name like'%"+this.SafeRequest(sUserName)+"%'"
}
???? 分頁(yè)存儲(chǔ)過(guò)程注入的機(jī)會(huì): 上面的通用分頁(yè)存儲(chǔ)過(guò)程之所以會(huì)說(shuō)存在SQL注入的機(jī)會(huì),是因?yàn)橥ㄅ浞鹟ike后面的單引號(hào),如果在后面參數(shù)中也出現(xiàn)單引號(hào)與like通配符后面的單引號(hào)相匹配后,后面的內(nèi)容就是SQL注入的內(nèi)容了。此時(shí)我們可以寫一個(gè)過(guò)濾SQL特殊字符的方法,對(duì)特殊字符進(jìn)行處理,可能根據(jù)自己的情況,選取相應(yīng)過(guò)濾條件。最起碼要把用戶名中的單引號(hào)替換成雙引號(hào)。下面的寫法是不安全的:用戶名中有單引號(hào),例如 :Jim's dog
if(sUserName!="")
{
? strWhere +=" and first_name like'%"+sUserName+"%'"
}
? ??
說(shuō)明:
園友
小No
提到,能夠通過(guò)把輸入注入條件編碼成十六進(jìn)制編碼來(lái)騙過(guò)過(guò)濾程序。這種情況的確存在,所有可以針對(duì)html標(biāo)簽中又屬于SQL敏感字符的內(nèi)容進(jìn)行十六進(jìn)制的比較。例如:‘,;。“-”不用處理,因?yàn)樗粫?huì)被HTML編碼。? ? ? ??
? ?? 我個(gè)人不太支持這種所謂高效的通用分頁(yè)存儲(chǔ)過(guò)程,理由:
???? 1:可閱讀性太差,整版的字符串,誰(shuí)看著都不舒服。
? ?? 2:對(duì)應(yīng)用程序有比較高的安全要求,稍不注意就會(huì)存在上面所說(shuō)的注入漏洞。
???? 3:對(duì)多表的復(fù)雜查詢無(wú)能無(wú)力。如果強(qiáng)行應(yīng)用,我想遠(yuǎn)比單獨(dú)寫一個(gè)存儲(chǔ)過(guò)程來(lái)的麻煩。
? ?? 4:所謂通用,即大多數(shù)人都知道你這個(gè)存儲(chǔ)過(guò)程的大致結(jié)構(gòu),這樣無(wú)疑給別有用心者更多可趁之機(jī)。
? ?? 針對(duì)分頁(yè)存儲(chǔ)過(guò)程的處理,不妨看看這篇: 你是如何面對(duì)大量分頁(yè)需求的?
? ?? 總結(jié): 通用分頁(yè)存儲(chǔ)過(guò)程本身是沒(méi)有漏洞可言的,只不過(guò)是程序的不嚴(yán)謹(jǐn)造成的注入機(jī)會(huì)。
???
解決這種拼接SQL字符串可能帶來(lái)的隱患方案:
? ? 1:盡量對(duì)輸入?yún)?shù)進(jìn)行類型設(shè)置,能設(shè)置成數(shù)字型的一定要設(shè)成數(shù)字型。
??? 2:設(shè)置好參數(shù)的長(zhǎng)度,一個(gè)字符串,例如姓名,一般不會(huì)超過(guò)20個(gè)字符。
? ? 3:輸入的參數(shù)內(nèi)容能刪除空格的就最好利用Trim(),這樣,就算有SQL敏感字符,一旦SQL連接成一串,那也是不能夠正常注入。
??? 4:盡量過(guò)濾傳入的條件,起碼要把單引號(hào)替換成雙引號(hào)。
??? 5:嚴(yán)格設(shè)置數(shù)據(jù)庫(kù)用戶的權(quán)限,負(fù)責(zé)查詢的用戶,只讓它具有讀的權(quán)限,這樣就算是注入成功,也不能造成致命的后果。
具有插入權(quán)限的用戶,嚴(yán)格控制刪除,更新的權(quán)限。而傭有刪除權(quán)限的用戶,一般都傭有查看權(quán)限,刪除操作是很難存在SQL注入的。
注:
?? 歡迎大家發(fā)表意見(jiàn)!
?
?
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號(hào)聯(lián)系: 360901061
您的支持是博主寫作最大的動(dòng)力,如果您喜歡我的文章,感覺(jué)我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長(zhǎng)非常感激您!手機(jī)微信長(zhǎng)按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
