前 SQL INJECTION 攻击测试愈演愈烈， 很多大型的网站和论坛都相继被注入。 这些网站一般使用的多为 SQL SERVER 数据库， 正因为如此， 很多人开始怀疑 SQL SERVER 平安性。 其实 SQL SERVER 2000 已经通过了美国政府的 C2 级安全认证 - 这是该行业所能拥有的最高认证级别， 所以使用 SQL SERVER 还是相当的平安的当然和 ORCAL DB2 等还是有差距， 但是 SQL SERVER 易用性和广泛性还是能成为我继续使用下去的理由。 那怎么样才干使 SQL SERVER 设置让人使用的放心呢？
第一步肯定是打上 SQL SERVER 最新的平安补丁 . 如果这一步都没有做好， 那我也没有继续下去的必要了
第 二步是修改默认的 1433 端口， 并且将 SQL SERVER 隐藏。 这样能禁止对试图枚举网络上现有的 SQL Server 客户端所发出的广播作出响应。 另外， 还需要在 TCP/IP 筛选中将 1433 端口屏蔽掉， 尽可能的隐藏你 SQL SERVER 数据库。 这样子一但让攻击创建了 SQL SERVER 账号， 也不能马上使用查询分析器远程登陆来进行下一步的攻击。 单从 ASP PHP 等页面构造恶意语句的话， 还有需要检查返回值的问题， 总比 不上直接查询分析器来得利落。 所以我首先要做到即使让别人注入了也不能让攻击者下一步做得顺当。 修改方法：企业管理器 --> 数据库组 --> 属性 --> 惯例 --> 网络配置 --> TCP/IP --> 属性 这儿将你默认端口进行修改， 和 SQL SERVER 隐藏。
第三步是很重要的一步， SQL INJECTION 往往在 WEB CODE 中产生。 而做为系统管理员或者数据库管理员， 总不能常常的去看每一段代码。 即使经常看代码， 也不能保证我上面的疏忽。 那怎么办？就要从数 据库角色着手， 让数据库用户的权限划分到最低点。 SQL SERVER 默认权限让人真的很头疼， 权限大得非常的高， 权限小的又什么都做不了 SYSADMIN 和 db_owner 真是让人又爱又恨。 攻击者一但确 认了网站存在 SQL INJECTION 漏洞， 肯定有一步操作方法就是测试网站的 SQL SERVER 使用者具有多大的权限。 一般都会借助 SELECT IS_SRVROLEMEMBER 'sysadmin' 或者 SELECT IS_MEMBER 'db_owner' 再或者用 user = 0 让字符和数字进行比拟， SQL SERVER 就会提示了错误信息， 从该信息中即可知道一些敏感信息 ) 等语句进行测试。 方法还有， 也不敢多说了其一怕错， 其二怕联盟中的人扁。 当前， 如果网站的数据库使用者用的 SA 权限， 再加上确认了 WEB 所处在绝对路径， 那么就宣告了网站的 OVER db_owner 权限也一样， 如果确认了绝对路径， 那么有 50 ％的机会能给你机器中上 WEB 方式的木马， 如海阳等。 所以这儿我确认了一点， 必需要创建自已的权限， 让攻击者找不着下嘴的地方。 这儿引用一个 SQL SERVER 联机协助中的例子：
创立 SQL Server 数据库角色的方法（企业管理器）
创立 SQL Server 数据库角色
1. 展开服务器组， 然后展开服务器。
2. 展开 " 数据库 " 文件夹， 然后展开要在其中创建角色的数据库。
3. 右击 " 角色 " 然后单击 " 新建数据库角色 " 命令。
4. " 名称 " 框中输入新角色的名称。
5. 单击 " 添加 " 将成员添加到 " 规范角色 " 列表中， 然后单击要添加的一个或多个用户。 可选）
只有选定数据库中的用户才干被添加到角色中。
对象权限
处置数据或执行过程时需要称为对象权限的权限类别：
SELECT INSERT UPDATE 和 DELETE 语句权限， 可以应用到整个表或视图中。
SELECT 和 UPDATE 语句权限， 可以有选择性地应用到表或视图中的单个列上。
SELECT 权限， 可以应用到用户定义函数。
INSERT 和 DELETE 语句权限， 会影响整行， 因此只可以应用到表或视图中， 而不能应用到单个列上。
EXECUTE 语句权限， 可以影响存储过程和函数。
语句权限
创 建数据库或数据库中的项（如表或存储过程）所涉及的活动要求另一类称为语句权限的权限。 例如， 如果用户必需能够在数据库中创建表， 则应该向该用户授予 CREATE TABLE 语句权限。 语句权限（如 CREATE DATABASE 适用于语句自身， 而不适用于数据库中定义的特定对象。
语句权限有：
BACKUP DATABASE
BACKUP LOG
CREATE DATABASE
CREATE DEFAULT
CREATE FUNCTION
CREATE PROCEDURE
CREATE RULE
CREATE TABLE
CREATE VIEW
暗示性权限
暗示性权限控制那些只能由预定义系统角色的成员或数据库对象所有者执行的活动。 例如， sysadmin 固定服务器角色成员自动继承在 SQL Server 装置中进行操作或查看的全部权限。
数据库对象所有者还有暗示性权限， 可以对所拥有的对象执行一切活动。 例如， 拥有表的用户可以检查、添加或删除数据， 更改表定义， 或控制允许其他用户对表进行操作的权限。
db_owner 数据库中有全部权限。
db_accessadmin 可以添加或删除用户 ID
db_securityadmin 可以管理全部权限、对象所有权、角色和角色成员资格。
db_ddladmin 可以发出 ALL DDL 但不能发出 GRANT REVOKE 或 DENY 语句。
db_backupoperator 可以发出 DBCC CHECKPOINT 和 BACKUP 语句。
db_datareader 可以选择数据库内任何用户表中的所有数据。
db_datawriter 可以更改数据库内任何用户表中的所有数据。
db_denydatareader 不能选择数据库内任何用户表中的任何数据。
db_denydatawriter 不能更改数据库内任何用户表中的任何数据。
这儿把新建的数据库角色的权限配置好， 比如需要使用哪个表、视图、存储过程等。 然后把 Db_owner 和 db_securityadmin db_backupoper 取消， 不给攻击者 BACKUP DATABASE 和 CREATE TABLE 机会， 一但攻击者具有这两个权限， 那么你网站就还处在十分危险的状态。 还有注意一下， 创建数据库账号时， 千万不能对服务器角色进行选择。
第 四步是修改 SQL SERVER 内置存储过程。 SQL SERVER 估计是为了装置或者其它方面， 内置了一批危险的存储过程。 能读到注册表信息， 能写入注册表信息， 能读磁盘共享信息等等 ...... 各位看到这儿， 心里可能会在想， 网站中有其它代码， 又不像查询分析器那样能查接将结果输出。 给你这个权限， 又不能怎么样， 还是看不到信息。 如果各位这样想就 大错特错了提示一下， 如果攻击者有 CREATE TABLE 权限， 那么创建一个临时表， 然后将信息 INSERT 表中， 然 SELECT 进去， 接着跟数字进行比拟， 让 SQL SERVER 报错， 那么结果就全出来了 ...... 所以我要报着宁错杀， 不放过的态度进行修补。
先来列出危险的内置存储过程：
xp_cmdshell
xp_regaddmultistring
xp_regdeletekey
xp_regdeletevalue
xp_regenumkeys
xp_regenumvalues
xp_regread
xp_regremovemultistring
xp_regwrite
ActiveX 自动脚本：
sp_OACreate
sp_OADestroy
sp_OAMethod
sp_OAGetProperty
sp_OASetProperty
sp_OAGetErrorInfo
sp_OAStop
将有安全问题的 SQL 过程删除 . 比较全面 . 一切为了平安 !
删除有安全隐患的扩展 :
exec sp_dropextendedproc 'xp_cmdshell' [ 删除此项扩展后 , 将无法远程连接数据库 ]
exec sp_dropextendedproc 'xp_dirtree' [ 删除此项扩展后 , 将无法新建或附加数据库 ]
exec sp_dropextendedproc 'xp_enumgroups'
exec sp_dropextendedproc 'xp_fixeddrives'
exec sp_dropextendedproc 'xp_loginconfig'
exec sp_dropextendedproc 'xp_regaddmultistring'
exec sp_dropextendedproc 'xp_regdeletekey'
exec sp_dropextendedproc 'xp_regdeletevalue'
exec sp_dropextendedproc 'xp_regread'
exec sp_dropextendedproc 'xp_regremovemultistring'
exec sp_dropextendedproc 'xp_regwrite'
exec sp_dropextendedproc 'xp_enumerrorlogs'
exec sp_dropextendedproc 'xp_getfiledetails'
exec sp_dropextendedproc 'xp_regenumvalues'
恢复扩展
exec sp_addextendedproc 'xp_cmdshell', 'xplog70.dll'
exec sp_addextendedproc 'xp_dirtree', 'xpstar.dll'
exec sp_addextendedproc 'xp_enumgroups', 'xplog70.dll'
exec sp_addextendedproc 'xp_fixeddrives', 'xpstar.dll'
exec sp_addextendedproc 'xp_loginconfig', 'xplog70.dll'
exec sp_addextendedproc 'xp_regaddmultistring', 'xpstar.dll'
exec sp_addextendedproc 'xp_regdeletekey', 'xpstar.dll'
exec sp_addextendedproc 'xp_regdeletevalue', 'xpstar.dll'
exec sp_addextendedproc 'xp_regread', 'xpstar.dll'
exec sp_addextendedproc 'xp_regremovemultistring', 'xpstar.dll'
exec sp_addextendedproc 'xp_regwrite', 'xpstar.dll'
exec sp_addextendedproc 'xp_enumerrorlogs', 'xpstar.dll'
exec sp_addextendedproc 'xp_getfiledetails', 'xpstar.dll'
exec sp_addextendedproc 'xp_regenumvalues', 'xpstar.dll'
全部复制到 "SQL 查询分析器 "
点击菜单上的 --" 查询 "--" 执行 " 就会将有安全问题的 SQL 过程删除 ( 以上是 7i24 正版用户的技术支持 )
更改默认 SA 空密码 . 数据库链接不要使用 SA 帐户 . 单数据库单独设使用帐户 . 只给 public 和 db_owner 权限 .
数据库不要放在默认的位置 .
SQL 不要装置在 PROGRAM FILE 目录下面 .
以 上各项全在封杀之列， 例如 xp_cmdshell 屏蔽的方法为： sp_dropextendedproc 'xp_cmdshell' 如果需要的话， 再用 sp_addextendedproc 'xp_cmdshell', 'xpsql70.dll' 进行恢复。 如果你不知道 xp_cmdshell 使用的哪个 .dll 文件的话， 可以使用 sp_helpextendedproc xp_cmdshell 来查看 xp_cmdshell 使用的哪个动态联接库。 另外， 将 xp_cmdshell 屏蔽后， 还需要做的方法是将 xpsql70.dll 文件进行改名， 以防止获得 SA 攻击者将它进行恢复。
做到这儿， SQL SERVER 就基本上平安了但是信息还是能一样的外泄。 终究 SELECT 无法取消的除非你网站用的 HTML SQL INJECTION 防范还需要我这些顺序员来注意， 这才是治本之法。 高级设置篇再接着对 SQL SERVER 平安做下一步的分析。 该篇文章如果有什么错漏， 请大家多多包涵。 谢谢 ......
……