> For the complete documentation index, see [llms.txt](https://notes.dollarboysushil.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.dollarboysushil.com/web-application-pentest/authentication-attacks.md). # Authentication Attacks ## Authentication Attacks - Overview ### 1. Authentication vs Authorization * **Authentication** = proving *who* you are (login). * **Authorization** = proving *what you're allowed to do* once logged in. * Attacks here target the first check - getting into an account without legitimately proving ownership. Three factor types (MFA = combining 2+ of these): * Something you **know** - password, PIN * Something you **have** - phone, hardware token, email inbox * Something you **are** - fingerprint, behavior ### 2. Root causes of every auth bug Basically always one of these two: 1. **Weak brute-force protection** - mechanism is fine, but nothing stops unlimited guessing 2. **Broken logic** - a flaw lets you skip/bypass a step entirely, password strength irrelevant ### 3. Why it's high severity * Low-priv account compromised → still leaks data + opens extra attack surface * Admin/system account compromised → full app control, possible pivot to internal infra * A one-line logic bug here often outranks a "deeper" bug elsewhere ### 4. Password-based login attacks #### Brute-forcing * **Password guessing** - works with no rate limit + weak password * **Username guessing** - useful once enumeration confirms real accounts * **Credential stuffing** - reuse leaked username/password pairs from other breaches #### Username enumeration - check these for valid vs invalid username differences * [ ] Status code (200 vs 404, redirect vs error) * [ ] Error message wording ("invalid username" vs "invalid password") * [ ] Response length (even a few bytes off) * [ ] Response timing (valid username = server hashes password = slower response) **Why it matters:** confirms real accounts → focus password brute-force only on those. #### Flaws in brute-force protection * **Account locking bypass** - lock resets the moment *one correct* credential pair is submitted → smuggle unlimited guesses alongside one known-good pair in a batch * **IP-based rate limit bypass** - limit is per-IP, not per-account → rotate IPs or spoof `X-Forwarded-For` * **Multiple credentials per request** - endpoint accepts an array of username/password pairs in one request, processes each separately server-side, but front-end limiter only counts it as one request → unlimited attempts disguised as a single request **Rule of thumb:** if the protection can be reset or split by changing the shape/origin of a request, it's broken. #### HTTP Basic authentication * No built-in lockout/rate limiting - browser resends creds freely, Burp Intruder works fine on the header * Base64 ≠ encryption - trivially reversible, only safe over HTTPS * Sent on every request → more exposure to logs, caching, referrer leaks ### 5. Multi-factor authentication (MFA) attacks #### Outright bypass * Server sets "logged in" state/cookie **before** 2FA check completes * Try navigating directly to a post-login page after step 1 - sometimes you're just already in #### Flawed 2FA verification logic * Verification step identifies *which account's* code to check using a client-controlled value (cookie/hidden param), not the server-side session * Fix the value to point at another username, submit *your own* valid code → verify into their account #### Brute-forcing 2FA codes * 4-6 digit codes are brute-forceable if the verify endpoint has no rate limit * Check: does the code invalidate after one failed try? * Check: does the rate limit reset the same way account-lock bugs do (one correct guess in a batch of wrong ones)? ### 6. Other authentication mechanisms #### "Remember me" / persistent login * Cookie should be random + server-validated * Red flag: cookie is just username, or a weakly-obfuscated version of it → brute-force or reconstruct offline * Check client-side JS for the generation algorithm - it might just tell you how to forge one #### Password reset * **Emails the actual current password** → red flag, means passwords aren't hashed properly server-side * **Reset via URL/token** - check: * [ ] Token long + random, or guessable? * [ ] Invalidated after use? * [ ] Bound server-side to the account it was issued for? * **Password reset poisoning** - reset link is built from a client-controlled header (`Host`, `X-Forwarded-Host`) → poison it, victim clicks the link, their reset token lands in your logs #### Changing passwords * Should require current password before setting new one * If that check is skippable, or the endpoint doesn't verify the request targets the logged-in user's own account → account takeover ### 7. OAuth (third-party auth) * Own topic, own attack surface: implicit vs auth-code flow, `redirect_uri` validation, `state` param handling * Not covered here - separate notes ### 8. Quick checklist before testing any login flow * [ ] Does the response differ at all for valid vs invalid usernames? * [ ] Is rate limiting tied to account, or just IP/request? * [ ] Can the limit/lockout be reset by an attacker-controlled trick (batch requests, new IP)? * [ ] Is every step of a multi-step login enforced server-side, or can a later step be reached directly? * [ ] Is any step (2FA target, reset scope, password-change target) identified by a client-controlled value instead of the session? * [ ] Are tokens (reset links, remember-me cookies) random enough + invalidated after use? Most labs = pick one of these questions, find the exact spot where the answer is "no."