Skip to main content

🗂️PortSwigger Lab Writeup: Broken Brute-Force Protection, IP Block

PortSwigger lab banner: Broken Brute-Force Protection, IP Block


🎯 Objective

The objective of this lab is to exploit an authentication weakness where the app implements brute-force protection incorrectly - successful login disables or resets rate limiting. The goal is to brute-force the target username's password and log in to the account.

  • Lab URL: https://portswigger.net/web-security/authentication/password-based/lab-broken-bruteforce-protection-ip-block
  • Category: Authentication
  • Difficulty: Practitioner

🧪 Exploitation Steps

🕵️Step 1: Observe the Website

  • Firstly open the lab URL in your browser, and observe what it is about and how it works. Lab homepage screenshot showing site layout
    Login page screenshot for the vulnerable application
  • At first glance, the website seems to be a blogging website with a login page. In the lab description, it is mentioned that we need to bruteforce the password of user - carlos and log in to account.

📝Step 2: Test Rate-limiting

  • Open the BurpSuite, capture a POST request to /login and send it to Repeater Tab by Ctrl + R Burp Repeater capture of POST /login request
  • Now send the request with wrong credentials like carlos:12345678 or carlos:carlos to observe how rate limiting is implemented and when. Repeater failed login responses showing rate limiting
  • Hence after 3 failed login requests, rate limiting is implemented. let's try to bypass this by adding a HTTP header - X-Forwarded-For. Attempt to bypass rate limiting using X-Forwarded-For header in Repeater
  • Hence, this trick did not worked so we try another method which is trying to login with correct credentials which may reset the rate limiting
  • Therefore send a login request with correct credentials - wiener:peter Successful login with valid credentials to reset rate limiting
  • Now, this request was successful and we were able to log in.
  • Now again send wrong credentials to see if rate limiting is reset or not. Repeater test after successful login showing reset rate limiting
  • Hence, we successfully bypassed the rate limiting by logging in with correct credentials. This means that in the process of bruteforce, we need to also send correct login credentials simultaneously to bypass rate limiting.

🚀Step 3: Bruteforce Password

  • Now prepare a list of username with our target carlos and username wiener simultaneously for bruteforce.
  • Also prepare a list of passwords with a known password peter and possible passwords from Portswigger - Candiate Passwords
  • Prepare both the list in a order that pair correct credentials and are automatically send for resetting rate limiting.
  • I used the below python script for preparing this list.
    with open('pass.txt', 'r') as f:
    with open('pass2.txt' ,'w') as f1:
    with open('user.txt' , 'w') as f2:
    for j in f:
    f1.write("peter\n")
    f2.write("wiener\n")
    f1.write(j)
    f2.write("carlos\n")
  • In the above python script, pass.txt file contains the possible passwords from Portswigger.
  • Now send the login request to Intruder Tab by Ctrl + I
  • Add the marker on username value as well as password value and set the attack type to Pitchfork. Intruder request prepared with Pitchfork markers on username and password
  • In Payloads section, set the 1 - Payload type to Simple list and paste the generated usernames (user.txt) from the python script.
    Intruder payloads: generated usernames (user.txt) for reset strategy
  • Set the 2 - Payload type to Simple list and paste generate passwords (pass2.txt) from the python script.
    Intruder payloads: generated passwords (pass2.txt) for reset strategy
  • After configuring everything, start the attack. Intruder attack results showing 302 Found for target username carlos
  • In all the payloads, you will see a 302 Found response for our target username carlos
  • Hence, we successfully bruteforced the carlos password.

🧑‍💼Step 4: Log in as carlos

  • Open the login page and copy paste the credentials extracted to log in. Login page filled with discovered carlos credentials
  • And Finally, the Lab is solved. Lab solved confirmation screen

🧠 Conclusion

  • This lab demonstrates broken brute-force protection: the application resets the rate-limit counter on a successful login, effectively disabling the IP/account block.
  • Exploit: by alternating a valid login (wiener:peter) with attempts for the target (carlos:<candidate>) the attacker continuously resets throttling and brute-forces the account.
  • Fix: do not reset rate limits on successful auth — enforce per-user and per-IP throttling, and add CAPTCHA or exponential backoff for repeated failures.