科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道带SQL server注入漏洞的分页存储过程(2)

带SQL server注入漏洞的分页存储过程(2)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

在Google中搜索“分页存储过程”会出来好多结果,是大家常用的分页存储过程,今天我却要说它是有漏洞的,而且漏洞无法通过修改存储过程进行补救。

作者:knowsky.com 来源:knowsky.com 2007年9月1日

关键字: 存储过程 SQL Server SQL Server 各版本 数据库

  • 评论
  • 分享微博
  • 分享邮件

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

带SQL server注入漏洞的分页存储过程(2)

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

set @strSQL = 'SELECT TOP ' + str(@PageSize) + '
 ' + @strGetFields + ' from [' + @tblName + ']  where ' + @strWhere + ' 
' + @strOrder

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

set @strSQL = 'SELECT TOP 20 *  from [UserAccount]  
where ' + @strWhere  + '
 ORDER BY ID DESC’

我们可以假定用户输入的模糊用户名是: Jim’s dog。

我们用SQL Parameter传递参数给分页存储过程@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 Server语句,很显然此语句的 LIKE ‘%Jim’ 后面的部分全部被截断了,也就是说如果用户输入的不是Jim’s dog而是Jim’ delete from UserAccount那么会正确的执行删除操作,传说中的SQL Server注入就会出现了。

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

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

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

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

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章