如果我的数据库用户是只读的，为什么我需要担心sql注入？

Question

他们（恶意用户）可以描述表格并获取重要信息吗？如果我将用户锁定到特定表怎么办？我并不是说我想要 sql 注入，但我想知道我们的旧代码很容易受到影响，但 db 用户已被锁定。谢谢。

编辑：我明白你在说什么，但如果我没有其他数据的response.write，他们怎么能看到它。爬行和执行操作是有道理的，其他人也是如此，但他们如何实际看到数据呢？

Answer 1

有人可以注入 SQL 来导致授权检查返回 true 而不是 false 的等效值，从而获得对本应禁止访问的内容的访问权限。

或者，他们可以将目录表的连接注入到自身 20 或 30 次，从而使数据库性能变得极其缓慢。

或者他们可以调用一个以不同数据库用户身份运行的存储过程，会修改数据。

Answer 2

'); SELECT * FROM Users

是的，您应该将它们锁定为仅它们实际上应该能够看到的数据（表/视图），特别是如果它是公开的。

Answer 3

仅当您不介意任意用户读取整个数据库时。例如，这是一个简单的可注入登录序列：

select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text'

if(RowCount > 0) {
     // Logged in
}

我只需使用任何用户名和密码 ' 或 1 = 1 登录即可以该用户身份登录。

Answer 4

要特别小心。我假设您已经删除了 drop table、a​​lter table、create table 和 truncate table，对吗？

基本上，通过良好的 SQL 注入，您应该能够更改依赖于数据库的任何内容。这可能是授权、许可、对外部系统的访问……

您是否曾经将从数据库检索到的数据写入磁盘？在这种情况下，他们可以上传 perl 等可执行文件和 perl 文件，然后执行它们以更好地访问您的盒子。

您还可以通过利用预期特定返回值的情况来确定数据是什么。即如果SQL返回true，则继续执行，如果不是，则停止执行。然后，您可以在 SQL 中使用二分搜索。选择 count(*) 其中 user_password > 'H';如果计数> 0 继续。现在，您可以找到准确的纯文本密码，而无需将其打印在屏幕上。

此外，如果您的应用程序没有针对 SQL 错误进行强化，则可能会出现这样的情况：它们可以在 SQL 或结果的 SQL 中注入错误，并在错误处理程序期间将结果显示在屏幕上。第一个 SQL 语句收集了一个很好的用户名和密码列表。第二条语句尝试在不适合的 SQL 条件中利用它们。如果 SQL 语句显示在这种错误情况下，...

Jacob

Answer 5

我阅读了这个问题和答案，因为我正在使用只读用户创建一个 SQL 教程网站允许最终用户运行任何 SQL。

显然这是有风险的，而且我犯了几个错误。以下是我在前 24 小时内了解到的内容（是的，其他答案涵盖了大部分内容，但这些信息更具可操作性）。

• 不允许访问您的用户表或系统表：

Postgres：

REVOKE ALL ON SCHEMA PG_CATALOG, PUBLIC, INFORMATION_SCHEMA FROM PUBLIC

• 确保您的只读用户只能访问您需要的表
  您想要的架构：

Postgres：

GRANT USAGE ON SCHEMA X TO READ_ONLY_USER;
GRANT SELECT ON ALL TABLES IN SCHEMA X TO READ_ONLY_USER

• 配置数据库以删除长时间运行的查询

Postgres：

Set statement_timeout in the PG config file 
/etc/postgresql/(version)/main/postgresql.conf

• 考虑将敏感信息放入其自己的架构中

Postgres：

 GRANT USAGE ON SCHEMA MY_SCHEMA TO READ_ONLY_USER;

 GRANT SELECT ON ALL TABLES IN SCHEMA MY_SCHEMA TO READ_ONLY_USER;

 ALTER USER READ_ONLY_USER SET SEARCH_PATH TO MY_SCHEMA;

• 采取注意锁定任何存储过程并确保它们不能由只读用户运行

编辑：请注意，通过完全删除对系统表的访问，您将不再允许用户进行诸如cast()之类的调用。因此，您可能需要再次运行此命令以允许访问：

GRANT USAGE ON SCHEMA PG_CATALOG to READ_ONLY_USER;

Answer 6

是的，继续担心SQL注入。 恶意 SQL 语句不仅仅涉及写入。

想象一下，如果存在链接服务器或编写查询来访问跨数据库资源。 IE

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary;

Answer 7

Oracle 存在一个错误，允许您通过调用带有错误参数的公共（但未记录）方法来使实例崩溃。