DBO权利风险答案

【问题标题】：DBO rights riskDBO权利风险
【发布时间】：2010-09-22 08:36:51
【问题描述】：

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

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

所以 - 除了添加/更新/删除表和过程的明显 dbo 权限之外，对于拥有 dbo 到 SQL 2005 数据库的恶意用户，我可以列举哪些危险？

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

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

【问题讨论】：

标签： security dbo

【解决方案1】：

我知道这是一篇已有 5 年历史的帖子，但从未得到正确回答，并且发布了一些非常糟糕的信息。

首先，让我们看看联机丛书对“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...期间。

【讨论】：

【解决方案2】：

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

将他们的权限提升到系统管理员，从而接管整个服务器，包括其上的所有其他数据库 [请参阅下面的参考资料了解这可能发生的 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/

【讨论】：

【解决方案3】：

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

【讨论】：

我知道这是一篇旧帖子，但是，抱歉……这绝对不正确！只有那些拥有“SA”或“控制服务器”权限或（喘气！真是愚蠢的事情）已被赋予代理权限以直接运行它的登录才能运行 xp_CmdShell。这是我看到的第二个这样的帖子，里面有这种错误信息。你从哪里得到这些信息的？我问是因为提供它的人需要更正。
5 年前我知道的比现在还少。太好了，你纠正了我。 :)