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

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

在google中搜索“分页存储过程”会出来好多结果,是大家常用的分页存储过程,今天我却要说它是有漏洞的,而且漏洞无法通过修改存储过程进行补救,如果你觉得我错了,请读下去也许你会改变看法。

通常大家都会认为存储过程可以避免sql注入的漏洞,这适用于一般的存储过程,而对于通用分页存储过程是不适合的,请看下面的代码和分析!

一般的通用的分页存储过程代码如下:

如此高效通用的分页存储过程是带有sql注入漏洞的如此高效通用的分页存储过程是带有sql注入漏洞的通用分页存储过程
如此高效通用的分页存储过程是带有sql注入漏洞的CREATE PROCEDURE pagination
如此高效通用的分页存储过程是带有sql注入漏洞的@tblName varchar(255), -- 表名 
如此高效通用的分页存储过程是带有sql注入漏洞的@strGetFields varchar(1000) = '*', -- 需要返回的列 
如此高效通用的分页存储过程是带有sql注入漏洞的@fldName varchar(255)='', -- 排序的字段名 
如此高效通用的分页存储过程是带有sql注入漏洞的@PageSize int = 10, -- 页尺寸 
如此高效通用的分页存储过程是带有sql注入漏洞的@PageIndex int = 1, -- 页码 
如此高效通用的分页存储过程是带有sql注入漏洞的@doCount bit = 0, -- 返回记录总数, 非 0 值则返回 
如此高效通用的分页存储过程是带有sql注入漏洞的@OrderType bit = 0, -- 设置排序类型, 非 0 值则降序 
如此高效通用的分页存储过程是带有sql注入漏洞的@strWhere varchar(1500) = '' -- 查询条件 (注意: 不要加 where) 
如此高效通用的分页存储过程是带有sql注入漏洞的AS 
如此高效通用的分页存储过程是带有sql注入漏洞的
如此高效通用的分页存储过程是带有sql注入漏洞的declare @strSQL varchar(5000) -- 主语句 
如此高效通用的分页存储过程是带有sql注入漏洞的declare @strTmp varchar(110) -- 临时变量 
如此高效通用的分页存储过程是带有sql注入漏洞的declare @strOrder varchar(400) -- 排序类型 
如此高效通用的分页存储过程是带有sql注入漏洞的if @doCount != 0 
如此高效通用的分页存储过程是带有sql注入漏洞的begin 
如此高效通用的分页存储过程是带有sql注入漏洞的if @strWhere !='' 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'select count(*) as Total from [' + @tblName + '] where '+@strWhere 
如此高效通用的分页存储过程是带有sql注入漏洞的else 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'select count(*) as Total from [' + @tblName + ']' 
如此高效通用的分页存储过程是带有sql注入漏洞的end 
如此高效通用的分页存储过程是带有sql注入漏洞的--以上代码的意思是如果@doCount传递过来的不是0,就执行总数统计。以下的所有代码都是@doCount为0的情况 
如此高效通用的分页存储过程是带有sql注入漏洞的
如此高效通用的分页存储过程是带有sql注入漏洞的else 
如此高效通用的分页存储过程是带有sql注入漏洞的begin 
如此高效通用的分页存储过程是带有sql注入漏洞的if @OrderType != 0 
如此高效通用的分页存储过程是带有sql注入漏洞的begin 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strTmp = '<(select min' 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strOrder = ' order by [' + @fldName +'] desc' 
如此高效通用的分页存储过程是带有sql注入漏洞的--如果@OrderType不是0,就执行降序,这句很重要! 
如此高效通用的分页存储过程是带有sql注入漏洞的end 
如此高效通用的分页存储过程是带有sql注入漏洞的
如此高效通用的分页存储过程是带有sql注入漏洞的else 
如此高效通用的分页存储过程是带有sql注入漏洞的begin 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strTmp = '>(select max' 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strOrder = ' order by [' + @fldName +'] asc' 
如此高效通用的分页存储过程是带有sql注入漏洞的end 
如此高效通用的分页存储过程是带有sql注入漏洞的if @PageIndex = 1 
如此高效通用的分页存储过程是带有sql注入漏洞的begin 
如此高效通用的分页存储过程是带有sql注入漏洞的if @strWhere != '' 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFields+ ' from [' + @tblName + '] where ' + @strWhere + ' ' + @strOrder 
如此高效通用的分页存储过程是带有sql注入漏洞的else 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFields+ ' from ['+ @tblName + '] '+ @strOrder 
如此高效通用的分页存储过程是带有sql注入漏洞的--如果是第一页就执行以上代码,这样会加快执行速度 
如此高效通用的分页存储过程是带有sql注入漏洞的end 
如此高效通用的分页存储过程是带有sql注入漏洞的
如此高效通用的分页存储过程是带有sql注入漏洞的else 
如此高效通用的分页存储过程是带有sql注入漏洞的begin 
如此高效通用的分页存储过程是带有sql注入漏洞的--以下代码赋予了@strSQL以真正执行的SQL代码 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFields+ ' from [' 
如此高效通用的分页存储过程是带有sql注入漏洞的+ @tblName + '] where [' + @fldName + ']' + @strTmp + '(['+ @fldName + ']) from (select top ' + str((@PageIndex-1)*@PageSize) + ' ['+ @fldName + '] from [' + @tblName + ']' + @strOrder + ') as tblTmp)'+ @strOrder 
如此高效通用的分页存储过程是带有sql注入漏洞的if @strWhere != '' 
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'select top ' + str(@PageSize) +' '+@strGetFields+ ' from [' 
如此高效通用的分页存储过程是带有sql注入漏洞的+ @tblName + '] where [' + @fldName + ']' + @strTmp + '([' 
如此高效通用的分页存储过程是带有sql注入漏洞的+ @fldName + ']) from (select top ' + str((@PageIndex-1)*@PageSize) + ' [' 
如此高效通用的分页存储过程是带有sql注入漏洞的+ @fldName + '] from [' + @tblName + '] where ' + @strWhere + ' ' 
如此高效通用的分页存储过程是带有sql注入漏洞的+ @strOrder + ') as tblTmp) and ' + @strWhere + ' ' + @strOrder 
如此高效通用的分页存储过程是带有sql注入漏洞的end 
如此高效通用的分页存储过程是带有sql注入漏洞的end 
如此高效通用的分页存储过程是带有sql注入漏洞的exec (@strSQL)
如此高效通用的分页存储过程是带有sql注入漏洞的GO
如此高效通用的分页存储过程是带有sql注入漏洞的
如此高效通用的分页存储过程是带有sql注入漏洞的

