EXERCISE 2 — When to use time-based, and a MySQL payload
=========================================================

WHEN YOU MUST USE TIME-BASED INSTEAD OF BOOLEAN-BASED:
  - Boolean-based blind requires a DETECTABLE DIFFERENCE in the RESPONSE
    between a true and a false condition (text, length, status, etc.).
  - Sometimes there is NO such difference: the app returns the SAME page
    regardless of the injected condition's truth — e.g. a request that always
    returns "OK" / a fixed 200 with identical body, or where the injectable
    query's result doesn't affect the visible response at all.
  - With no content oracle, you MANUFACTURE one: make the database take a
    measurable amount of TIME when the condition is true, and read the answer
    from the RESPONSE DURATION. That's time-based blind. Use it whenever
    boolean's content signal is absent or unreliable.

MYSQL TIME-BASED PAYLOAD — is the 1st char of admin's password 'a'?
  ' AND IF(
      SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1) = 'a',
      SLEEP(5),
      0
   )--

  Equivalent using ASCII:
  ' AND IF(ASCII(SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)) = 97, SLEEP(5), 0)--

HOW THE ANSWER IS READ:
  - IF(cond, SLEEP(5), 0): when the condition is TRUE, the DB evaluates
    SLEEP(5) and pauses ~5 seconds before responding; when FALSE, it evaluates
    0 and responds immediately.
  - So you MEASURE the response time:
      * response takes ~5s longer  => condition TRUE  => the char IS 'a'
      * response returns quickly    => condition FALSE => the char is NOT 'a'
  - As with boolean, you'd normally BINARY-SEARCH the ASCII value
    (IF(ASCII(...) > midpoint, SLEEP(5), 0)) rather than test each letter, then
    advance to the next character position.

ONE REASON TIME-BASED IS NOISIER / LESS RELIABLE:
  - The signal is wall-clock TIME, which is affected by factors unrelated to
    the condition: NETWORK JITTER/LATENCY, server LOAD, concurrent queries,
    proxies, and connection setup. A "fast" response under heavy load might
    take longer than your threshold, or a "slept" response might be masked by
    timeouts — producing false readings.
  - Mitigations testers use: pick a delay clearly above normal variance (e.g.
    SLEEP(5) or 10), REPEAT each measurement and use statistics/medians, and
    compare against a baseline request. (sqlmap does this automatically.) Even
    so, time-based is slower and more error-prone than boolean — but it works
    where boolean can't.

ONE-LINE TAKEAWAY:
  Use time-based when there's no content difference to read; make the DB
  SLEEP on "true" and read the answer from the response delay — robust against
  blank responses, but noisier due to timing variance.