在google中搜索“分頁存儲過程”會出來好多結果，是大家常用的分頁存儲過程，今天我卻要說它是有漏洞的，而且漏洞無法通過修改存儲過程進行補救，如果你覺得我錯了，請讀下去也許你會改變看法。
通常大家都會認為存儲過程可以避免sql注入的漏洞，這適用於一般的存儲過程，而對於通用分頁存儲過程是不適合的，請看下面的代碼和分析！
一般的通用的分頁存儲過程代碼如下：
通用分頁存儲過程
CREATE PROCEDURE pagination
@tblName varchar(255), -- 表名
@strGetFIElds varchar(1000) = '*', -- 需要返回的列
@fldName varchar(255)='', -- 排序的字段名
@PageSize int = 10, -- 頁尺寸
@PageIndex int = 1, -- 頁碼
@doCount bit = 0, -- 返回記錄總數, 非 0 值則返回
@OrderType bit = 0, -- 設置排序類型, 非 0 值則降序
@strWhere varchar(1500) = '' -- 查詢條件 (注意: 不要加 where)
AS
declare @strSQL varchar(5000) -- 主語句
declare @strTmp varchar(110) -- 臨時變量
declare @strOrder varchar(400) -- 排序類型
if @doCount != 0
begin
if @strWhere !=''
set @strSQL = 'select count(*) as Total from [' + @tblName + '] where '+@strWhere
else
set @strSQL = 'select count(*) as Total from [' + @tblName + ']'
end
--以上代碼的意思是如果@doCount傳遞過來的不是0，就執行總數統計。以下的所有代碼都是@doCount為0的情況
else
begin
if @OrderType != 0
begin
set @strTmp = '<(select min'
set @strOrder = ' order by [' + @fldName +'] desc'
--如果@OrderType不是0，就執行降序，這句很重要！
end
else
begin
set @strTmp = '>(select max'
set @strOrder = ' order by [' + @fldName +'] asc'
end
if @PageIndex = 1
begin
if @strWhere != ''
set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFIElds+ ' from [' + @tblName + '] where ' + @strWhere + ' ' + @strOrder
else
set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFIElds+ ' from ['+ @tblName + '] '+ @strOrder
--如果是第一頁就執行以上代碼，這樣會加快執行速度
end
大家可以看到上面的存儲過程中是通過一些步驟最終拼接成一個sql字符串，然後通過exec執行這個串得到分頁的結果。
我們假定要做一個這樣的查詢，通過用戶名UserName模糊查詢用戶，為了敘述方便，便於理解我們只考慮取第一頁的情況，取出存儲過程中取第一頁的拼串行如下：
set @strSQL = 'SELECT TOP ' + str(@PageSize) + ' ' + @strGetFIElds + ' from [' + @tblName + '] where ' + @strWhere + ' ' + @strOrder
為了便於說明問題，我們可以假定@pageSize為20，@strGetFIElds為 ‘*’，@tblName為UserAccount,@strOrder為’ ORDER BY ID DESC’ 那麼上面一行可以寫成如下形式：
set @strSQL = 'SELECT TOP 20 * from [UserAccount] where ' + @strWhere + ' ORDER BY ID DESC’
我們可以假定用戶輸入的模糊用戶名是: Jim’s dog
我們用SqlParameter傳遞參數給分頁存儲過程@strWhere 的值是：’UserName LIKE ‘’%Jim’’ dog%’’’(注意LIKE後邊的字符串中的單引號已經全部變成兩個單引號了)，我們將這個值代入上面的@strSQL賦值語句中,如下：
set @strSQL = 'SELECT TOP 20 * from [UserAccount] where UserName LIKE ''%Jim'' dog%'' ORDER BY ID DESC’
讓我們寫上聲明變量的部分執行在查詢分析器中測試一下，代碼如下：
DECLARE @strSQL varchar(8000)
DECLARE @strWhere varchar(1000)
SET @strWhere = 'UserName LIKE ''%Jim'' dog%'''
set @strSQL = 'SELECT TOP 20 * from [UserAccount] where ' + @strWhere + ' ORDER BY ID DESC'
print @strSQL
exec (@strSQL)
大家可以把上面幾行代碼粘貼到查詢分析器中執行一下，就可以看到下面的畫面：
在消息的第一行，打印出了要執行的sql語句,很顯然此語句的 LIKE ‘%Jim’ 後面的部分全部被截斷了，也就是說如果用戶輸入的不是Jim’s dog而是Jim’ delete from UserAccount那麼會正確的執行刪除操作，傳說中的sql注入就會出現了。
問題出現了，我們應該怎麼解決問題？
1． 很顯然我們使用SqlParameter傳遞參數已經將單引號替換成了連個單引號了，可是因為我們在數據庫中拼串導致替換並不能解決問題。
2． 根據我的實驗證明如果使用存儲過程不可能解決這個問題，我們只有將這個存儲過程要執行的拼串操作放到數據訪問層去做，才可以避免這個問題。
如果大家有在存儲過程中解決這個問題的辦法，請不吝賜教。
備注：本文說的是MS SQL Server2000的數據庫，而非使用SQL 2005的新特性分頁。
文章來源：http://www.cnblogs.com/yukaizhao/
