在google中搜索“分页存储过程”会出来好多结果，是大家常用的分页存储过程，今天我却要说它是有漏洞的，而且漏洞无法通过修改存储过程进行补救，如果你觉得我错了，请读下去也许你会改变看法。
通常大家都会认为存储过程可以避免sql注入的漏洞，这适用于一般的存储过程，而对于通用分页存储过程是不适合的，请看下面的代码和分析！
一般的通用的分页存储过程代码如下：
通用分页存储过程
大家可以看到上面的存储过程中是通过一些步骤最终拼接成一个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的新特性分页。
