不 ，您可能将 SQL 注入与数据注入混淆了；只读表不会阻止 SQL 注入，最多只能做一点限制其影响。

SQL 注入仅仅意味着注入 SQL 代码的能力。虽然只读表可能会限制向表中注入数据的能力，但它们不会影响以下能力：

• 如果不允许，则从其他数据库或表中读取
• 从系统表中读取或运行其他难以禁止的系统查询
• 编写将执行 DoS 的过于复杂的查询
• 使用 DNS 泄露数据
• 访问本地文件（例如，Oracle 中的 utl_file）
• 访问数据库服务器的网络（例如，Oracle 中的 utl_http）
• 通过DB 函数缓冲区溢出在服务器上执行任意代码
• 请参阅Oracle 数据库中的高级 SQL 注入，了解您需要担心的所有事情（并意识到其他数据库也有它们的等价物）

如果你

基本上只是想将他们输入的内容添加到select声明中。

那么您明确允许攻击者尝试其中任何一种。

现在，您当然可以做一些事情来限制这一点。您可以禁止使用引号和 SQL 语句分隔符。您可以禁止任何不属于[A-Za-z0-9"=]（或与您的数据库等效）的输入。但是如果你开始走这条路，你最好正确地编写你的应用程序：公开一个更丰富的查询界面，在其中提供要检查的键，然后对用户输入的任何值执行正确的引用。

最小权限（仅在一个表上的选择能力），与数据库的只读连接是否可以防止所有注入攻击？

SQL 注入是攻击者修改现有语句以导致意外操作的一种方式。这些操作可能是对数据库的更改或系统上的代码执行，也可能是简单地返回不应该返回的数据，或者通过执行资源密集型操作来拒绝服务。

将查询限制为仅对特定表进行选择可能会限制影响，但您仍然可能会导致拒绝服务。根据查询结果的使用位置，您可能会通过返回意外结果来更改应用程序行为。

不，微不足道的例子

EXEC ('SELECT COUNT(*) 
       FROM table 
       WHERE UserName =''''' + @UserName + ''''' AND Password = '''''+@Password+'''''')

将@Password 设置为 a' OR 1=1;--

你的密码被绕过了

一点也不。SQL 注入缺陷不在 SQL 服务器，而是在 Web 应用程序级别，因此如果 Web 应用程序对 SQL 注入敏感，那么无论对数据库的访问级别如何，它都将保持敏感。

但是，您提到的最小权限原则使得，即使有人设法在 Web 应用程序上利用 SQL 注入，他也只能获得对数据库内容的读取权限，他将无法更改数据库内容或结构.