A fully manual security assessment of three broken-authentication bugs — no scanners, just a proxy-backed browser and raw HTTP evidence, mapped end-to-end to CWE and OWASP.
⚠️ Educational / authorized testing only. Everything below targets a local, deliberately vulnerable training application, not a live system. Never run these techniques against anything you don't own or don't have explicit written authorization to test.
Automated scanners are great at pattern-matching known vulnerability classes. They're much weaker at authentication flaws that look completely legitimate at the HTTP level — a 200, a 401, a token — and only become a bug once you understand how the value was generated. This walkthrough is a fully manual assessment of three such bugs in a deliberately vulnerable login system, captured start to finish with nothing but a proxy-backed browser and a network tab.
The bugs
| # | Bug | CWE | OWASP |
|---|---|---|---|
| 1 |
POST /login has no rate limit, delay, or lockout |
CWE-307 | A07:2021 – Identification and Authentication Failures |
| 2 | Session tokens are sequential integers, not random | CWE-330 | A07:2021 |
| 3 | Password-reset token is md5(username) — deterministic, not random or single-use |
CWE-640 | A07:2021 |
Phase 1 — No brute-force protection
Three wrong passwords for admin, back to back, then the real one. All four POST /login requests return instantly — no 429, no CAPTCHA, no increasing delay. Filtering the network tab down to login shows the whole sequence sitting there in plain sight: nothing on the server side ever notices the repetition.
That's the entire proof for CWE-307. A real attacker isn't limited to four guesses — they're limited by whatever rate their network connection allows, because the server places no limit of its own.
Phase 2 — Predictable session tokens
The login endpoint hands out tokens from a shared, incrementing counter — regardless of which account is logging in. alice gets 1001. bob gets 1002. That's already suspicious, but the real proof of impact is this: clear your cookies, open a private window, and request /whoami?session=1001 with zero credentials. The server hands back alice's full identity, because "knowing a number" and "being alice" are treated as equivalent.
Phase 3 — A reset token that isn't a secret
/reset-token?username=alice returns a 32-character hex string that looks random — until you request it again and get the exact same value back. It's not a secret; it's md5("alice"), a pure function of public data. Anyone who knows a username can compute their "reset token" offline, with no server interaction and no account access at all.
From evidence to finding
Each bug was routed from the network capture into a manual finding — evidence field populated with the actual request/response pairs, CWE and OWASP mapping attached, and a concrete fix:
- Finding A (Medium) — add per-account and per-IP throttling with exponential backoff or lockout, plus a CAPTCHA after repeated failures.
- Finding B (High) — issue tokens from a cryptographically secure random source (128+ bits), never a counter.
- Finding C (High) — generate a random, single-use, time-limited reset token, stored server-side and delivered only to the account's verified contact method.
Takeaway
None of this required exploit tooling — it required patience, a network tab, and the discipline to capture evidence before writing a single conclusion. Scanners are excellent at known-signature bugs; deterministic secrets and predictable state are exactly the class of finding that still needs a human reading raw traffic.
What's the last "boring" auth bug your team caught that a scanner missed? Curious to hear how others are covering this gap.
Try it yourself → https://github.com/sendwavehub/scan-target-demo-apps
Windows Store https://apps.microsoft.com/detail/9pj0j7bk1m27?hl=en-US
Web Site https://Sendwavehub.tech/en/apps/ai-security-studio-4
