DBO会对服务器造成什么危害?

发布于 2024-07-09 04:43:56 字数 213 浏览 14 评论 0原文

除了执行我在 SQL 2005 安装中禁用的 XP_CmdShell 之外,获得数据库 DBO 权限的恶意用户还能做什么:

  • 对我的数据库、
  • 对我的服务器?

我正在评估某人获取 DBO 来证明在应用程序中运行“最低权限”用户帐户的最坏情况的安全风险。 一些人声称,由于我们不使用“机密数据”,因此某人获得 DBO 的影响微乎其微。

Aside from executing XP_CmdShell, which I have disabled in my SQL 2005 installation, what could a malicious user who gains DBO rights to my database do:

  • To my database,
  • To my server?

I'm assessing the worst-case security risk of someone obtaining DBO to justify running a "least-privileged" user account in an application. Some allege that since we're not working with "confidential data" that the impact of someone gaining DBO is minimal.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

挽袖吟 2024-07-16 04:43:56

他可以运行任何 XP_ 存储过程,因此它可能会弄乱注册表并弄乱您的整个服务器。
删除/更改表等...

he can run any XP_ sproc so it can mess up the registry and mess up your whole server for one thing.
drop/change tables, etc...

世界如花海般美丽 2024-07-16 04:43:56

dbo 是数据库所有者 - 可能是也可能不是 sa。 作为 dbo,您基本上可以自由控制拥有的数据库 - 显然,这可能会导致权限更改、删除表等。

作为 sa,您可以自由控制服务器。 这包括安装新的扩展过程(如果启用了 CLR,则安装 .NET 程序集),以及 dbo 可以执行的所有操作(对于所有数据库)。 并且,您还可以再次启用xp_cmdshell

dbo is Database Owner - which may or may not be sa. As dbo, you basically have free reign over the owned database - obviously, this could lead to changed permissions, dropped tables, etc.

As sa, you have free reign over the server. This includes installing new extended procedures (or .NET assemblies if you have CLR enabled), as well as everything dbo can do (for all databases). And, you can also enable xp_cmdshell again.

澉约 2024-07-16 04:43:56

网上有很多关于 SQL 注入的信息。 限制连接 SQL 的用户的权限是一项非常重要的措施。

http://en.wikipedia.org/wiki/SQL_injection

这是一个简单、可怕的例子几年前遇到过。 网站使用 URL 即时生成 SQL 语句并运行它们。 我能够猜测像

www.blah.com/.../load.aspx?itemid=1

这样的 URL会产生这样的 SQL

SELECT * FROM items where id=1

所以我发送了这个 url:

www.blah.com/。 ../load.aspx?itemid=1;删除表项

至少,如果数据库连接不是 dbo,这将会失败。

Lots of info online about SQL injection. Limiting the privs of the user you connect to SQL with is one very important defesse.

http://en.wikipedia.org/wiki/SQL_injection

Here's a simple, frightening example I ran into a couple of years ago. Website generates SQL stateemnts on the fly using URLs and runs them. I was able to guess that URLs like

www.blah.com/.../load.aspx?itemid=1

produced SQL like this

SELECT * FROM items where id=1

so I sent this url:

www.blah.com/.../load.aspx?itemid=1;drop table items

bang.

At the very least, if the DB connection was not dbo this would have failed.

那片花海 2024-07-16 04:43:56

说白了,如果他拥有你的数据库,他就侵占你的数据库。 也就是说,您可以和数据说再见了。

To put it bluntly, if he owns your database, he pwns your database. That is to say, you can kiss your data good-bye.

挖鼻大婶 2024-07-16 04:43:56

也就是说,您可以和数据说再见了。

但是您在磁盘上和磁带上都有备份,所以您是黄金!

That is to say, you can kiss your data good-bye.

But you have backups on disk and on tape, so you are golden!

独守阴晴ぅ圆缺 2024-07-16 04:43:56

是的。 典型的防御是“好吧,至少他不能弄乱数据库之外的任何东西”(xp_CmdShell 未启用)。 我,我觉得家里锁着的壁橱里有一个疯狗强奸犯,我感到不舒服。 但这种类比对于管理层来说并不是一个很好的说服力。

Yeah. The typical defense is "well, at least he can't mess up anything outside of his database" (xp_CmdShell is not enabled). Me, I'm not comfortable having a mad-dog rapist in a locked closet in my house. But that analogy isn't a great sell to management.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文