在google中搜索“分頁存儲過程”會出來好多結果，是大家常用的分頁存儲過程，今天我卻要說它是有漏洞的，而且漏洞無法通過修改存儲過程進行補救，如果你覺得我錯了，請讀下去也許你會改變看法。

通常大家都會認為存儲過程可以避免sql注入的漏洞，這適用于一般的存儲過程，而對于通用分頁存儲過程是不適合的，請看下面的代碼和分析！

 

一般的通用的分頁存儲過程代碼如下：

 

大家可以看到上面的存儲過程中是通過一些步驟最終拼接成一個sql字符串，然后通過exec執行這個串得到分頁的結果。

 

我們假定要做一個這樣的查詢，通過用戶名username模糊查詢用戶，為了敘述方便，便于理解我們只考慮取第一頁的情況，取出存儲過程中取第一頁的拼串行如下：

 

為了便于說明問題，我們可以假定@pagesize為20，@strgetfields為 ‘*’，@tblname為useraccount,@strorder為’ order  by  id desc’ 那么上面一行可以寫成如下形式：

 

我們可以假定用戶輸入的模糊用戶名是: jim’s dog

我們用sqlparameter傳遞參數給分頁存儲過程@strwhere 的值是：’username like ‘’%jim’’ dog%’’’(注意like后邊的字符串中的單引號已經全部變成兩個單引號了)，我們將這個值代入上面的@strsql賦值語句中,如下：

 

讓我們寫上聲明變量的部分執行在查詢分析器中測試一下，代碼如下：

 

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注入就會出現了。

 

 

備注：本文說的是ms sql server2000 的數據庫，而非使用sql 2005的新特性分頁。