【发布时间】：2010-09-25 01:22:38
【问题描述】：
对于 Web 应用程序，在创建将连接到 MySQL 数据库的用户时，您可以选择权限。假设该用户打算执行的唯一操作是 SELECT/INSERT/UPDATE/DELETE，只提供这些权限似乎是有意义的，但是我从未在任何地方看到过推荐 - 支持和反对的原因是什么方法？
【问题讨论】：
标签： mysql privileges
【发布时间】：2010-09-25 01:22:38
【问题描述】：
用户在普通应用程序中可能还需要其他权限，例如：
- 创建临时表
- 执行（存储过程）
- 文件（用于 SELECT INTO 和 LOAD DATA）
- 锁表
最小权限也有可能意味着仅对某些表执行 SELECT，而对其他表仅执行 SELECT 和 UPDATE 等。这可能会在应用程序功能增强时随时更改。还有一些奇怪的情况，比如需要对您从未查询的表具有 SELECT 特权，因为它被您更新的表中的外键引用。因此，跟踪最小特权是一件非常痛苦的事情。
您想通过使用 SQL 权限来限制什么？您是编写所有代码的人，因此无需细粒度地管理 SQL 权限。坦率地说，如果您的用户能够上传和运行未经您审查的 SQL 语句，那么您将面临更大的问题：
SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;
您要管理的实际任务不在数据库级别，而是在应用程序业务级别。例如，CMS 具有创建页面、编辑页面、管理 cmets 等操作。这些任务比 SQL 权限级别更高。您可以使用 SQL 角色（即权限组）来模仿它们，但 SQL 角色并未得到广泛支持。
我不知道有谁将他们的应用程序用户映射到不同的 MySQL 用户。他们是您在应用程序中进行身份验证的用户，在应用程序连接到数据库之后（用户只是数据库中的数据行）。
因此，您最好让您的网络应用使用具有完全权限的单个 MySQL 用户。
【讨论】：
-
有趣...但是您应该只授予用户完全权限似乎很疯狂。我在这里错过了什么吗？为什么不拥有一个对所有数据库具有读写权限的“WebUser”。也许不是分钟。特权，但肯定不完整。为什么还要邀请用户执行“DROP MyDatabase”；命令？当然，您的代码应该不允许执行原始 sql...但是会出错，这只是较低级别。
-
@Atomiton：这很好，但这意味着需要 DDL 命令的实际管理任务必须使用不同的数据库凭据或至少使用不同的角色。但是人们希望将管理界面集成到同一个 Web 应用程序中。那么您的应用程序是否应该使用不同的凭据即时重新连接到数据库？还是应该授予 WebUser 该应用程序的任何用户（甚至是管理员）所需的联合权限？我想大多数人都会选择后者，无论好坏。
-
@Bill：我想我应该为我的管理员用户设置一个不同的连接字符串。如果他们以管理员身份登录，请以更多权限连接。也许我只是偏执。我明白你在应用程序中管理权限的意思，你是对的......它不应该让用户造成伤害。但我想这有点像因为你锁了门而让你的保险箱没有上锁。有时，您会错过您打开的那个窗口。但是，如果保险箱被锁定，重要的东西仍然是安全的。同样，锁定数据库似乎……嗯……更安全。原谅双关语。 :)
-
@Atomiton：在用户进行身份验证之前，您如何知道用户是您应用中的管理员？在您的应用连接到数据库之前如何进行身份验证？
-
@Bill：你说得对，我不知道。我的做法是让所有用户都以基本用户身份进行身份验证。他们在登录之前无法开始做事。登录后，我将切换到使用适当的连接字符串进行后续请求。这意味着在通信层上做更多的工作，但我通常会设置这个层一次并将其用于多个项目。当然，这部分也是由我们的 dba 决定的，他们不会让我向所有用户授予完全访问权限。 （她不信任数据库服务器上的开发人员 :-)）
Web 应用程序通常只使用一个用户来访问数据库，而不是每个实际用户帐户一个用户。应用最低权限是一种很好的做法。用户名和密码将被编码到您的脚本中（有没有人混淆它？）所以如果您的脚本管理不善，就有妥协的余地。
根据我的经验，我很少让应用删除行 - 最好将行标记为已删除，然后审核那里的内容，而不是不知道那里有什么！这种方法还有助于保持表和索引的优化。
因此，我建议只允许 INSERT、UPDATE 和 SELECT - 如果您的应用程序的某些部分需要稍微放松一下，它很快就会变得明显！
允许更多权限只能通过发出资源密集型命令或允许恶意数据攻击来扩大 DoS 攻击的可能性。
【讨论】：
-
回复：混淆数据库连接密码：stackoverflow.com/questions/334776/…
-
我的意思是整个应用程序的单个数据库用户，而不是每个实际用户一个数据库用户。
我不同意 Bill 的观点，Atomix 的思路更合适。除非可以另外证明，否则比尔的回答大大增加了数据库被破坏的风险。
也许对于非常有经验的开发人员来说，还有其他安全措施，但对于其他开发人员来说，让脚本完全、不受限制地访问数据库以做任何事~是在自找麻烦，而无需这样做。
这里应该使用最小权限原则。对于 MySQL，有一个具有所有权限的超级用户，用于创建表、删除数据库等。理想情况下，此用户名和密码永远不会出现在任何 PHP 文件或 Web 服务器上的任何文件中。 （我以 PHP 为例，但它适用于其他 Web 应用程序）。您只能将此用户名和密码用于 PHPMyAdmin 或 MySQL Workbench。
然后，对于 PHP 脚本，根据您的 PHP 脚本，有一个所需的最低要求，例如仅 INSERT、SELECT、UPDATE，甚至可能没有 DELETE。这将在 PHP 文件中，也就是说，实际上只有文档根目录之外的一个文件，这是大多数人推荐的。
原因是这样的：是的，您不需要为每个 Web 应用程序用户提供一个 MySQL 用户。但应适用最小特权原则 (http://en.wikipedia.org/wiki/Principle_of_least_privilege)。如果您的 MySQL 超级用户由于您不小心将 MySQL 连接脚本命名为 .txt 而不是 .php 或有人获得了对 Web 服务器文件的访问权限而受到损害，那么至少他们能做的“最糟糕”的事情是 SELECT、UPDATE 和 INSERT。 .. 虽然这可能会导致大问题，但不如给他们 DROP DATABASE、DROP TABLES 和更糟糕的事情。
另外，在我目前的项目中，由于敏捷开发实践（我不工作但推荐http://www.agilealliance.org/），一两个“非技术”团队成员直接使用 PHPMyAdmin 对 MySQL 数据库进行直接更改。这是因为不需要为简单的直接数据输入创建 CMS。在这种情况下，第三个 MySQL 用户具有合理但同样“足够”的权限适合他们。我们不想削弱权限太少的团队成员，但他们当然不能意外删除或更改内容。
由于 MySQL 没有 ROLES（在提出原始问题时，并且根据 Bill），因此允许任何 Web 脚本仅通过一个超级用户访问 MySQL 是非常危险的。
【讨论】：
-
我只想指出，如果上述内容听起来太刺耳，我很抱歉，这是由于发帖时的压力所致。我通常不会这么认真，希望大家能欣赏讨论。干杯。
-
UNION常用吗？它在某些类型的攻击中很重要，所以也许它是一个很好的阻止候选者？