Web — Name Your Own Price

Category: Web · Difficulty: Easy

Scenario

shop.kashsec-labs.test's checkout page renders a hidden form field to hold the order total, which it submits along with your shipping details when you click "Place Order." You captured the request the page sends for a $249.99 item.

Provided data

POST /api/checkout HTTP/1.1
Host: shop.kashsec-labs.test
Content-Type: application/x-www-form-urlencoded

item_id=771&quantity=1&unit_price=249.99&total=249.99&shipping=standard

The server's response after a successful order:

{"order_id": 9012, "status": "confirmed", "charged": 249.99}

Your task

Notice that unit_price and total are submitted by the browser, as plain form fields — not looked up server-side from a product catalog. Find the flag hidden in what happens when you change them before submitting.

Hint 1

A price is exactly the kind of value that should never be trusted from client input at all — the server should look up the real price for item_id 771 from its own database and compute the total itself, ignoring whatever the client happened to send.

Hint 2

Try resubmitting the exact same request, but with unit_price=0.01 and total=0.01 instead of the real price.

Show full answer

The server accepts the client-submitted price at face value and returns: {"order_id": 9013, "status": "confirmed", "charged": 0.01, "flag": "KASHSEC{cl13nt_s1d3_pr1c1ng_1s_n0_pr1c1ng}"}. This is a classic business logic vulnerability — there's no injection, no broken authentication, nothing that a vulnerability scanner would ever flag. The application is working exactly as coded; the code itself just trusts data (a price) that must always be recomputed server-side from a trusted source, never accepted as client input at all.

The flag

KASHSEC{cl13nt_s1d3_pr1c1ng_1s_n0_pr1c1ng}

Why this matters beyond the CTF

Client-side price manipulation is one of the most common — and most consistently underestimated — real-world e-commerce vulnerability classes, because it requires zero technical sophistication once you know to look for it: intercept a request, change a number, resubmit. Path 15's bug bounty material and Path 11's business-logic coverage both flag this exact pattern as a genuinely high-value, genuinely easy thing to test for in scope, precisely because so many applications still get it wrong. The fix has one shape, always: never trust a price, discount, or total from client input — the server must independently derive it from data it controls.

Bonus round — a sneakier variant

The same checkout flow also accepts a discount_code field. This code is legitimate: LAUNCH10 (10% off), captured from a real promotional banner on the site.

POST /api/checkout HTTP/1.1
Content-Type: application/x-www-form-urlencoded

item_id=771&quantity=1&unit_price=249.99&total=224.99&discount_code=LAUNCH10

Hint

Suppose (unlike the main challenge) this endpoint correctly ignores your submitted unit_price and total entirely, and looks up the real price server-side. It still accepts discount_code as client input, and applies whatever percentage that code maps to. What field remains attacker-controlled that could still cause damage?

Show answer

Even with price properly server-derived, the quantity field is still worth scrutinizing on its own — a negative quantity (quantity=-5) could, on a naively implemented server, produce a negative total, which some payment processors or internal ledger systems might process as a credit

Automated vulnerability scanners are built to recognize known bad patterns — injection syntax, known CVE signatures, malformed input causing errors. A request with a suspiciously low but syntactically perfect price field looks completely normal to a scanner; there's no error, no crash, no telltale signature. Finding business logic bugs requires actually understanding what the application is supposed to enforce, then checking whether it actually does — which is exactly why this category rewards careful human thinking over automated tooling.

Next up → Web — The Coupon That Wouldn't Quit