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 回答