在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 else begin --以下代碼賦予了@strSQL以真正執行的SQL代碼 set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFields+ ' from [' + @tblName + '] where [' + @fldName + ']' + @strTmp + '(['+ @fldName + ']) from (select top ' + str((@PageIndex-1)*@PageSize) + ' ['+ @fldName + '] from [' + @tblName + ']' + @strOrder + ') as tblTmp)'+ @strOrder if @strWhere != '' set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFields+ ' from [' + @tblName + '] where [' + @fldName + ']' + @strTmp + '([' + @fldName + ']) from (select top ' + str((@PageIndex-1)*@PageSize) + ' [' + @fldName + '] from [' + @tblName + '] where ' + @strWhere + ' ' + @strOrder + ') as tblTmp) and ' + @strWhere + ' ' + @strOrder end end exec (@strSQL)GO
大家可以看到上面的存儲過程中是通過一些步驟最終拼接成一個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 @strSQLexec (@strSQL)
大家可以把上面幾行代碼粘貼到查詢分析器中執行一下，就可以看到下面的畫面：
在消息的第一行，打印出了要執行的sql語句,很顯然此語句的 LIKE ‘%Jim’ 後面的部分全部被截斷了，也就是說如果用戶輸入的不是Jim’s dog而是Jim’ delete from UserAccount那麼會正確的執行刪除操作，傳說中的sql注入就會出現了。
問題出現了，我們應該怎麼解決問題？
1． 很顯然我們使用SqlParameter傳遞參數已經將單引號替換成了連個單引號了，可是因為我們在數據庫中拼串導致替換並不能解決問題。
2． 根據我的實驗證明如果使用存儲過程不可能解決這個問題，我們只有將這個存儲過程要執行的拼串操作放到數據訪問層去做，才可以避免這個問題。
如果大家有在存儲過程中解決這個問題的辦法，請不吝賜教。
備注：本文說的是MS SQL Server2000 的數據庫，而非使用SQL 2005的新特性分頁。
