2

我建议管理一个 SQL 2k5 机器的朋友,该机器有几个用户可以通过 dbo 访问多个数据库。问题是:

  1. 这些用户已经有几个月没有更改密码了,
  2. 这些用户将他们的 ID 放入应用程序中,应用程序作为 DBO 运行。

所以 - 除了添加/更新/删除表和 procs 的明显 dbo 权限之外,对于将 dbo 访问 SQL 2005 数据库的恶意用户,我可以举出什么危险?

我想提供对数据库和其他用户造成伤害的特定场景。dbo 可以更改服务器上的文件分配吗?DBO 会影响未直接连接到该数据库的其他资源吗?


澄清一下,这是 SQL Server 2005,默认情况下 xp_cmdShell 没有为 DBO 用户授权。我仍然想知道是否存在明显的 CRUD 之外的风险。有人可以用 DBO 做什么?

4

3 回答 3

2

我意识到这是一个 5 年前的帖子,但它从未得到正确回答,并且发布了一些非常糟糕的信息。

首先,让我们看看 Books Online 对“DBO”角色 (priv) 的看法。重点是我的。

db_owner 固定数据库角色的成员可以对数据库执行所有配置和维护活动。

总而言之,这意味着拥有“DBO”权限的人可以对拥有该权限的任何数据库执行任何他们想做的事情。截至 2005 年,这也意味着他们可以删除数据库。

另请注意,它并没有说能够控制服务器是一件多么血腥的事情。据我所知,您需要“SA”或(最近)“控制服务器”权限来执行 xp_CmdShell。DBO 没有附带 priv,因此它不能运行 xp_CmdShell 或许多其他以“xp_”甚至“sp_”开头的东西。

换档,看起来 OP 已经有点意识到,DBO privs 被认为是“提升的 privs”。我建议您永远不要将 DBO priv 授予应用程序(或其他前端),我只会将其授予应该是负责数据库管理员的人。这些人需要像您选择成为 DBA 的人一样明智地选择。

要回答有关 CRUD 的其他问题……在大多数情况下,CRUD 由 ORM 执行,所需的最高权限是 db_DataReader 和 db_DataWriter。老实说,我什至不允许登录拥有这些权限。我知道世界上每个前端开发人员都会对我大喊大叫,但事实是,即使 CRUD 也应该通过存储过程来完成,以防止攻击者使用允许某人从表中删除的 db_DataWriter 进入。就我而言,应用程序(和其他前端)应该只有未修改的 PUBLIC privs 和执行某些存储过程的 privs ......期间。

于 2013-04-06T19:34:38.210 回答
0

我同意 Jeff 的观点,即从最低权限的角度来处理它。并且只是为了证明 db_owner 比人们想象的要危险得多 - 请注意,它还允许攻击者:

  • 将他们的权限提升到 sysadmin 从而接管整个服务器,包括其上的所有其他数据库 [请参阅下面的参考资料了解这可能发生的 2 种不同方式]
  • 通过用尽所有可用存储来执行拒绝服务
  • 通过用尽所有 RAM 来执行拒绝服务
  • 删除整个数据库

参考:

https://www.anujvarma.com/db_owner-security-risks/

https://www.itprotoday.com/sql-server/5-reasons-against-allowing-dbowner-role-permissions

https://akawn.com/blog/2012/02/why-you-should-be-cautious-with-the-dbo_owner-role/

于 2020-07-30T01:20:37.190 回答
-1

是的。dbo 有权对数据库做任何事情。甚至运行 xp_cmdshell。一旦你可以运行 xp_cmdshell,你就可以在系统上做几乎任何事情。这一切都是可能的,前提是 dbo 具有默认情况下具有的系统管理员权限。

于 2008-11-14T14:45:43.297 回答