如此高效通用的分页存储过程是带有sql注入漏洞的

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/archive/2007/03/09/pagination_proc_problem.html