Kzq*_*qai 6 mysql security php sql
我继承了一个非常不安全的 php web 应用程序，有 sql 注入的历史。我无法立即修复脚本，我宁愿需要它们运行才能使网站运行，并且有太多的 php 脚本需要首先从 php 端处理。但是，我确实可以完全控制服务器和服务器上的软件，包括完全控制 mysql 数据库及其用户。
让我们估计它总共有 300 个脚本、40 个半私有脚本和 20 个私有/安全脚本。
所以我的问题是如何最好地保护数据，隐含假设来自 php 端的 sql 注入（例如在 300 个脚本列表中的某个地方）是不可避免的？
我的初稿计划是在 mysql 数据库中创建多层不同权限的用户。这样我可以先保护最需要保护的数据和脚本（“私有/安全”类别），然后是第二层数据库表和脚本（“半私有”），最后处理整个 php 应用程序的其余部分（最终保护主要处理“公共”信息的数据库表的结果，例如，即使只是查看主页也需要的东西）。
因此，3 个数据库用户（公共、半私有和安全），三个不同的脚本组（安全脚本、半私有脚本和公共脚本）中的每一个都有不同的用户连接。通过这种方式，我可以阻止从“公共”或“半私有”访问“安全”，以及从“公共”访问“半私有”。我应该考虑其他替代方案吗？如果要采用分层访问系统，那么哪种方法最好？
简单的答案是“您无法真正防止数据库级别的 SQL 注入”。一旦他们使用手头的查询连接到数据库，您的数据库就会执行它——如果有人向该 SQL 注入了恶意内容，您希望做的最好的事情就是减轻他们可能造成的损害。
在减轻损害方面，您已经描述了一个很好的方法：将每个脚本限制为使用一个数据库用户帐户，该帐户仅限于脚本所需的最低访问权限（选择、插入、更新、删除和仅适用于脚本必须触摸）。
这并不能保护您的数据库免受 SQL 注入的影响——它只是限制了某人可以根据他们破坏的脚本窃取（或破坏）的数据量。一个坚定的攻击者可能会首先攻击“有趣的”脚本，这些脚本首先拥有他们想要的多汁数据。
就不可预见的问题而言，将用户角色分离可能只提供最小的安全收益（如果您有很多复杂的跨表查询和执行多项操作的脚本），但存在服务器损坏的风险（特别是如果您有很多复杂的执行多项操作的脚本的跨表查询）。
值得注意的是，在这个级别审计你的数据库可能比用适当的参数化查询替换所有当前调用花费的时间（如果不是更多），这使得 SQL 注入攻击变得困难或不可能。