1

We had a "pentest" done on our website - and received the following alert (xyz.com is a placeholder for the real name.

I queried this with the testers, and they say their automated tools found this... so they can't help till we fix it... but I have no idea what they are on about. The website is LAMP based.... we dont even use SQlLite.

Finding listed below:

"On the host xyz.com SQL injection may be possible. The query time is controllable using parameter value [case randomblob(100000) when not null then 1 else 1 end ], which caused the request to take [285] milliseconds, parameter value [case randomblob(1000000) when not null then 1 else 1 end ], which caused the request to take [299] milliseconds, when the original unmodified query with value [20230316] took [53] milliseconds."

Further details here:

The team validated the SQL Injection vulnerability identified by OWASP ZAP using Burpsuite and the query time is controllable using parameter value [case randomblob(100000) when not null then 1 else 1 end ], which caused the requests to have different response times.

Here is the "screenshot" of the vulnerability...

enter image description here

I don't know how to proceed or "fix" this type of issue - as I dont follow what is happening - I see a query passed via a URL - but don't follow how this would translate to injection ?

Any help or pointers would be greatly appreciated ?

0

1 Answer 1

1

tl;dr: I would expect this to be a false positive related to caching (which doesn't require a fix), not an SQLi. But it's definitely something to follow up on with the testers as well as the devs.


A delay here is an indicator for SQL injection, but not necessarily a strong one. If the delay can be reproduced reliably, it's definitely something (application-level DOS might be another candidate to look at).

Indications that it's not an SQLi are:

  • randomblob is not a mysql function, but afaik unique to sqlite. Still, the payload could trigger in a related system that does use sqlite (eg a log server, a caching server, etc).
  • 300ms - 0.3 seconds - isn't that long of a delay. There could be a lot of reasons for that. One would be that the v parameter looks like it's there for caching purposes. By changing the value, a fresh, non-cached version of the file might be fetched / generated, which could explain the delay.
  • their 100.000 payload and their 1.000.000 payloads return about the same delay. With an injection, one would expect 10 times the delay for the second payload.

they say their automated tools found this... so they can't help till we fix it...

They should be able to offer more info (likely depends on the type of test you requested & also how much you paid; low budget tests may not have the resources for in-depth follow-ups).

How I would proceed:

  • check if you can reproduce this. Is there really a delay with the given Request? Or was it a one-time fluke?
  • if you replay the example Request twice (with the exact same parameter), is there a delay both times? Or just the first time? That would strongly indicate that it's because of caching, not because of an injection.
  • if you can't reproduce it, tell the testers. Ask them how many requests they tested this with & ask them to verify again on their end.
  • if it's not a fluke, ask the testers for a better POC. Not a dump of the full DB, but reading out sqlite_version() or similar shouldn't take too long.
  • if they can't do that, but you are sure that it's not a fluke, you'll have to investigate yourself (there's only so much the testers can analyze without access to the source code):
    • How is the your_style.css file returned to the client? Is it just a static file & v used as a cache-buster? Or is it in any way fetched from the DB?
    • Are there other systems related to the file? Is there a log server, a cache server, etc? Do they process the v parameter? And if so, how?
    • play around with the value that causes problems. Are you able to create a delay with a parameter that definitely isn't an SQL injection? That would mean it's not SQLi (maybe application-level DOS, maybe caching, maybe something else).
1
  • thanks for the thoughts.. going to check with both testers + devs.. but you gave me some food for thought. Thanks. Nov 7, 2023 at 9:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .