Broken Authentication and Session Attacks

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Authentication is the front door of an application — and session handling is the key you keep using after you’ve walked in. When either is weak, an attacker doesn’t need to break anything clever; they simply become a legitimate user. Page 1.4 gave you the concepts; this page attacks them, exposing exactly where login and session systems fail in the real world.

Part 1: The Problem

Page 1.4 established the machinery: authentication proves who you are, sessions and tokens keep you logged in, and whatever the browser holds is your identity to the server. Every one of those mechanisms can be implemented weakly.

When it is, the consequences are total: an attacker who defeats authentication or steals a session gains a legitimate user’s full access — and because they are that user as far as the system can tell, the intrusion can be near-invisible. This section is the offensive view of identity: how login and session systems are actually broken.

Part 2: Attacking the Password — Brute Force and Credential Stuffing

Passwords are the weakest common authentication factor (1.4), and attackers exploit that directly.

Brute force. Systematically guessing passwords for an account — trying many candidates until one works. Pure brute force (every possible combination) is slow; in practice attackers use a dictionary attack — guessing from a list of likely and common passwords, which is far faster because human-chosen passwords are predictable.

Credential stuffing. The more dangerous modern attack. Enormous lists of real username/password pairs have leaked from past breaches. Because people reuse passwords across sites, an attacker takes credentials leaked from Site A and tries them on Sites B, C, D. They’re not guessing — they’re reusing known-real passwords. This is why password reuse is so dangerous, and why it’s a Phase 1.4 lesson made real here.

   BRUTE FORCE / DICTIONARY        CREDENTIAL STUFFING
   one target account,             many accounts,
   many password guesses           each tried with its
   from a likely-password list     real password leaked
                                   from another site

What makes an app vulnerable to these: no limit on login attempts, no rate-limiting, no account lockout, no MFA, no detection of mass login failures. An app that lets an attacker try unlimited logins as fast as they like is inviting both attacks.

Part 3: Attacking the Session — Hijacking and Fixation

Even with a strong password, the session that login creates is itself a target. If an attacker obtains your session identifier, they skip authentication entirely — they just present your session and the server treats them as you.

Session hijacking — stealing an active session. The attacker obtains a valid session ID/token. Ways this happens:

• XSS (section 2.5) — a script reading the session cookie. (And why HttpOnly matters.)
• Network sniffing — if the session travels over unencrypted HTTP, anyone on the path can read it. (And why HTTPS-only matters.)
• Predictable session IDs — if session IDs are short, sequential, or guessable rather than long and random, an attacker can simply guess a valid one.

Session fixation — forcing a known session on the victim. A subtler attack. Instead of stealing the victim’s session after login, the attacker plants a session ID they already know, gets the victim to log in using it, and — if the app fails to issue a fresh session on login — the attacker’s pre-known ID is now an authenticated session.

   1. Attacker obtains a valid (not-yet-logged-in) session ID.
   2. Attacker tricks the victim into using THAT session ID.
   3. Victim logs in.
   4. If the app DOESN'T issue a NEW session on login,
      the attacker's known ID is now an authenticated session.

The defense is simple and is the lesson: always issue a brand-new session ID upon login.

Part 4: Attacking the Forgotten Door — Password Reset Flows

Here is a place beginners overlook and skilled testers always check: the password reset / “forgot password” flow.

Think about it — the reset flow is, by design, a way to gain access to an account without knowing the password. That’s its whole job. If it’s poorly built, it’s an authentication bypass handed to the attacker. Common weaknesses:

• Weak reset tokens. The reset link contains a token; if that token is predictable, guessable, sequential, or doesn’t expire, an attacker can forge a valid reset link for someone else’s account.
• Reset tokens that don’t expire or can be reused.
• Host-header poisoning — some reset flows build the reset link using a header the attacker can influence, sending the victim’s reset link to the attacker.
• Security questions — “mother’s maiden name,” “first pet” — answers are often public or guessable (OSINT, section 2.1). A weak knowledge factor guarding the reset.
• Username enumeration on the reset page — if “no such user” and “reset sent” produce visibly different responses, the attacker learns which usernames exist (see Part 5).

