原文: 通用分頁(yè)存儲(chǔ)過(guò)程真的有注入漏洞嗎?

? ?? 今天看了兩篇關(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ù)不同的條件讀取用戶信息。

IF ( EXISTS ( SELECT??? *
????????????? 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;

?????? ?
??????? }

if(sUserName!="")
{
? 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)！

?

?

通用分頁(yè)存儲(chǔ)過(guò)程真的有注入漏洞嗎?