这样一个高效且通用的分页存储过程是带有sql注入漏洞的

在谷歌搜索“分页存储过程”会得到很多结果，这是一个常用的分页存储过程。今天，我想说它有漏洞，而这些漏洞是不能通过修改存储过程来弥补的。如果你认为我错了，请阅读它，你可能会改变你的看法。一般认为，存储过程可以避免sql注入的漏洞，SQL注入适用于一般的存储过程，但不适用于一般的分页存储过程。请看下面的代码和分析！一般分页存储过程代码如下：复制代码如下： create procedure paging @ tblname varchar(255)，-表名@strGetFields varchar(1000)='* '，-要返回的列@ fldname varchar (255)='，-排序字段名@ pagesizeint=10，-page size @ pageindexint=1，-页码@ docount bit=0，-返回记录总数，如果值不为0，则返回@ ordertype bit=0。-设置排序类型。如果该值不是0，它将按降序排列@ strwherevarchar(1500)=' '-查询条件(注意不要在：中添加where)为declare @ strsqlvarchar(5000)-main语句declare @ strtmpvarchar(110)-临时变量declare @ strorder varchar (400)-。=0开始if @strWhere！='' set @strSQL='选择count(*)作为Total from [' @tblName ']其中'[email protected]else set @ strSQL='选择count(*)作为Total from[' @ tblName ']' end-上面的代码表示如果@doCount不通过0，将执行总计数。当@ doctor为0时，如果@OrderType为0，则以下所有代码都是开始！=0 begin set @ strtmp='(选择min ' set @ str order=' order by[' @ fldname ']desc '-如果@OrderType不是0，执行降序很重要！end else begin set @strTmp='(选择max ' set @ strOrder=' order by[' @ fldName ']ASC ' end if @ page index=1 begin if @ strWhere！=' ' set @ STrsql=' select top ' str(@ PageSize)' '[email protected]' from[' @ tblName ']其中' @ STrwhere ' ' @ strOrder else set @ STrsql=' select top ' str(@ PageSize)' '[email protected]' from[' @ tblName ']@ strOrder-如果是第一页，执行上面的代码。这将加快执行速度，endelse begin-下面的代码为@strSQL提供了实际执行set @ STrsql=' select top ' str(@ page size)' '[email protected]' from[' @ tblname ']的SQL代码。其中[' @ Fldname ']' @ StRTMP '([' @ Fldname '])from(选择top ' str((@ page index-1)* @ PageSize)'[' @ Fldname ']from[' @ TBlname ']' @ strOrder ')作为tblTmp)' @strOrder if @strWhere！=' ' set @ STrsql=' select top ' str(@ PageSize)' '[email protected]' from[' @ TBlname ']其中[' @ Fldname ']' @ STrtMP '([' @ Fldname '])from(select top ' str((@ PageIndex-1)* @ PageSize)'[' @ Fldname ']from[' @ TBlname ']其中' @ strhere'' @ strorder ')为tbltmp)和' @ strhere'' @ strorder end exec('

让我们假设我们想要做这样的查询，并且通过UserName模糊地查询用户。为了方便描述和理解，我们只考虑取第一页。提取存储过程中第一页的拼写如下：从[“@ tblname”]设置@ strsql=“select top”str(@ page size)“@ strgetfields”。其中“@ strhere”@ strorder为了便于解释，我们可以假设@pageSize为20，@strGetFields为“*”，@tblName为UserAccount，@ strOrder为‘ORDER BY ID desc’，那么上面这一行就可以写成：set @ strsql='从[user account]中选择top 20 *。其中“@ strhere”按id desc排序“我们可以假设用户输入的模糊用户名是： Jim的狗。我们使用SqlParameter向分页存储过程传递参数。@ strhere的值为：“UsernameLike”“% Jim”“Dog %”(注意L. The后字符串中的单引号都变成了两个单引号。)我们将这个值代入上面的@strSQL赋值语句。Set @ strsql='从[用户帐户]中选择前20个*其中用户名如' ' % Jim'' dog% ' '按id desc排序'让我们写下声明变量的部分，并在查询分析器中测试它。代码如下：复制代码如下： declare @ strsqlvarchar(8000)declare @ strhere varchar(1000)。SET @ strWhere=' UserName LIKE ' ' % Jim ' ' dog % ' ' ' SET @ strSQL=' SELECT TOP 20 * from[user account]Where ' @ strhere ' order by iddesc ' print @ strSQL exec(@ strSQL)您可以将以上几行代码粘贴到查询分析器中并执行，可以看到如下图片：。

在消息的第一行，打印要执行的sql语句。显然，LIKE“% Jim”之后的语句的所有部分都被截断了。也就是说，如果用户从UserAccount中输入Jim的狗而不是Jim的delete，那么删除操作就会正确执行，传奇的sql注入就会出现。有问题，应该怎么解决？1.显然，我们通过使用SqlParameter传递参数，已经将单引号替换成了偶数单引号，但是我们在数据库中串线导致的替换并不能解决问题。2.根据我的实验，如果用存储过程解决不了这个问题，我们只有把这个存储过程要执行的字符串操作放到数据访问层，才能避免这个问题。如果您在存储过程中有这个问题的解决方案，请随时评论。注意：本文是关于MS SQL Server2000的数据库，而不是用SQL 2005的新特性分页。