Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.
Overview
The unchanged page hides a measurable server-side effect: postgreSQL payloads using pgsleep(10), including ‘; SELECT pgsleep(10)–, delay the response by ten seconds. The ten-second pause is the evidence that the cookie value reaches PostgreSQL as executable syntax.
Lab objective/setup
Exercise Blind SQL injection with time delays through the endpoint and input recorded in the lab note. PostgreSQL payloads using pg_sleep(10), including '; SELECT pg_sleep(10)--, delay the response by ten seconds.
What I observed
PostgreSQL payloads using pg_sleep(10), including '; SELECT pg_sleep(10)--, delay the response by ten seconds.
Why it is vulnerable
PostgreSQL payloads using pg_sleep(10), including '; SELECT pg_sleep(10)--, delay the response by ten seconds. The application passes that value into the security-sensitive operation without the context-specific validation or encoding needed to prevent this result.
Walkthrough in the authorized PortSwigger lab
Record the normal TrackingId response time, inject the PostgreSQL statement terminator and pg_sleep(10), and repeat enough times to separate the deliberate delay from network variance. No body difference is required for this lab.
Verification
The lab is confirmed when postgreSQL payloads using pg_sleep(10), including '; SELECT pg_sleep(10)--, delay the response by ten seconds. The captured result and the Academy solved state provide the verification; an ordinary status code alone does not.
Impact and defensive lesson
Time-based SQL injection remains exploitable when errors and query output are suppressed. Bind cookie values as data, disallow stacked statements, cap query duration, and investigate repeated sleep-function requests.