带SQL server注入漏洞的分页存储过程.docVIP

带SQL server注入漏洞的分页存储过程 带SQL server注入漏洞的分页存储过程2010年04月28日星期三16：53在Google中搜索分页存储过程会出来好多结果，是大家常用的分页存储过程，今天我却要说它是有漏洞的，而且漏洞无法通过修改存储过程进行补救。 通常大家都会认为存储过程可以避免SQL Server注入的漏洞，这适用于一般的存储过程，而对于通用分页存储过程是不适合的，请看下面的代码和分析！ 一般的通用的分页存储过程代码如下： CREATE PROCEDURE pagination @tblName varchar(255),--表名 @strGetFields varchar(1000)=*,--需要返回的列 @fldName varchar(255)=,--排序的字段名 @PageSize int=10,--页尺寸 @PageIndex int=1,--页码 @doCount bit=0,--返回记录总数,非0值则返回 @OrderType bit=0,--设置排序类型,非0值则降序 @strWhere varchar(1500)=--查询条件(注意：不要加where) AS declare@strSQL varchar(5000)--主语句 declare@strTmp varchar(110)--临时变量 declare@strOrder varchar(400)--排序类型 if@doCount！=0 begin if@strWhere！= set@strSQL=select count(*)as Total from[+@tblName+]where+@strWhere else set@strSQL=select count(*)as Total from[+@tblName+] end --以上代码的意思是如果@doCount传递过来的不是0，就执行总数统计。以下的所有代码都是@doCount为0的情况。 else begin if@OrderType！=0 begin set@strTmp=(select min set@strOrder=order by[+@fldName+]desc --如果@OrderType不是0，就执行降序，这句很重要！ end else begin set@strTmp=(select max set@strOrder=order by[+@fldName+]asc end if@PageIndex=1 begin if@strWhere！= set@strSQL=select top+str(@PageSize)+ +@strGetFields+from[+@tblName+]where +@strWhere++@strOrder else set@strSQL=select top+str(@PageSize)+ +@strGetFields+from[+@tblName+]+@strOrder --如果是第一页就执行以上代码，这样会加快执行速度 end else begin --以下代码赋予了@strSQL以真正执行的SQL代码 set@strSQL=select top+str(@PageSize)+ +@strGetFields+from[ +@tblName+]where[+@fldName+]+@strTmp+ ([+@fldName+])from(select top+str((@PageIndex-1)*@PageSize)+ [+@fldName+]from[+@tblName+]+@strOrder+)as tblTmp) +@strOrder if@strWhere！= set@strSQL=select top+str(@PageSize)++@strGetFields+from[ +@tblName+]where[+@fldName+]+@strTmp+([ +@fldName+])from(select top+str((@PageIndex-1)*@PageSize)+[ +@fldName+]from[+@tblName+]where+@strWhere+ +@strOrder+)as tblTmp)and+@strWhere++@strOrder end end exec(@strSQL) GO 大家可以看到上面的存储过程中是通过一些步骤最终拼接成一个SQL Server字符串，然后通过exec执行这个串得到分页的结果。 我们假定要做一个这样的查询，通过用户名UserName模糊查询用户，为了叙述方便，便于理解我们只考虑取第一页的情况，取出存储过程中取第一页的拼串行如下： set@strSQL=SELECT TOP+str(