SQL Server安全问题全攻略之攻击

一片老文章，但是对理解sql server的库有很大帮助

原文地址：http://www.wzsky.net/html/Program/DataBase/34544.html

二、注入和跨库攻击

　　注入和跨库攻击可能是2004年黑客攻击中最流行的词了，它的原理和上面讲的都是获得了SQL Server管理员sa的权限，从而控制数据库，还可以利用xp_cmdshell这样的SQL Server的扩展存储过程控制Windows系统。注入和空口令获取sa权限的方法不同，注入是ASP程序在连接SQL Server时有漏洞，黑客利用漏洞获取了sa权限。说到这，小王有点疑问，程序中sa连接的是自己的库而扩展存储过程在master库中，如何利用的？简单的说，有sa 的权限后就能查询出用户建的什么库，库中有哪些表，表中有什么字段，表的纪录等。这些又是如何实现的呢？

　　要解答这个问题需要从两个方面着手，一是新建个库后，SQL Server起了什么变化？二是SQL Server的权限。

　　1、新建一个库后其在系统库和系统表的位置

　　例：在SQL Server新建一个库，库名称为：xyz，在该库下建一个test的表，表中字段为id、name、password。

　　1）、库在哪里？
　　SQL Server安装完毕后默认安装了master、model、msdb、northwind、pubs、tempdb这6个库，其中northwind、pubs是例子库，其它都是系统数据库，各有其用。xyz库建好后，库名称存在master库中的sysdatabases表中，如图9所示，sysdatabases表中的 dbid字段的值大于6的就是用户自己建的库。图10中用SELECT name FROM sysdatabases where dbid>6可以查出用户自己建的库，刚建的xyz库也在其中。

图9



图10

　　2）、表在哪里？

　　表名称存在xyz库中的sysobjects表且xtype='u'，如图11，输入SELECT *FROM sysobjects where xtype='u'可以查出表名称是test，记住我们刚建的表test对应的id是357576312

图11

　　3）、有哪些字段？

　　test表中有哪些字段呢？该表的字段存在xyz库中的syscolumns表中，且id等于sysobjects表中test表对应的id，也就是我们上面查出来的357576312。

　　如图12，输入SELECT * FROM syscolumns where id='357576312'可以查出test表中的字段。

图12

　　4）、总结

　　当有相应权限的用户连到SQL Server后，能通过查询master库中的sysdatabases表得到用户建的数据库名称，接着再查询用户数据库的sysobjects表查出创建的表，接着再查询用户数据库的syscolumns表查出表中的字段，进而查出纪录。

　　这个例子提到有相应权限的用户，那用户具有哪些权限呢？我们接着说。

　　2、理解用户、角色和权限这几个概念

　　要对这几个概念讲得很明白，需要很大的篇幅，本文只作简要介绍。

　　要想访问SQL Server必须是它的一个用户，如果要访问某个数据库，必须赋予该用户访问此数据库的权限。角色就是一系列权限的集合。用户和角色的关系就像Windows系统中的用户和用户组的关系。

　　还是举例说明吧！sa为什么有那么大的权限？

　　sa是SQL Server的默认超级用户，就像系统的administrator用户一样，如图13，点击在“安全性”——〉“登录”，在右栏的sa用户下鼠标右键，出现图14的sa属性界面选到“服务器角色”项，可以看到sa的角色是system administrators（简写为sysadmin）,前面提到角色就是一系列权限的集合，点击图14的“属性”，在图15中可以看到该角色拥有操作SQL Server的所有权限。如图16可以看出sa具有所有数据库的访问权限，现在明白sa为什么有那么大的权限了吧。

图13


图14


图15


图16

　　实际做管理系统时并不需要用户有那么大的权限，一般只要能访问自己建的库就行了。可以新建个用户，只给此用户有限的权限，这样安全系数应该高些，从这个思路出发看看如何实现。

　　1）、新建aaa用户

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

图17



图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语句，根据前文讲的原理暴出库、表及相应的纪录。

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