Sailor Security

Authentication Attack – Bypass Brute-Force Protection

  1. Scenario
  2. Weak Brute-Force Mechanism
    1. X-Forwarded-For
  3. Application’s Auth Logic
  4. User enumeration – Intruder
  5. Password Enumeration – Intruder
  6. Mitigation
  7. References

Scenario

As is common in many applications, after three consecutive failed login attempts, the account is temporarily locked for 30 seconds. If incorrect attempts continue, the lockout period is progressively extended.

This method is to bypass weak brute-force attack protection mechanism with altering the HTTP header for IP-based rate limiting.

After third brute-force attempt – account is locked.

Weak Brute-Force Mechanism

Some web applications implement IP-based rate limiting to prevent brute-force attacks by restricting the number of failed login attempts per IP address. However, if the application relies on X-Forwarded-For for logging or blocking IPs, attacker can manipulate it in several ways.

X-Forwarded-For

X-Forwarded-For (XFF) is an HTTP header used to identify the original IP address of a client that connects to a web server through a proxy or load balancer.

X-Forwarded-For: 192.168.1.100  (1st attempt)
X-Forwarded-For: 192.168.1.101  (2nd attempt)
X-Forwarded-For: 192.168.1.102  (3rd attempt)

When using X-Forwarded-For: #, the value # is just a placeholder (not a real IP), which can sometimes trick poorly configured security mechanisms.

X-Forwarded-For: 1,2,3,4,5,6...

Application’s Auth Logic

Application does not explicitly gives errors such “invalid user name” rather a generic response. Instead of relying on error – response time help.

Testing for invalid user – response time is 99 millisecond

Testing for valid user – response time is 273 millisecond

User enumeration – Intruder

Look for response received – even though the response size is a little bigger than initial benchmark, still it can be assumed it is the valid user.

Password Enumeration – Intruder

Valid user is found in previous step, app01. Now change the parameter to password and load your wordlist – start the the attack.

The only response code with 302 is the user: app01 and password abc123.

Combining with Proxy Chains
It is also possible to use proxy services (e.g., TOR, VPNs, or open proxies) while modifying X-Forwarded-For headers, making detection even harder.

Mitigation

To prevent X-Forwarded-For abuse:

  • Verify and Sanitize Inputs: Ensure X-Forwarded-For contains a valid IP format.
  • Use the Right IP Source: If behind a reverse proxy (e.g., Cloudflare, AWS ALB), use its designated headers like CF-Connecting-IP or X-Real-IP.
  • Implement Stronger Rate-Limiting: Combine IP-based rate limiting with session, device, or behavioral analysis.
  • Log and Monitor Suspicious Headers: Detect patterns of unusual X-Forwarded-For usage.

References

PortSwigger – Web Security Academy:

https://portswigger.net/web-security