On 2016-11-25 15:29, Lester Caine lester@... [firebird-support]
wrote:

> On 25/11/16 13:56, Mark Rotteveel mark@...
> [firebird-support] wrote:
>> On 2016-11-25 12:40, Lester Caine lester@...
>> [firebird-support]
>> wrote:
>>> > Nothing to do with Firebird but can anybody explain why the numbers in
>>> > 'SELECT FIRST 102121121121212 SKIP 3574239239242420' would be a problem
>>> > in MySQL or is it some other vulnerability the original sQL injection
>>> > was trying to hit. I know I need to add limit checks in the code which
>>> > reprocessed the SQL but it quite happily 'white screens' the vast
>>> > majority of MySQL injection attempts so I'm just need to make sure
>>> > there
>>> > is nothing that WOULD affect Firebird adversely.
>> That number is too big to fit in an int, could explain the problem
>>
>> BTW: You might want to look for other solutions if you need to skip
>> and
>> fetch that many records, it is not really efficient ;)
>
> You are missing the point Mark ... This SQL has come about from a PHP
> SQL injection attack. I don't need it to 'work'. I was trying to get a
> handle on the vulnerability they were trying to exploit on MySQL incase
> the results may be a problem. The ACTUAL SQL is only spanning a few
> hundred pages and is handled via parameters. This SQL was the result of
> manually added SQL in the raw fields.

Ah, ok, that wasn't really clear to me.

It might just be an attempt to a denial of service (eg because skipping
the first 3574239239242420 is/could be expensive if the table actually
contains that many row), or it is used to get an idea of the size of
your table (see previous one), or maybe it can be used for
fingerprinting because it triggers an error on specific MySQL versions,
or it used to gain access to data from queries appended (eg using a
union).

There might be more scenarios, but without specifics of the exploit that
is probably impossible to tell or guess; nor would it be possible to
assess if that would be something that could affect Firebird.

Mark