那么如果代码的某些部分容易发生sql注入，那么如果用户碰巧使用了对所有内容没有通用写入权限的前端，至少用户不能向数据库写入任何内容？
【问题讨论】：
标签： sql security sql-injection
这种方法通常是拥有不同的角色，而不是真正的用户本身。至于 SQL 注入攻击，我将专注于彻底解决问题，而不是通过您提出的这种方法来缓解它。
【讨论】：
是的，我想说让用户使用仅允许他们使用网站所需的最低权限的帐户进行连接是一种很好的做法。如果您的网络用户应该只从数据库中读取数据，那么我肯定会创建一个只有读取权限的帐户，并让他们通过该帐户访问数据库。
更重要的是保护您的网络应用程序。即使用户没有写入您的数据库（想想被盗的信用卡号或密码），您仍然可能成为毁灭性 SQL 注入攻击的受害者。
【讨论】：
是的，但是有很多设计技术可以帮助控制您的数据库界面和表面积。
必须假设代码通常会在给定会话中的所有操作（读取和写入）中使用相同的登录名。但是，如果用户不是写入用户，则用于其会话的登录名当然不应该有任何写入权限。
减少暴露于 SQL 注入的表面积的一个好方法是，首先不要让该帐户直接更新任何表。
例如，通过存储过程进行写访问，唯一可能发生的注入是使用适当的参数执行这些过程。
【讨论】：
是的。除了 Abe 和 Cade Roux 的出色答案外，它还可以帮助安全审计人员确定优先级，并使攻击后的取证变得更容易。
它允许您将安全审核集中在使用更多权限的代码上——您可以将更多时间用于审核需要写入权限的代码而不是需要读取权限的代码，甚至可以将更多时间用于需要删除表权限的代码。
角色分离的另一个好处是它使取证更容易。如果您有角色分离并且可以识别数据库日志中的攻击，您可以缩小可能被利用的代码 - 仅使用与日志中的攻击相关联的角色的代码。
【讨论】：
大多数情况下这是多余的，但大多数情况下您应该使用参数化查询，这些查询无论如何都不容易发生 SQL 注入。
考虑使用存储过程，以及只能调用过程而不能直接运行查询的用户帐户。
如果您需要使用直接查询，并且由于某种原因不能使用参数，那么是的，您应该有一个只能在可能的情况下从数据库中读取的用户帐户。
【讨论】：
您对 SQL 注入的想法似乎来自 Bobby Tables 的那部愚蠢的漫画。
但实际上，仅仅从数据库中读取数据可能比写入数据更具灾难性。
另外，我有一种强烈的感觉，没有人说“这是个好习惯”的好人在现实生活中使用它。比如说，前端（在现实生活中，而不是想象中的生活中）也必须具有写入权限。
你叫错树了。
如果您的代码的某些部分容易发生 sql 注入 - 请更正这些部分。这是唯一明智的解决方案。
【讨论】：