In intercepting-proxies you sat a proxy between your browser and the server and learned to pause, read, modify, and replay a single request. That proved the client controls every byte of the request - but it was manual, one request at a time.
Real testing often needs the same request sent hundreds or thousands of times, with one value changed on each try: a different password, a different coupon code, a different numeric id. By hand that is hopeless. This lesson is where interception grows into automated payload iteration.
The two standard tools are Burp Suite's Intruder and OWASP ZAP's Fuzzer. Both take a captured request, let you mark a position inside it, and substitute a whole list of payloads into that position automatically while recording how the server answered each one.
Whether you call it fuzzing (feeding many varied inputs to probe behavior) or brute-forcing (trying every candidate until one works), the engine is identical: iterate a request, then read the responses.
In this lesson you will:
- Inspect a preloaded NovaCart login request in the custom Attack Simulator.
- Identify the marked payload position and explain why it represents a Sniper attack.
- Choose a small simulated wordlist and run the in-page iteration model.
- Triage the simulated results by HTTP status code and response length to find the one successful guess - the
200among the401s.
Estimated time: 10 to 15 minutes.
Prerequisites: authentication-login for the login request shape and captcha-rate-limiting-anti-automation for rate-limit and lockout context. The captured request and all interactive controls are already in the custom page.
A word on scope first: the custom simulator sends no network traffic. Real automated iteration is active and high-volume - it sends a burst of requests and can lock accounts or trip defenses. Run a real tool only against a target you are explicitly authorized to test, exactly as established in hacking-ethics-and-authorization.
When you are ready, send the Continue signal.