【问题标题】:If my database user is read only, why do I need to worry about sql injection?如果我的数据库用户是只读的,为什么我需要担心 sql 注入?
【发布时间】:2010-11-18 19:00:20
【问题描述】:

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

编辑:我明白你在说什么,但如果我没有 response.write 其他数据,他们怎么能看到它。抓取并确实有意义,其他人也是如此,但他们将如何实际查看数据?

【问题讨论】:

    标签: database sql-injection


    【解决方案1】:
    '); SELECT * FROM Users
    

    是的,您应该将它们锁定为他们应该能够看到的数据(表/视图),尤其是当它是公开面对的时候。

    【讨论】:

    【解决方案2】:

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

    或者他们可以将目录表的连接注入自身 20 或 30 次,以使数据库性能下降。

    或者他们可以调用以不同数据库用户身份运行的存储过程,该用户确实修改数据。

    【讨论】:

      【解决方案3】:

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

      select * from UserTable where userID = 'txtUserName.Text' and password = 'txtPassword.Text'
      
      if(RowCount > 0) {
           // Logged in
      }
      

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

      【讨论】:

        【解决方案4】:

        要非常小心。我假设您已经删除了 drop table、a​​lter table、create table 和 truncate table,对吧?

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

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

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

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

        雅各布

        【讨论】:

        • 我们所拥有的一些东西是防止数据输入的类型。所以我们可能有一个日期,如果他们没有输入一个日期,它就会被拒绝,但我仍然想知道这是否可以被利用。
        • 这取决于代码。如果你发现一个日期之后被 SQL 注入攻击,它仍然被认为是一个日期吗? “12/01/1999'); drop table users”将是一个有趣的尝试日期。确保您不仅确认您有一个日期,而且您还确认您没有其他任何东西。
        【解决方案5】:

        是的,继续担心 SQL 注入。恶意 SQL 语句不仅仅与写入有关。

        还可以想象一下,如果有链接服务器或者查询是为了访问跨数据库资源而编写的。即

        SELECT * from someServer.somePayrollDB.dbo.EmployeeSalary;
        

        【讨论】:

          【解决方案6】:

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

          【讨论】:

            【解决方案7】:

            我阅读了这个问题和答案,因为我正在创建一个带有只读用户的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;
            

            【讨论】:

            • 嗯,正确的答案只有一个词:是的。可以说,写得更多是没有意义的。我想很多阅读这个问题的人都处于拥有一个需要锁定只读访问权限的用户的数据库的位置。这就是我添加这个答案的原因。
            猜你喜欢
            • 1970-01-01
            • 2018-10-24
            • 2010-10-11
            • 1970-01-01
            • 1970-01-01
            • 2015-09-24
            • 2019-11-18
            • 2018-10-22
            • 2013-12-07
            相关资源
            最近更新 更多