图18
2)、设置权限
如图18，在"服务器角色"选项中什么也不选，如图19，在"数据库访问"选项中只选"xyz"库，也就是说只让aaa用户访问xyz库。"数据库角色中答应"只选默认的"public"。
图19
图20
3)、测试
设置好后，用aaa用户登陆"SQL 查询分析器"，如图21，执行exec xp_cmdshell 'net user user1 /add'，出现了期待的结果，没有权限执行。
图21
接着执行SELECT name FROM sysdatabases where dbid>6，期待的结果是没有权限执行，可实际的结果和图10的查询结果一模一样，aaa用户不是没有master库的权限吗?aaa用户除了不能访问自己建的库wz_cxxt_new外，其它的库都能访问，问题出在哪呢?
问题出在public 角色，下面这段话是SQL Server帮助中写的。
public 角色是一个非凡的数据库角色，每个数据库用户都属于它。public 角色：
· 捕捉数据库中用户的所有默认权限。
· 无法将用户、组或角色指派给它，因为默认情况下它们即属于该角色。
· 含在每个数据库中，包括 master、msdb、tempdb、model 和所有用户数据库。
· 无法除去。
如图22是master库中的"public"角色，双击"public"，在界面中单击"权限"，出现图23界面，可以看到该角色具有sysdatabases的访问权限。可以看到权限分得非常细，有select、insert、update、delete等，如图24，把权限改为禁止，再执行SELECT name FROM sysdatabases时出现了"拒绝了对对象 'sysdatabases'(数据库 'master'，所有者 'dbo')的 SELECT 权限。"的提示。
图22
图23
图24
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语句，根据前文讲的原理暴出库、表及相Φ募吐肌?/p>
评论加载中…
 |