DBO权利风险

Question

我建议管理SQL 2k5盒子的朋友，该盒子有几个用户可以访问多个数据库。问题是：

1. 这些用户在几个月内没有更改密码，
2. 这些用户将其ID放入应用程序，应用程序作为DBO运行。

那么 - 除了明显的添加/更新/删除表和过滤器的dbo权限之外，我还能指出哪些恶意用户有dbo到SQL 2005数据库？

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

---

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

Answer 1

我意识到这是一个5岁的帖子，但它从未被正确回答，并且有一些非常糟糕的信息已被发布。

首先，让我们看看联机丛书对“DBO”角色（priv）的看法。重点是我的。

  

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

总而言之，这意味着具有“DBO”权限的人可以对他们拥有该权限的任何数据库执行任何他们想要的任何操作。截至2005年，这也意味着他们可以放弃数据库。

另请注意，它并没有说是能够控制服务器的血腥事情。早在我记忆中，您需要“SA”或（最近）“Control Server”privs来执行xp_CmdShell。 DBO没有附带任何priv，所以它不能运行xp_CmdShell或许多其他以“xp_”或“sp _”开头的东西。

换档并且看起来OP已经有点意识到，DBO privs被认为是“高级私人”。我建议您从不将DBO priv授予应用程序（或其他前端），我只会将其授予应该是负责数据库管理员的人员。这些人需要像那些选择成为DBA的人一样明智地被选中。

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

Answer 2

是肯定的。 dbo有权在数据库上做任何想做的事情。甚至运行xp_cmdshell。一旦你可以运行xp_cmdshell，你几乎可以在系统上做任何事情。 这是可能的，只要dbo具有sysadmin权限，默认情况下它具有。

Answer 3

我同意Jeff关于从最小特权的角度进行处理的观点。只是为了证明db_owner比人们想象的要危险得多-请注意，它还允许攻击者执行以下操作：

• 将其特权升级为sysadmin，从而接管包括该服务器上所有其他数据库在内的整个服务器[请参见下面的参考资料，以了解两种可能的发生方式]
• 通过耗尽所有可用存储空间进行拒绝服务
• 通过耗尽所有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/