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

时间:2009-08-11 22:02:24

标签: database sql-injection

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

编辑:我理解你在说什么,但如果我没有响应。写其他数据,他们怎么能看到它。带来爬行和dos是有意义的,其他人也是如此,但他们将如何实际看到数据?

7 个答案:

答案 0 :(得分:7)

'); SELECT * FROM Users

是的,您应该将它们锁定到他们实际应该能够看到的数据(表格/视图),特别是如果它是公开的。

答案 1 :(得分:7)

有人可以注入SQL以使授权检查返回等效的true而不是false来访问应该禁止的内容。

或者他们可以将目录表的连接注入其自身20或30次,以便将数据库性能提升到爬行状态。

或者他们可以调用作为 修改数据的其他数据库用户运行的存储过程。

答案 2 :(得分:4)

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

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

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

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

答案 3 :(得分:3)

要非常小心。我假设你已经删除了drop table,alter table,create table和truncate table,对吗?

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

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

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

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

雅各

答案 4 :(得分:1)

我读了这个问题和答案,因为我正在创建一个SQL tutorial website,其中只有一个只允许最终用户运行任何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;

答案 5 :(得分:0)

是的,继续担心SQL注入。恶意SQL语句不只是写入。

想象一下,如果存在Linked Servers,或者编写了查询来访问跨数据库资源。即

SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary;

答案 6 :(得分:0)

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