Lab: Web App Exploitation

This lab brings the e-commerce attack-surface map to life. You will run a real, deliberately-vulnerable shop on your own machine and exploit three of its weaknesses by hand — the same classes Trinetra flags in the capstone.

Rules of engagement

Practice only against the local Juice Shop instance you run yourself (or an authorized training range). These techniques against any system you do not own are illegal under India’s IT Act and equivalents elsewhere. Bind the app to localhost so it is never exposed to your network.

Setup

On Windows?

The Docker command below is identical — just install Docker Desktop first. See Windows Setup for the full picture.

OWASP Juice Shop is a modern web app built intentionally insecure for training. Run it locally:

# Docker (simplest) — bound to localhost only
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

# …or with Node.js
# npm install -g juice-shop  (then run it)  — see owasp.org/www-project-juice-shop

Open http://localhost:3000. Keep your browser developer tools open (F12) on the Network tab — half the lesson is watching the requests the site makes.

The exercise

1. Recon — read before you touch.

   Browse the shop. In the Network tab, notice the calls to /rest/... and /api/.... A web app is a frontend talking to an API talking to a database — the very chain on the map. Predict where it might trust input it shouldn’t.

2. SQL injection — log in without a password (map pin #2).

   Open the Login page. In the Email field enter:

   ' OR 1=1;--

   Put anything in the password field and submit. You’re logged in as the first user (the admin). Why: the app built its query by gluing your text into SQL, so OR 1=1 made the condition always true and -- commented out the password check. The database couldn’t tell data from command.

3. Broken access control — read another basket (map pin #4).

   While logged in, open your basket and watch the request: GET /rest/basket/{id}. Change the {id} to a different number and replay it (in the browser or with curl). You can view a basket that isn’t yours. Why: the server returned the record without checking that you own it (IDOR).

4. Cross-site scripting — run script in the page (map pin #3).

   In the product search box, enter:

   <iframe src="javascript:alert(`xss`)">

   The page executes your input as code. Why: the app reflected your text into the page without sanitizing it — so an attacker could plant script that steals other shoppers’ sessions.

What you just proved

Three different doors, one root cause repeated: the app trusted input it should have treated as hostile — in a query, in an object reference, in the page. That single idea explains most web vulnerabilities.

How each is defended

• SQL injection → use parameterized queries (the data can never be parsed as command); least-privilege database accounts; a WAF as backstop.
• Broken access control → check ownership on every request server-side; never trust an id from the client.
• XSS → escape/encode all output, sanitize rich text, and set a Content-Security-Policy; mark session cookies HttpOnly.

Debrief

• Each exploit maps to a pin on the e-commerce map — go back and re-read pins 2, 3, and 4 now that you’ve done them.
• Notice you never needed special tools — just a browser and an understanding of trust. That’s the attacker’s real advantage: knowing what the developer assumed.
• Next, the Trinetra capstone flips you to defender: find issues like these in source code and ship the fix as a pull request.