Skip to main content

Authentication bypass

Lab: DVWA
Scenario: Authentication weaknesses (Brute Force focus)
Difficulty: Intermediate
Estimated Time: 35 minutes

Learning Objectives​

By the end of this scenario, you will be able to:

  • Demonstrate online password guessing against a login form when rate limiting and account lockout are absent or weak.
  • Explain how credential stuffing and brute force differ (reuse vs guessing).
  • Name controls that raise cost for attackers: lockout, MFA, CAPTCHA, monitoring.

DVWA’s primary module for this lesson is Vulnerabilities → Brute Force. (Other apps use “auth bypass” to mean SQLi in login or broken session—always map the actual mechanism.)

Setup​

Prerequisites​

  • DVWA at CSN Labs
  • Security Low unless comparing levels
  • Optional: Burp Suite (Intruder) or hydra for automated attempts—only in the lab

Initial configuration​

  1. Log into DVWA as an administrator to set security to Low (you need app access before testing the vulnerable login).
  2. Log out of DVWA if the Brute Force module uses a separate login form (follow your lab’s layout—some hosts expose Brute Force while you remain logged into DVWA shell).

Scenario story​

A login form accepts username and password over HTTP(S). With no throttling, an attacker can try thousands of passwords for a known username. Your job is to prove the weakness with a small, ethical attempt list and to document defenses.

Step-by-step walkthrough​

Step 1: Locate the Brute Force page​

Navigate to Vulnerabilities → Brute Force.

Observe:

  • Username and password fields
  • Whether a CSRF token or hidden field appears (varies by DVWA version and level)

Step 2: Manual baseline​

Try a wrong password intentionally. Note:

  • HTTP status and response length (DevTools Network tab).
  • Whether error text differs between “bad password” and “unknown user” (account enumeration risk).

Step 3: Controlled guessing (Low security)​

At Low, DVWA typically allows rapid repeated logins. Try a short list of common passwords against a test user your lab defines (e.g. admin / password, admin / admin)—stay inside lab rules.

Expected: Eventually a 302 or welcome response indicates success; Network tab shows different length or redirect vs failures.

What to record: Request URL, method (GET/POST), parameters (username, password, etc.).

Step 4: Optional — automate ethically in the lab​

With Burp: capture login request → send to Intruder → set payload positions on password → use a small wordlist. Compare responses by length or status to find success.

Why length? Failed logins often return the same HTML size; success may differ.

Step 5: Optional second module — Weak Session IDs​

If your curriculum includes Vulnerabilities → Weak Session IDs, open it at Low and refresh several times. Some levels show predictable PHPSESSID values—an attacker who can guess sessions may hijack users. Document whether IDs look incremental or random.

Why this works​

Brute force succeeds when:

  • Guessable or default credentials exist.
  • No progressive delays, lockout, or MFA.
  • Monitoring does not block or alert on high failure rates.

Bypass is not magic—it is missing rate control plus weak secrets.

Defender notes​

How to detect​

  • Failed login spikes per IP, user, or tenant.
  • Success after long runs of failures.
  • Geographic or impossible travel signals for logins.

How to prevent​

  1. Rate limiting and temporary lockout (balance with DoS risk to legit users).
  2. MFA for sensitive accounts.
  3. Strong password policy + breach password checks (not alone, but helpful).
  4. CAPTCHA or proof-of-work only when needed (often after N failures).
  5. Consistent error messages to reduce account enumeration.

Try these variations​

Easy​

  • Compare Low vs Medium security: does DVWA introduce CSRF tokens or delays?

Medium​

  • Test password in login form for SQL injection only if the module is designed for it—do not assume every login is injectable.

Hard​

  • Map session cookie flags: HttpOnly, Secure, SameSite in Application → Cookies.

Evidence checklist​

  • One failed login request summary (method, params).
  • Evidence of successful login after repeated attempts or clear doc of rate limit stopping you at higher levels.
  • Two defensive controls you would enable in production.

Next steps​