大家可以看到上面的存储过程中是通过一些步骤最终拼接成一个sql字符串,然后通过exec执行这个串得到分页的结果。

我们假定要做一个这样的查询,通过用户名UserName模糊查询用户,为了叙述方便,便于理解我们只考虑取第一页的情况,取出存储过程中取第一页的拼串行如下:

如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'SELECT TOP ' + str(@PageSize) + ' ' + @strGetFields + ' from [' + @tblName + ']  where ' + @strWhere + ' ' + @strOrder

为了便于说明问题,我们可以假定@pageSize为20,@strGetFields为 ‘*’,@tblName为UserAccount,@strOrder为’ ORDER  BY  ID DESC’ 那么上面一行可以写成如下形式:

如此高效通用的分页存储过程是带有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赋值语句中,如下:

如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'SELECT TOP 20 *  from [UserAccount]  where  UserName LIKE ''%Jim'' dog%'' ORDER BY ID DESC’

让我们写上声明变量的部分执行在查询分析器中测试一下,代码如下:

如此高效通用的分页存储过程是带有sql注入漏洞的DECLARE @strSQL varchar(8000)
如此高效通用的分页存储过程是带有sql注入漏洞的DECLARE @strWhere varchar(1000)
如此高效通用的分页存储过程是带有sql注入漏洞的SET @strWhere = 'UserName LIKE ''%Jim'' dog%'''
如此高效通用的分页存储过程是带有sql注入漏洞的set @strSQL = 'SELECT TOP 20 *  from [UserAccount]  where ' + @strWhere + ' ORDER BY ID DESC'
如此高效通用的分页存储过程是带有sql注入漏洞的print @strSQL
如此高效通用的分页存储过程是带有sql注入漏洞的exec (@strSQL)
如此高效通用的分页存储过程是带有sql注入漏洞的

大家可以把上面几行代码粘贴到查询分析器中执行一下,就可以看到下面的画面:

如此高效通用的分页存储过程是带有sql注入漏洞的
在消息的第一行,打印出了要执行的sql语句,很显然此语句的 LIKE ‘%Jim’ 后面的部分全部被截断了,也就是说如果用户输入的不是Jim’s dog而是Jim’ delete from UserAccount那么会正确的执行删除操作,传说中的sql注入就会出现了。

问题出现了,我们应该怎么解决问题?

1.  很显然我们使用SqlParameter传递参数已经将单引号替换成了连个单引号了,可是因为我们在数据库中拼串导致替换并不能解决问题。

2.  根据我的实验证明如果使用存储过程不可能解决这个问题,我们只有将这个存储过程要执行的拼串操作放到数据访问层去做,才可以避免这个问题。

如果大家有在存储过程中解决这个问题的办法,请不吝赐教。

备注:本文说的是MS SQL Server2000 的数据库,而非使用SQL 2005的新特性分页。

上一篇:读书笔记之SQL注入漏洞和SQL调优


下一篇:Linux中MySQL5.5解压版普通用户安装