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

　　今天看了兩篇關於存儲過程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注入的。