Attacking web applications
A web test is not clicking buttons until something breaks. It is walking every feature, every parameter and every role on purpose, watching what the server does, and proving each flaw with evidence a developer can reproduce. This lesson shows how a tester finds access control, injection and business-logic flaws in the lab Partner app, and captures them. The fixes live in the application-security course; here the angle is how you find and demonstrate the gap.
By the end you can
- Use an intercepting proxy to read, change and replay the requests a browser makes
- Walk an application the OWASP WSTG way: map every feature, parameter and role before you test
- Find an access-control gap by comparing what two authorised test accounts can reach, and prove an IDOR with the second account
- Spot injection, cross-site scripting and business-logic flaws by how the app reflects, stores and trusts input
- Capture evidence that reproduces, write impact in business terms, and know what your test looks like in the defender's logs
The everyday picture
Think of a building safety inspector walking a new block of flats. She does not kick doors to see what gives. She carries a checklist: every fire door, every stairwell, every electrical panel, every flat. For each one she asks the same questions, writes down what she finds, and photographs it with the floor and door number in shot. She does not fix the loose wire herself. Her job is to prove it is loose, say what could happen if it stays that way, and hand the builder a report precise enough to act on.
A web application test is the same job. You do not poke at random. You list every feature, every input and every role, and ask the same questions of each. When something is wrong, you capture it so someone else can see exactly what you saw, you say what it would cost the business, and you leave the fixing to the team. The skill that separates a tester from someone mashing buttons is the method and the evidence, not the cleverness of any single trick.
The intercepting proxy: your main instrument
A browser hides the conversation it has with a server. You see a page; you do not see the dozens of requests behind it, the headers, the hidden fields, the ids in each URL. The tester's main tool makes that conversation visible. An intercepting proxy sits between the browser and the server. Every request the browser sends, and every response that comes back, passes through it where you can read it.
It does three things, and understanding them at the level of "what it shows you" is enough to start:
- Read. It records every request and response: the method and URL, the headers, the session cookie or token, the body. This is where you see the invoice id in the path, the
shopIdin a hidden field, the sort value in a query string. - Modify. It can pause a request so you change a value before it reaches the server, or edit a response before the browser renders it. Changing one id and letting the request go is how you test whether the server checks ownership.
- Replay. It can resend a captured request again and again with small changes, so you do not have to click through the app each time. You can also replay one account's request while swapping in a second account's session.
You stay strictly inside the scope and rules you agreed in Ethics, law and scoping, pointed at the practice Partner app only. The proxy is not an attack by itself; it is a microscope. Everything that follows is about what you look for once you can see the traffic.
Quick check
A developer says the Partner app is safe because the app only ever sends a shop its own invoice ids, so a shop can never ask for another shop's invoice. Why does an intercepting proxy change that claim?
What the app's screens offer is a user interface choice, not a control. Once the tester can edit and replay requests, any id can be sent regardless of what the app displays. So the only thing that keeps a shop out of another shop's invoice is a check on the server, which is exactly what you test for.