Target Application: https://github.com/Yavuzlar/VulnLab/tree/main

Day 3 of breaking web applications on purpose.

Yesterday, we stored JavaScript in a database.

Today?

We don't even need the server to mess up.

Welcome to DOM-Based XSS: world where the vulnerability lives entirely in client-side JavaScript.

🎯 The Setup

The application takes values from the URL:

?height=10&base=5

Then JavaScript calculates an area using those values.

Sounds harmless.

Until you realize something important:

The developer directly injected the URL parameter into JavaScript code.

That's where things go sideways.

🧠 Real-Life Analogy

Imagine a calculator app that says:

"Tell me the numbers and I'll compute."

Instead of validating your input, it literally pastes whatever you type directly into its brain.

You don't give it numbers.

You give it instructions.

And it executes them.

That's DOM XSS.

💣 The Payload

Instead of a number, we inject:

1;alert('DOM');//

Now the full URL becomes:

?height=1;alert('DOM');//&base=10

⚡ Why This Works

The vulnerable JavaScript looked conceptually like this:

var height = <?php echo $_GET['height']; ?>;

The developer forgot something critical:

Quotes.

So instead of treating input as a value…

The browser treats it as executable JavaScript.

Your input becomes part of the code.

You break out of the math expression. You inject a new statement. JavaScript runs.

Game over.

💥 What Happens?

The browser executes:

var height = 1; alert('DOM');

And you get a popup.

But in real life, that popup could be:

  • 🍪 Cookie theft
  • 🔓 Session hijacking
  • 🎭 Account takeover
  • 🧾 Data extraction
  • 🔁 Silent redirection to phishing pages

No database involved. No backend error. Just pure client-side logic abuse.

🧨 Why DOM XSS Is Sneaky

  • Security scanners often miss it
  • Server logs show nothing suspicious
  • It lives inside frontend logic
  • It executes instantly when URL loads

It's silent. It's fast and ofc Dangerous!!

None
We'll dig in more tomorrow.