The principle: the password reset flow must be as strong as the login itself — because it is a login path. Always test it.

Part 5: Information Leaks — Username Enumeration

A smaller but enabling weakness: username enumeration is when an app lets an attacker work out which usernames/emails are registered.

It happens when the app responds differently to a valid vs invalid username:

• Login: “wrong password” (user exists) vs “no such user” (doesn’t) — the difference reveals valid accounts.
• Registration: “email already in use” reveals registered emails.
• Reset: different messages or response timing for valid vs invalid accounts.

Why it matters: enumeration is a force multiplier. Once an attacker has a confirmed list of real usernames, brute force and credential stuffing become far more efficient — they’re no longer wasting guesses on accounts that don’t exist. The defense is consistent responses — the app should reply identically whether or not the account exists (“if that account exists, a reset link has been sent”).

Part 6: The Defenses — A Preview of Phase 4.2

Every weakness above has a corresponding defense, built fully in Phase 4.2. Knowing them now sharpens your testing — you’re really checking for their absence:

If you take one thing from this page as both attacker and defender: MFA changes the math. Most of the attacks above — stolen password, brute force, credential stuffing — are defeated or massively weakened when a second factor is required. It is the highest-leverage fix in authentication security.

📓 Key Terms

🧪 Hands-On Lab

Only on your own lab or deliberately vulnerable practice apps. Brute-forcing or attacking logins on any unauthorized system is a crime.

Task 1 — Brute force a weak login. On a deliberately vulnerable app, use Burp Intruder (section 2.2) with a small wordlist to brute-force a login that has no rate-limiting. Watch responses — a different length or status code reveals the correct password.

Task 2 — Feel the rate-limiting difference. If your practice app has a login with lockout/rate-limiting and one without, attack both. Experience directly how a simple control defeats the attack from Task 1.

Task 3 — Hijack a session. In a controlled lab scenario, take a valid session cookie and place it in a different browser. Observe that you’re now “logged in” as that user — no password involved. The session is the identity.

Task 4 — Test a password reset flow. On a deliberately vulnerable app, examine the reset flow. Inspect the reset token — is it predictable, sequential, or guessable? Does it expire? Does it get reused? Practice the testing checklist from Part 4.

Task 5 — Hunt username enumeration. On a practice app’s login and registration pages, submit a known-valid and a known-invalid username. Compare the responses — message wording, status code, even response timing. Any difference is enumeration.

Task 6 — Map attacks to defenses. For every weakness you found in Tasks 1–5, write the defense from Part 6 that would stop it. You’re building the bridge to Phase 4.2.

⚠️ Common Mistakes

• Only testing the main login form. The reset flow, registration, “remember me,” and API authentication are all authentication paths — and often the weakest. Test them all.
• Brute-forcing real/unauthorized accounts. Login attacks against systems you don’t own are unambiguous crimes. Lab and authorized targets only.
• Underestimating session attacks. A perfect password is irrelevant if the session can be stolen or fixed. The session is the identity after login.
• Overlooking username enumeration as “minor.” On its own it’s small; as a force multiplier for brute force and stuffing, it’s significant. Report it.
• Forgetting that MFA is the big lever. Many of these attacks collapse against MFA. Both as a tester (note its absence) and a defender (recommend it), treat MFA as central.

✅ Recap & What’s Next

• When authentication or session handling is weak, an attacker simply becomes a legitimate user — no clever exploit required.
• Passwords fall to brute force and credential stuffing; sessions fall to hijacking and fixation; the password reset flow is an often-weak alternate login path; and username enumeration multiplies all of it.
• Every weakness has a defense (Phase 4.2) — rate-limiting, new sessions on login, strong reset tokens, consistent responses — and MFA is the single highest-value control.

Next (2.7): Authentication asks “who are you?” Authorization asks “what may you do?” Next we attack authorization — broken access control and IDOR, consistently among the most common and serious bugs in real applications.