我注意到大多数 FOSS 应用程序(例如 Wordpress)只使用一组已被授予所有权限的数据库凭据。这似乎违反了最小特权原则。
在编写这样的应用程序时,最好使用多个帐户,例如,一个帐户仅用于 SELECT 查询,另一个用于 UPDATE 等?
我注意到大多数 FOSS 应用程序(例如 Wordpress)只使用一组已被授予所有权限的数据库凭据。这似乎违反了最小特权原则。
在编写这样的应用程序时,最好使用多个帐户,例如,一个帐户仅用于 SELECT 查询,另一个用于 UPDATE 等?
这绝对违反了最小特权原则。让我们回到定义:
在信息安全、计算机科学等领域,最小特权原则,也称为最小特权原则或最小特权原则,要求在计算环境的特定抽象层中,每个模块(如进程、基于我们正在考虑的层的用户或程序)必须能够仅访问其合法目的所必需的此类信息和资源。
在您的 Wordpress 示例中,公共用户正在使用 SQL 帐户从数据库中检索数据,该帐户也具有更改或删除该数据的能力。此用户的“最小权限”不包括更改该数据的访问权限,无论它是直接在表上还是通过存储过程。这绝对不符合“仅访问其合法目的所必需的此类信息和资源”。
SQL 环境中的风险主要是 SQL 注入。一个小缺陷,如果该公共帐户有权造成损害,那么您最终会遇到各种问题。是的,输入应该被验证,是的查询应该被参数化,但这是一个额外的防御层,给你一些额外的保障。
我在OWASP Top 10 for .NET 开发人员第 1 部分中专门讨论了这一点:注入。
我想如果只是为了维护问题,情况会更糟。一个用户意味着凭据在一个地方,并且可以在一个地方为每台服务器更新它们。此外,大多数框架都假设一个凭据集来统治它们,虽然允许两个以上的凭据并不难,但它更烦人。
有一些好处是,如果您有一个仅具有选择权限的用户,您不必担心 SQL 注入(当然不是在Bobby Tables级别),但即使这样也不能保证,所以您会无论如何都必须清理您的数据输入(他们仍然可以根据选择进行注入攻击......)。
最佳实践是授予存储过程而不是表级别的权限。