Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Blind SQL injection with time delays

anon | Last updated: Sep 17, 2020 07:28PM UTC

There are some things I didn't understand about this lab: 1) How can we find out what version of SQL the server is running? Is it just a matter of testing the syntax of each version until one works? 2) The SQL injection cheat sheet says that the time delay syntax for PostgreSQL is SELECT pg_sleep(10). Why does x' SELECT pg_sleep(10)-- not work? 3) I tried using x' pg_sleep(10)-- and it didn't work. Why do we need the concatenation operator ||?

Uthman, PortSwigger Agent | Last updated: Sep 18, 2020 12:50PM UTC

Hi, 1. You can find out further information here. You essentially want to run a query that retrieves the version: https://portswigger.net/web-security/sql-injection/examining-the-database 2. This blog has a great explanation: https://blog.yekki.co.uk/sql-injection/ "x' SELECT pg_sleep(10)--" would not work because the entire TrackingID would be false instead of True. The solution shows TrackingId=x' || pg_sleep(10)-- (the TrackingId is False, whilst pg_sleep(10) is True. You know this based on the observed delay) 3. The operator || is a logical OR. This means that both statements are evaluated but only the True one is executed. In this case, you should observe a delay with the option mentioned in the solution (we know this because TrackingId=x' is False).

Amir | Last updated: Oct 11, 2021 04:51PM UTC

doesn't matter if the trackingID is correct or not adding the following sql query works anyways -> ' || (select pg_sleep)-- I am just still not sure why do we need to concatenate

Amir | Last updated: Oct 11, 2021 04:51PM UTC

doesn't matter if the trackingID is correct or not adding the following sql query works anyways -> ' || (select pg_sleep)-- I am just still not sure why do we need to concatenate

Uthman, PortSwigger Agent | Last updated: Oct 12, 2021 04:26PM UTC

Hi!

It is based on concatenation, as you mentioned, so you can ignore my point because it's incorrect. Apologies for the confusion there.

It looks like it just combines the two SQL 'payloads' into a single string so the single quote is closing the string and concatenating this with the select statement allows that statement to be executed (triggering the time delay). Rana explains this very well in her video here.

Alex | Last updated: Nov 25, 2021 12:30AM UTC

Hi Uthman, Following on from this because I'm curious and also because the video you provided still didn't explain why the concatenation operator ('||') was valid PostgreSQL syntax. It would be easier if we could see the select statement for ourselves so we could confirm once and for all but as far as I can tell the PostgreSQL select statement is something like: select tracking-id from tracking-id_table where tracking-id='<value from trackingid cookie>' When we inject " '|| select pg_sleep(10)-- " into this I believe we get the two select queries concatenated together (unless the "||" also does something else in PostgreSQL): select tracking-id from tracking-id_table where tracking-id='' select pg_sleep(10)-- Ordinarily, having two select keywords in the same query would cause the query to break however in our case its valid for some reason? Unless string concatenation ("||") does something else in PostgreSQL I cant work out why we use it or why the statement succeeds over something like " '; select pg_sleep(10)-- " (ordinarily the use of the semicolon here would terminate the first query, allowing the second select query to run)

Luca | Last updated: Aug 03, 2023 07:53PM UTC

I used the examples provided in the theory (for all DBs) and it didn't work, that's how I ended up on this old thread: '%3b+IF+(1=1)+SELECT+pg_sleep(10)-- Without the IF condition it works though. On top of that, Burp (pro) cannot find this injection. Why and why? :)

Luca | Last updated: Aug 03, 2023 07:56PM UTC

||+IF+(1%3d1) ||+IF+(1=1) ||IF+(1%3d1) ||IF+(1=1) do not seem to work either

Dominyque, PortSwigger Agent | Last updated: Aug 04, 2023 12:38PM UTC

Hi Luca We have just run through the lab, and the given solution works. Have you tried following this? Additionally, when you say that Burp Pro cannot find the injection, does this means you scanned the lab?

Luca | Last updated: Aug 07, 2023 10:38AM UTC

Hi, yes the given solution works. I am wondering why a solution based on the examples in the theory and the chat sheet do not work (see above). Also yes, a scan of the defined insertion point with Burp Pro cannot find this injection, which is a bit worrying as it wouldn't be found in a real test with a similar injection present

Dominyque, PortSwigger Agent | Last updated: Aug 07, 2023 12:37PM UTC

Hi Luca The techniques for triggering a time delay are highly specific to the type of database being used. Burp Professional would not find this injection because it does not check for SQL injections via Postgres time delays. We do have a development ticket to include this in our Scanner at some point.

Luca | Last updated: Aug 07, 2023 06:24PM UTC

thank you. I think I made some confusion with my attempts. I will try again with PostgreSQL specific conditional time delays. It is true that the official solution does not use conditions at all, though.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.