Day 15 of breaking web applications on purpose.

Yesterday we changed a parameter and modified another user's account.

Today?

We attack something every business cares about:

Money.

Let me ask you something.

What if the price you pay for something online… is controlled by your browser instead of the server?

Because that's exactly what happened here.

Welcome to a Business Logic Vulnerability via IDOR-style parameter manipulation.

🎯 The Setup

The application allows users to purchase tickets.

When a user buys tickets, the request sent to the server looks something like this:

POST /lab/idor/ticket-sales/index.php

Inside the request body we see parameters like:

amount=2 ticket_money=10

Which means:

• Ticket quantity = 2 • Ticket price = 10

So the application trusts the client to send the price.

Pause for a second.

👉 Should the client ever control the price of a purchase?

Absolutely not.

🧠 The First Thought

As a tester, whenever you see a price parameter in a request, you should ask:

What happens if I change it?

So we intercept the purchase request using Burp Suite.

Then we send it to Repeater.

Now we try something interesting.

💣 The Payload

Original request:

amount=2&ticket_money=10

Modified request:

amount=2&ticket_money=5

Then we forward the request.

⚡ The Result

The purchase succeeds.

But this time the system charges half the price.

Which means the application trusted the client-side price value.

No validation.

No server-side verification.

The attacker now controls the cost.

🧠 Why This Works

The server likely performs a calculation like this:

total = amount * ticket_money

But because ticket_money comes from the client, the attacker can manipulate it.

Instead of calculating price server-side, the application blindly accepts the value sent by the browser.

This breaks the most important rule of secure development:

Never trust client-side input for critical business logic.

🧨 Real-World Analogy

Imagine going to a cinema ticket counter.

Instead of the cashier telling you the ticket price…

You write your own price on the receipt.

And the cashier simply accepts it.

That's exactly what happened here.

The system let the customer decide the price.

💥 Real Impact

Business logic flaws like this can cause serious financial damage.

An attacker could:

• Purchase tickets at arbitrary prices • Buy expensive items for extremely low cost • Abuse discount logic • Manipulate payment amounts • Cause financial loss to the platform

In large e-commerce systems, this type of vulnerability can cost companies millions.

🛡️ Proper Fix

Pricing must always be enforced on the server.

Instead of trusting this:

ticket_money=5

The server should calculate price internally:

price = getTicketPrice(ticket_id) total = amount * price

Other best practices include:

• Remove price parameters from client requests • Validate prices against server-side records • Implement integrity checks on purchase requests • Monitor abnormal transactions

Security rule:

The client should never control financial logic.

Ever.

🎯 Day 15 Takeaway

You didn't bypass authentication.

You didn't exploit SQL.

You didn't inject scripts.

You simply changed a number.

And suddenly…

You could buy tickets for half the price.

Sometimes the most dangerous vulnerabilities aren't technical.

They're logical.

Tomorrow we move deeper into server-side file attacks — where attackers control which files the application loads.

And that's where things start getting very interesting.

LESSGOOO 🔥

Precision beats noise. Curiosity breaks systems.