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

在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的新特性分页。