Web Application Penetration Testing Complete Masterclass
🌐 Web Pentest · Both
Beginner
16 modules
2.7h
0 enrolled
From zero-knowledge to professional-grade tester. Every attack explained step-by-step with real payloads, full methodology, beginner mindset guidance, and a complete corporate pentest report at the end.
Instructor
lazyhackers
Curriculum — 5 sections · 16 modules · 2.7h
Cookie Security Flags — Full Audit
Every cookie in the application needs to be audited. Use Burp's response tab or DevTools → Application → Cookies.
| Flag | What to Test | Missing = Risk | Sev |
|---|---|---|---|
| HttpOnly | Run XSS payload → does document.cookie return session cookie? | Session theft via XSS — JS can read the cookie | HIGH |
| Secure | Send request over HTTP (port 80) — is session cookie included? | Cookie sent over cleartext HTTP — network interception | HIGH |
| SameSite=Strict/Lax | Attempt CSRF — does browser send cookie on cross-site POST? | CSRF attacks possible on all state-changing endpoints | MED |
| Expiry | Wait 24+ hours — is session still valid? | Sessions never expire — stolen token valid indefinitely | MED |
| Token Entropy | Collect 20 tokens — analyze with Burp Sequencer | Predictable token — can be guessed or brute-forced | CRIT |
Burp Sequencer — Token Randomness Analysis
# Steps to use Burp Sequencer: # 1. Capture a response that sets a session cookie in Burp proxy # 2. Right-click on the request → Send to Sequencer # 3. Select the cookie value as the token location # 4. Start live capture → collect 10,000+ tokens automatically # 5. Click "Analyze Now" # # Result: "Effective entropy" score # - Above 100 bits = Good (secure randomness) # - Below 64 bits = HIGH finding (token is predictable) # - Below 32 bits = CRITICAL (easily brute-forced) # Manual token analysis — decode base64 encoded tokens echo "dXNlcklkPTEyMzQ7cm9sZT11c2Vy" | base64 -d # Output: userId=1234;role=user ← CRITICAL — tamper this! # Re-encode with admin role echo -n "userId=1;role=admin" | base64 # Use the new value as your session cookie
Session Fixation Attack
# Test procedure: # 1. Visit the app WITHOUT logging in — note your session ID # Cookie: session=PRE_LOGIN_TOKEN_ABC123 # 2. Log in with valid credentials # 3. Check session ID AFTER login — has it changed? # Same token = VULNERABLE (Session Fixation) # New token = Secure (session regenerated on login) # # Attack scenario if vulnerable: # 1. Attacker visits /login — gets session=ATTACKER_KNOWN_VALUE # 2. Attacker sends victim: https://target.com/login?sessionid=ATTACKER_KNOWN_VALUE # 3. Victim logs in using the attacker's known session ID # 4. Attacker is now authenticated as the victim
Session Invalidation Tests
| Test | How to Perform | Expected Secure Behavior |
|---|---|---|
| Logout test | Copy session cookie → click Logout → send request with old cookie in Burp/curl | HTTP 401/403 — old session invalid |
| Password change test | Change password → use old session token in new request | Old session invalidated — must re-login |
| Concurrent session test | Login from Browser A → Login from Browser B — do both sessions stay valid? | Configurable — enterprise apps should allow setting max sessions |
| Token persistence test | Logout → close browser → reopen → visit app — does "Remember me" still auth? | Should have clear expiry — typically 30 days max |