原文: 通用分頁存儲過程真的有注入漏洞嗎?

? ?? 今天看了兩篇關于存儲過程SQL注入漏洞的文章:

? ?? 1): 如此高效通用的分頁存儲過程是帶有sql注入漏洞的

? ?? 2): 防SQL注入：生成參數化的通用分頁查詢語句

???? 怎么看怎么覺的別扭,在我印象中存儲過程是不會存在注入漏洞的啊?起碼我目前的水平還不了解如何注入存儲過程。如果大家有注入的方法請指教。換句話說存儲過程本身并無注入漏洞，只不過有漏洞大多都是因為程序漏洞導致。

???? 我們來簡化下之前兩位園友討論的分頁存儲過程,原代碼太長,我這里呢寫一個針對一個單表查詢的存儲過程。創建一個用戶表,表結構如下:有三個字段，人員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]

???? 然后寫一個查詢存儲過程（getPerson）:作用，根據不同的條件讀取用戶信息。

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) -- 主語句
??????? SET @strSQL = 'select top 10 * from person where 1=1 '
?? ?--如果存在條件,則加上
??????? IF @strWhere != ''
??????????? BEGIN
??????????????? SET @strSQL = @strSQL + @strWhere?? ? ??? ?
??????????? END
??????? PRINT ( @strSQL )
??????? EXEC ( @strSQL
??????????? )
??? END

? ?? 查詢方式，根據用戶的姓來查詢。要想最終的存儲過程執行語法正確，同時不存在注入漏洞， 此時條件的正確格式是:and first_name like '%Jim''s dog%'。

? ? 我們可以看到條件Jim's dog組裝成SQL后，中間的單引號一定要變成兩個。為了避免注入，我一般這樣處理SQL拼接的安全問題:在C#寫程序的時候應該這樣寫:

/// <summary>
??????? /// 屏蔽字符串中的特殊字符
??????? /// by minjiang 07-07-06
??????? /// </summary>
??????? public? string? SafeRequest(string str)
??????? {
??????????? //定義要返回的字符串
??????????? string sReturn;
??????????? //將要處理的字符串轉換為小寫字母
??????????? 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)
??????????????? {
??????????????????? //把單引號替換成雙引號
??????????????????? 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)+"%'"

}

???? 分頁存儲過程注入的機會： 上面的通用分頁存儲過程之所以會說存在SQL注入的機會，是因為通配符like后面的單引號,如果在后面參數中也出現單引號與like通配符后面的單引號相匹配后，后面的內容就是SQL注入的內容了。此時我們可以寫一個過濾SQL特殊字符的方法,對特殊字符進行處理，可能根據自己的情況，選取相應過濾條件。最起碼要把用戶名中的單引號替換成雙引號。下面的寫法是不安全的：用戶名中有單引號,例如 ：Jim's dog

if(sUserName!="")
{
? strWhere +=" and first_name like'%"+sUserName+"%'"

}

? ?? 說明: 園友 小No 提到,能夠通過把輸入注入條件編碼成十六進制編碼來騙過過濾程序。這種情況的確存在，所有可以針對html標簽中又屬于SQL敏感字符的內容進行十六進制的比較。例如：‘，;?！?”不用處理，因為它不會被HTML編碼。? ? ? ??

? ?? 我個人不太支持這種所謂高效的通用分頁存儲過程，理由：

???? 1：可閱讀性太差，整版的字符串，誰看著都不舒服。

? ?? 2：對應用程序有比較高的安全要求，稍不注意就會存在上面所說的注入漏洞。

???? 3：對多表的復雜查詢無能無力。如果強行應用，我想遠比單獨寫一個存儲過程來的麻煩。

? ?? 4：所謂通用，即大多數人都知道你這個存儲過程的大致結構，這樣無疑給別有用心者更多可趁之機。

? ?? 針對分頁存儲過程的處理，不妨看看這篇： 你是如何面對大量分頁需求的?

? ?? 總結： 通用分頁存儲過程本身是沒有漏洞可言的，只不過是程序的不嚴謹造成的注入機會。

??? 解決這種拼接SQL字符串可能帶來的隱患方案：

? ? 1：盡量對輸入參數進行類型設置，能設置成數字型的一定要設成數字型。

??? 2：設置好參數的長度，一個字符串，例如姓名，一般不會超過20個字符。

? ? 3：輸入的參數內容能刪除空格的就最好利用Trim(),這樣，就算有SQL敏感字符，一旦SQL連接成一串，那也是不能夠正常注入。

??? 4：盡量過濾傳入的條件，起碼要把單引號替換成雙引號。

??? 5:嚴格設置數據庫用戶的權限，負責查詢的用戶，只讓它具有讀的權限，這樣就算是注入成功，也不能造成致命的后果。

具有插入權限的用戶，嚴格控制刪除，更新的權限。而傭有刪除權限的用戶，一般都傭有查看權限，刪除操作是很難存在SQL注入的。

注：

?? 歡迎大家發表意見！

?

?

通用分頁存儲過程真的有注入漏洞嗎?