小心MSSQL注入漏洞
网络通信
星期一上午，在学校计算中心兼职的同学女巫MM找到我，说她负责维护的软件园地服务器昨天晚上莫名其妙地“当”了好长时间，她觉得很奇怪，让我帮着看看是不是有问题，有没有被入侵。
来到了计算中心机房，我用Administrator账号登录了软件园地主机。这台服务器操作系统是Windows 2000 Server，Web服务器为IIS 5.0，数据库采用Microsoft SQL Server 2000；对外只开放了80(提供软件下载服务)和5631(pcanywhere远程管理)两个端口。我初步判断，如果有问题，应该出在Web服务上。
打开c:\winnt\system32\logfiles\w3svc2，仔细地查看了最近一个星期的IIS日志文件，发现了如图1所示的记录。
原来Web服务果然存在着漏洞，而且是危险性很大的SQL注入漏洞。来自192.168.1.100的黑客经过探测，发现服务器存在着这个漏洞之后，接下来又想利用漏洞深入攻击(图2)。
很糟糕的是，服务器名是“sysadmin”，数据库连接账号是“dbo”。于是他激活了Guest账号，并把它添加到Administrator组(图3)。
由于防火墙的阻隔，这位老兄虽然获得了一个Admin账号，但却无法连接服务器。我认真分析了后面大量的日志，看得出他在接下来的攻击中，暴露了数据库名、管理表名、管理员ID、 密码。他用Web扫描器(IIS日志中有大量404 File Not Found 错误，而且时间相差很短)找到后台管理页面(manage/index.asp)，试图上传一个Webshell，不过没有成功，因为后台没有提供文件上传功能。
他的攻击止步于此，可以看出他的技术不高,经验也不足。如果利用xp_dirtree等扩展存储过程获得服务器本地目录和文件信息，找到Web绝对路径，再下载Pcanywhere密码文件*.CIF并解密，那么服务器就彻底完了。但是不能排除以前可能有人通过这种方法入侵过服务器(而且那时候的IIS日志也很可能会被清除了)，系统不一定是干净的，所以我只能建议女巫MM重装系统。
防范策略
1.SQL注入漏洞攻击可以归结为没有正确地检查用户发给服务器的信息，所以我们必须检查接收到的用户输入的数据。在本例中(download.asp)，可以只接收数字型参数，非数字型参数就拒绝执行并报错；另外，在ASP中使用 On Error Resume Next，屏蔽掉ASP错误信息提示，也能给入侵者设置很大的障碍。
2.一定不能在ASP程序中用DataBse Owner账号访问数据库，应只保留用于完成工作所需的最小权限。
3.记着务必要删除xp_cmdshell,xp_cmdsendmail、xp_regread、xp_regwrite、xp_dirtree、xp_subdirs等存储过程，这些东东我们一般用不着，但是却为黑客们开了方便的大门。
4.考虑到本地维护足以保证软件园地服务器正常的运行，所以只开放80端口就够了；从安全性考虑，本地可以只允许访问21和80两个端口。