对于 Web 应用程序,在创建将连接到 MySQL 数据库的用户时,您可以选择权限。假设该用户打算执行的唯一操作是 SELECT/INSERT/UPDATE/DELETE,只提供这些权限似乎是有意义的,但是我从未在任何地方看到过推荐 - 支持和反对的原因是什么方法?
3 回答
我不同意 Bill 的观点,Atomix 的思路更合适。除非可以另外证明,否则比尔的回答大大增加了数据库被破坏的风险。
也许对于非常有经验的开发人员来说,还有其他安全措施,但是对于其他开发人员来说,让脚本完全、不受限制地访问数据库来做任何事情是在自找麻烦,而无需这样做。
这里应该使用最小特权原则。对于 MySQL,有一个具有所有权限的超级用户,用于创建表、删除数据库等。理想情况下,此用户名和密码永远不会出现在任何 PHP 文件或 Web 服务器上的任何文件中。(我以 PHP 为例,但它适用于其他 Web 应用程序)。您只能将此用户名和密码用于 PHPMyAdmin 或 MySQL Workbench。
然后,对于 PHP 脚本,有一个具有最低要求的,例如只插入、选择、更新,甚至可能没有删除,这取决于你的 PHP 脚本。这将在 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 是非常危险的。
用户在普通应用程序期间可能需要其他权限,例如:
- 创建临时表
- 执行(存储过程)
- 文件(用于 SELECT INTO 和 LOAD DATA)
- 锁定表
还有一种可能性是,最小权限可能意味着仅对某些表执行 SELECT,而对其他表仅执行 SELECT 和 UPDATE 等。这可能会在应用程序功能增强时随时更改。还有一些奇怪的情况,比如需要对您从未查询的表具有 SELECT 特权,因为它被您更新的表中的外键引用。因此,跟踪最低权限是一件非常痛苦的事情。
您想通过使用 SQL 权限来限制什么?您是编写所有代码的人,因此无需细粒度地管理 SQL 权限。坦率地说,如果您的用户能够上传和运行您未经审查的 SQL 语句,那么您将面临更大的问题:
SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;
您想要管理的真正任务不在数据库级别,而是在应用程序业务级别。例如,CMS 具有创建页面、编辑页面、管理评论等操作。这些任务比 SQL 权限级别更高。您可以使用 SQL 角色(即权限组)来模仿它们,但 SQL 角色并未得到广泛支持。
我不知道有人将他们的应用程序用户映射到不同的 MySQL 用户。他们是您在应用程序连接到数据库后在应用程序中进行身份验证的用户(用户只是数据库中的数据行)。
因此,您最好让您的 Web 应用程序使用具有完全权限的单个 MySQL 用户。
Web 应用程序通常只使用一个用户来访问数据库,而不是每个实际用户帐户的用户。应用最低权限是一种很好的做法。用户名和密码将被编码到您的脚本中(是否有人混淆了这一点?)因此,如果您的脚本管理不善,就有妥协的余地。
以我的经验,我很少让应用程序删除行 - 最好将行标记为已删除,然后审核那里的内容,而不是不知道那里有什么!这种方法还有助于保持表和索引的优化。
因此,我建议只允许 INSERT、UPDATE 和 SELECT - 如果您的应用程序的某些部分需要稍微放松一下,它很快就会变得明显!
允许更多权限只能通过发出资源密集型命令或允许恶意数据攻击来扩大 DoS 攻击的可能性。