BugBounty.info

Login Bypass

3 min read

Login Bypass

Login endpoints are almost always in scope and almost always have something wrong with them. The bug class ranges from trivial (default creds) to genuinely tricky (logic flaws in multi-step flows). Start here on every target.

Rate Limit Bypass

Most rate limiting is IP-based. That means it's broken by design.

Header rotation - many apps trust forwarded headers from proxies and CDNs without validating them. Cycle through these on every blocked request:

X-Forwarded-For: 1.2.3.4
X-Real-IP: 1.2.3.4
X-Originating-IP: 1.2.3.4
X-Remote-IP: 1.2.3.4
X-Client-IP: 1.2.3.4
CF-Connecting-IP: 1.2.3.4
True-Client-IP: 1.2.3.4

In Burp, use Pitchfork with a list of IPs in column A and passwords in column B. Or use the IP Rotate extension to cycle through AWS API Gateway endpoints - effectively unlimited unique IPs.

Account-based lockouts - if the lockout is on the account, not the IP, distribute your attempts across accounts. If you're testing credential stuffing resilience, use a single password across 100 accounts before an account trips the lockout threshold.

Slow attack - some rate limits are requests-per-minute. One request every 90 seconds often flies under the radar.

Credential Stuffing Vectors

Not about cracking passwords - about testing whether the app has any protection at all:

  • Does the error message differ between "no account" and "wrong password"? That's a valid user enumeration finding on its own.
  • Try admin:admin, admin:password, admin:123456, test:test before anything clever.
  • Check for legacy endpoints - /api/v1/login when the app uses /api/v3/login. Old endpoints often lack modern rate limiting.

Default Credentials

Do this before anything else. It takes 30 seconds and occasionally wins immediately:

StackCreds
Jenkinsadmin:admin
Grafanaadmin:admin
Kibanano auth by default
phpMyAdminroot: (empty)
Tomcat managertomcat:tomcat, admin:admin
Routers/IoTvendor-specific, check cirt.net

Authentication Logic Flaws

These are the juicy ones. Look for multi-step login flows - anything with more than one POST request.

Step skipping - if login is /auth/step1 → /auth/step2 → /auth/complete, try hitting /auth/complete directly after step 1. Some apps only check that step 1 completed, not that step 2 did.

Response manipulation - if step 2 returns {"mfa_required": true}, change it to false in the proxy. See MFA Bypass for more on this.

Parameter pollution - send username=victim&username=attacker and see which one the app uses for authentication vs. which one it logs.

SQL injection in login - still happens. Try ' OR '1'='1 in the username field with any password. Also try admin'-- as the username.

POST /login HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
 
username=admin'--&password=anything

Burp Workflow

  1. Send login request to Intruder
  2. Mark the password field as the payload position
  3. Use Sniper with a short list first (top 20 passwords) to check for rate limiting behavior
  4. Check response length differences - a successful login often has a different response length even if the status code is the same (302 either way)

Graph View

Backlinks