Authorization disclaimer. This walkthrough is limited to the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Test only systems you own or are explicitly authorized to assess.

Overview

The authentication control can be manipulated by carefully ordering login attempts around its IP-based blocking behavior.

The Academy brief names victim `carlos`, supplies `wiener:peter`, and describes an IP-based brute-force control with flawed reset logic.
The Academy brief names victim `carlos`, supplies `wiener:peter`, and describes an IP-based brute-force control with flawed reset logic.

Lab objective/setup

The supplied credentials, candidate lists, email client, and exploit server are used only inside this Academy instance to reproduce the authentication-flow evidence shown below.

What I observed

Three consecutive failures trigger a one-minute IP block, but any successful login from the same client resets the shared counter. A session macro logs in as Wiener before each Carlos guess, allowing Intruder to reach 1234567 without retaining the block.

After repeated failures, the login page states that too many incorrect attempts were made and imposes a one-minute wait.
After repeated failures, the login page states that too many incorrect attempts were made and imposes a one-minute wait.
A successful login opens Wiener's My Account page, demonstrating the event that resets the IP failure counter.
A successful login opens Wiener's My Account page, demonstrating the event that resets the IP failure counter.

Why it is vulnerable

Rate limiting that counts requests without binding failures to both account and client identity can be reset or bypassed.

Walkthrough in the authorized PortSwigger lab

Record a successful Wiener login as a Burp macro and attach it to a session-handling rule that runs before each Intruder request. This successful control login clears the shared IP failure count before the next Carlos attempt. Test Carlos’s candidate passwords and open the sole 302 result.

For repeated `POST /login` attempts, the Burp macro editor records a successful `POST /login` request that can run before each password guess.
For repeated `POST /login` attempts, the Burp macro editor records a successful `POST /login` request that can run before each password guess.
The session-handling rule is enabled with the login macro as its action, interleaving a successful Wiener login with attack requests.
The session-handling rule is enabled with the login macro as its action, interleaving a successful Wiener login with attack requests.
The Intruder results contain a `302` response for payload `1234567`, while surrounding Carlos password guesses return `200`.
The Intruder results contain a `302` response for payload `1234567`, while surrounding Carlos password guesses return `200`.

Verification

The final capture shows the Academy marking the broken brute-force protection, ip block exercise as solved after the documented request sequence. No testing was performed outside the isolated lab.

The broken IP-block lab shows its solved banner above Carlos's My Account page after login with Intruder's password result.
The broken IP-block lab shows its solved banner above Carlos's My Account page after login with Intruder's password result.

Impact and defensive lesson

Authentication controls must bind identity, challenge state, reset tokens, and retry counters to server-side transactions. Return uniform failures, rate-limit by both account and trusted client signals, and use random revocable persistent-session tokens rather than credential-derived values.

References