You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Web Application Security Testing Guide: Session Management, Authentication & Authorization
PART 1: SESSION MANAGEMENT
Overview
Session Management is the process by which a web application maintains state and identity for authenticated users across multiple HTTP requests. Since HTTP is stateless, sessions rely on tokens (cookies, URL parameters, or custom headers) to associate a user with their previous interactions.
Token binding (to IP, User-Agent, or other fingerprint)
Logout functionality (server-side invalidation)
Session fixation resistance
PART 2: AUTHENTICATION & AUTHORIZATION
2.1 Authentication
Definition: The process of verifying the identity of a user, device, or system. Common authentication factors include:
Something you know (password, PIN)
Something you have (phone, hardware token)
Something you are (biometrics: fingerprint, face)
2.1.1 Basic Server Configuration
Testing the fundamental web server settings that impact authentication security.
#
Test Item
Detailed Explanation
Testing Method
1
default banner
The server's default HTTP response header (e.g., Server: Apache/2.4.41 (Ubuntu)) or welcome page that may reveal software name and exact version numbers. Attackers use this to find version-specific exploits.
Send HEAD / HTTP/1.1 or use curl -I https://target.com
2
options enabled
Unnecessary or dangerous HTTP methods left enabled: PUT (upload files), DELETE (remove files), TRACE (XST attacks), CONNECT (proxy tunneling), OPTIONS (method enumeration).
Use OPTIONS / HTTP/1.1 or nmap --script http-methods
3
default error pages
Stock error pages (404 Not Found, 500 Internal Server Error, 403 Forbidden) that may disclose internal paths (e.g., /var/www/html/), database error snippets, or stack traces.
Request non-existent pages, trigger SQL errors, cause 500 errors
4
manual & browser
Combine manual testing (raw HTTP requests via netcat or telnet) with browser-based testing (Developer Tools → Network tab) to observe differences between client-side and server-side behavior.
Browser DevTools + nc target.com 80
2.1.2 Analyze Request and Response from App
Inspecting the actual HTTP traffic between browser and server.
#
Test Item
Detailed Explanation
Testing Method
5
manual
Read raw HTTP requests and responses character-by-character. Look for hidden headers, unusual encoding, cache directives, and security headers missing.
Use curl -v, nc, or Burp Repeater
6
browser
Use browser Developer Tools (F12) → Network tab. Observe live requests, cookies set, redirect chains, and JavaScript-triggered requests.
Chrome/Edge DevTools, Firefox Developer Tools
7
nct (NetCat)
NetCat (nc) allows crafting raw TCP packets to bypass browser restrictions, test protocol edge cases, and send malformed requests that browsers won't allow.
`echo -e "GET / HTTP/1.1\nHost: target.com\n\n"
2.1.3 Other Pages and Dirs on the Server
Discovering hidden or unlinked content on the web server.
#
Test Item
Detailed Explanation
Testing Method
8
http-dir-enum
HTTP directory enumeration technique using dot-dot-slash (../) traversal, tilde (~) for user directories, and common backup extensions (.bak, .old, .swp).
Manually try GET /../../etc/passwd
9
burp
Burp Suite Professional features: Content Discovery (passive + active), Engagement Tools → Discover Content, and Intruder for brute force directory lists.
Burp Suite → Target → Site map → Engage → Discover content
10
zap
OWASP ZAP features: Forced Browse (directory brute force), Spider (crawling), and AJAX Spider for JavaScript-heavy apps.
ZAP → Quick Start → Automated Scan
11
dirbuster
OWASP DirBuster (Java GUI tool) uses wordlists to brute force directories and files. Supports recursive brute force and multiple threads.
DirBuster with directory-list-2.3-medium.txt
12
nikto
Nikto web server scanner checks for over 6,700 potentially dangerous files/programs, outdated server versions, and misconfigurations.
nikto -h https://target.com
2.1.4 Any Directory Listings Present
#
Test Item
Detailed Explanation
Testing Method
13
manual
Directory listing occurs when a web server shows a list of files in a directory instead of an index file (index.html, index.php). This exposes all files in that directory to anyone.
Visit /images/, /backup/, /uploads/, /assets/, /files/ and look for file lists
Example of vulnerable response:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><body><h1>Index of /backup</h1><ul><li><ahref="database.sql">database.sql</a></li><li><ahref="config.old">config.old</a></li></ul></body></html>
2.1.5 Verbose Error Responses Enabled
#
Test Item
Detailed Explanation
Testing Method
14
browser
Verbose errors reveal full file paths, SQL queries, function names, line numbers, and even code snippets. Trigger errors by: empty fields, very long inputs, special characters, SQL syntax, malformed JSON/XML.
Use Burp Repeater to systematically modify parameters and observe error differences. Burp Scanner automatically detects information disclosure via error messages.
ZAP's Fuzzer can send thousands of payloads and flag responses containing common error patterns (e.g., SQL syntax, Stack trace, Warning:, Fatal error).
HTTP TRACE method echoes back the exact request received by the server. Combined with XSS, this enables Cross-Site Tracing (XST) – stealing HttpOnly cookies that JavaScript cannot normally access. Modern browsers block TRACE, but internal tools or old APIs may still allow it.
Send TRACE / HTTP/1.1 and check if response echoes your request headers
Test request:
TRACE / HTTP/1.1Host: target.comX-Custom-Header: test
Vulnerable response (echoes back the headers):
HTTP/1.1 200 OKX-Custom-Header: test
2.1.8 Application
#
Test Item
Detailed Explanation
Testing Method
19
application
General application behavior analysis: How does the app handle state? Are session tokens regenerated after login? Does logout properly destroy sessions? Are there multiple authentication paths (SSO, OAuth, SAML)?
Map all application workflows: login → browse → logout → back button
Cryptographic cipher suites that are known to be vulnerable: Export ciphers (40/56-bit keys – FREAK attack), NULL ciphers (no encryption), RC4 (biases), DES/3DES (Sweet32 attack), CBC mode (BEAST, Lucky13).
TLS renegotiation allows client and server to re-establish cryptographic parameters within an existing connection. Insecure renegotiation (CVE-2009-3555) allows prefix injection attacks – attacker can prepend their own data to a legitimate user's request.
BEAST (Browser Exploit Against SSL/TLS) attack (2011) targets TLS 1.0 with CBC (Cipher Block Chaining) mode ciphers. Attacker can decrypt session cookies by injecting known plaintext and observing ciphertext changes. Mitigation: TLS 1.1+ or using RC4 (now also weak).
SSL/TLS certificate where the current date is after the notAfter field. Browsers show security warnings, but some applications (especially internal tools, IoT devices, or misconfigured APIs) may still accept expired certificates, allowing MITM attacks.
Certificate signed by the organization itself, not by a trusted Certificate Authority (CA). Browsers show "Your connection is not private" warnings. Users who bypass the warning are vulnerable to man-in-the-middle attacks. Acceptable only for internal development/testing.
Certificate that applies to all subdomains of a domain: *.example.com covers mail.example.com, admin.example.com, api.example.com, and even fake.example.com if DNS resolves. Risk: Compromise of one subdomain allows impersonation of all subdomains.
Check Subject Alternative Name (SAN) field: `openssl s_client -connect target.com:443
Placeholder representing the actual target application URL. Replace with the specific domain, subdomain, or IP address under test. Always test both http:// and https:// versions separately.
Identifying the exact web server software and version beyond what the Server header reveals. Uses: header order (Apache vs Nginx), default error page content, custom 404 pages, cookie naming conventions (PHPSESSID, JSESSIONID), default file extensions (.asp vs .php), and timing behavior.
Netcraft (https://sitereport.netcraft.com) provides free detailed reports: web server uptime, hosting history, SSL certificate chain, DNS records, domain registrar, subdomains found, and technology changes over time. Extremely useful for historical reconnaissance.
Real or internal IP addresses leaked in HTTP headers or responses. Common leak sources:X-Forwarded-For (original client IP), X-Real-IP, Via (proxy IP), True-Client-IP, CF-Connecting-IP (Cloudflare), error pages with [client 192.168.1.100], debug headers (X-Served-By, X-Backend).
Collect all response headers, search for IP patterns (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}), check for private ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x)
2.1.22 Burp Headers
#
Test Item
Detailed Explanation
Testing Method
33
burp_headers
Using Burp Suite's HTTP history to systematically analyze all request and response headers. Look for missing security headers: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options (clickjacking), X-Content-Type-Options (MIME sniffing), Referrer-Policy. Also check for custom headers that may reveal internal systems.
Burp → Proxy → HTTP History → Select any request → Inspector tab → Review all response headers
2.1.23 Is Proxy Present?
#
Test Item
Detailed Explanation
Testing Method
34
is proxy present?
Detect whether a reverse proxy (Cloudflare, Akamai, AWS CloudFront, Fastly, Nginx proxy) or forward proxy is sitting between tester and origin server. Detection methods: Different responses to IP vs domain, Via header, X-Cache header, mismatched SSL certificate (Cloudflare), specific error pages, cookie injection (__cfduid for Cloudflare). Affects caching, IP spoofing, header injection, and WAF bypass.
Compare curl -I https://target.com vs curl -I https://target.com --resolve target.com:443:ORIGIN_IP, check for cf-* headers (Cloudflare), akamai-* headers
2.1.24 Manual
#
Test Item
Detailed Explanation
Testing Method
35
manual
Always perform manual verification of every automated finding. Automated tools produce false positives (e.g., reporting a vulnerability that doesn't exist) and false negatives (missing real issues). Manual testing provides context, business logic understanding, and confirmation of exploitability.
For each automated finding, manually craft a proof-of-concept to confirm
2.1.25 Analyze robots.txt
#
Test Item
Detailed Explanation
Testing Method
36
manual
View /robots.txt directly in browser or via curl. This file tells search engines which paths to not crawl. However, attackers read it to find hidden or sensitive directories (/admin, /backup, /private, /dev). Many sites mistakenly block sensitive paths only via robots.txt, not via authentication.
curl https://target.com/robots.txt
37
firebug plugin
Firebug was a legacy Firefox developer tool (discontinued). Modern equivalent: Firefox Developer Tools (F12) → Network tab, or Chrome DevTools → Network tab. Use to observe requests for robots.txt and any dynamically generated disallow rules.
Identify every login form on the application: primary login page, modal/dialog logins, iframe logins, single sign-on (SSO) redirects, OAuth login buttons, API login endpoints (/api/login, /auth/token), and administrative logins. Each form may have different validation, rate limiting, and vulnerability profile.
Search HTML for <form action="...login...">, look for action pointing to login handlers, check JavaScript for dynamic login creation, spider the entire application
2.1.27 Registration Forms
#
Test Item
Detailed Explanation
Testing Method
39
registration forms
User registration forms that create new accounts. Test for: user enumeration (different responses for used vs available email), weak email validation (test@test passes), overposting (submitting extra parameters like role=admin), SQL injection in username/email fields, XSS in display name, and CAPTCHA bypass.
Submit registration with existing email, try adding &role=admin to POST body, inject ' OR '1'='1 in username field
2.1.28 Password Recovery Forms
#
Test Item
Detailed Explanation
Testing Method
40
password recovery forms
"Forgot password" or "Reset password" forms – often the weakest part of authentication. Test for: user enumeration (existing vs non-existing user messages), email/SMS flooding (no rate limits), token predictability (sequential or timestamp-based), token leakage (in URL or Referer header), IDOR (changing user_id parameter), and host header injection (reset email sent to attacker-controlled domain).
Submit recovery request, intercept token, check if token is base64-encoded username, check if token appears in logs/Referer
2.1.29 Oracle Padding
#
Test Item
Detailed Explanation
Testing Method
41
Oracle Padding
Padding oracle attack – decrypts ciphertext without knowing the key by feeding modified ciphertexts to the application and observing which inputs cause padding errors (like "Bad padding" vs "Invalid ciphertext"). Classic in ASP.NET (ScriptResource.axd, WebResource.axd), but also affects custom cryptography. Can lead to full session token decryption and arbitrary ciphertext manipulation.
Use padbuster tool: padbuster https://target.com encrypted_token 8 -cookies auth=encrypted_token, or Burp extension "Padding Oracle"
2.1.30 Identify Technologies Used
#
Test Item
Detailed Explanation
Testing Method
42
wappalyzer plugin
Wappalyzer browser extension (Chrome/Firefox) detects over 1,500 technologies: frontend frameworks (React, Angular, Vue), backend languages (PHP, Python, Ruby, Node.js), CMS (WordPress, Drupal, Joomla), databases (MySQL, MongoDB), analytics, CDN, and JavaScript libraries. Provides instant fingerprinting without sending any traffic (uses browser-detected resources).
Install Wappalyzer → Visit target → Click extension icon to see full technology list
2.1.31 Identify GETs
#
Test Item
Detailed Explanation
Testing Method
43
Identify GETs
Document every endpoint that uses the HTTP GET method. GET requests should be idempotent (no side effects) and should never contain sensitive data (passwords, session tokens, credit cards) in the URL because URLs are logged (browser history, server logs, proxy logs, Referer headers). GET parameters are also visible in browser address bar.
Burp → Target → Site map → Filter by method = GET, export to CSV, review each endpoint
2.1.32 Identify POSTs
#
Test Item
Detailed Explanation
Testing Method
44
Identify POSTs
Document every endpoint that uses the HTTP POST method. POST is used for state-changing operations (login, registration, password change, payment, data submission) and can send parameters in the request body (not visible in URL). However, POST bodies can still be intercepted and modified.
Burp → Target → Site map → Filter by method = POST, review each endpoint and its parameters
2.1.33 Identify Parameters in GETs and POSTs
#
Test Item
Detailed Explanation
Testing Method
45
Identify parameters in GETs and POSTs
Extract and document every parameter name used in both GET (URL query string) and POST (body: application/x-www-form-urlencoded, multipart/form-data, or application/json). Build a parameter inventory for fuzzing. Common parameter names: id, user, username, email, password, role, action, cmd, page, file, path, return, next, redirect, token, csrf, price, quantity.
Burp → Target → Site map → Right-click → Engagement tools → Find parameters, or manually review each request in HTTP History
2.1.34 Check If Actual Objects, SessionIDs Are Passed in GET Requests
#
Test Item
Detailed Explanation
Testing Method
46
Check if actual objects, sessionIDs are passed in GET requests
Critical security flaw: Session IDs in URLs (e.g., https://target.com/profile?PHPSESSID=abc123 or ?sessionid=xyz789). This exposes the session token in: browser history (any user on same machine), server access logs, proxy logs, Referer headers (when clicking external links), and shared links. Also check for database record IDs (?order_id=1001, ?invoice=2024001) that may be enumerable.
Look for ?id=, ?sid=, ?PHPSESSID=, ?JSESSIONID=, ?session=, ?token=, ?order=, ?invoice= in address bar during normal browsing
2.1.35 Replace the Methods and Headers
#
Test Item
Detailed Explanation
Testing Method
47
Replace the methods and headers
Modify HTTP methods and headers to bypass access controls or trigger unexpected behavior. Method swapping: Change GET to POST, POST to GET, GET to PUT, POST to DELETE. Header manipulation: Change Referer, User-Agent, Origin, X-Requested-With, Content-Type, X-Forwarded-For, Host. Some applications only validate certain methods or headers client-side.
Burp Repeater → Change method line → Send. Change Referer: https://target.com to Referer: https://evil.com. Change User-Agent to curl/7.68.0 to mimic bot.
2.1.36 Check If the Application Accepts the Request
#
Test Item
Detailed Explanation
Testing Method
48
check if the application accepts the request
After modifying methods or headers, observe the server's response. Acceptance indicators:200 OK, 302 Found (redirect), 201 Created, or any non-error status. Rejection indicators:405 Method Not Allowed (method blocked), 403 Forbidden (authorization failed), 400 Bad Request (malformed), 500 Internal Server Error (unexpected). If method swapping works (e.g., a POST endpoint accepts GET), that's a vulnerability.
After each modification in Burp Repeater, compare response status and body with original request
2.1.37 Search Boxes
#
Test Item
Detailed Explanation
Testing Method
49
Search boxes
Search input fields are high-risk for injection attacks because they interact with databases (SQL, NoSQL), search engines (Elasticsearch, Solr), and file systems. Test for: SQL injection (' OR '1'='1), NoSQL injection ({'$ne': ''}), XSS (<script>alert(1)</script>), XXE (if XML search payloads), command injection (; ls -la), and path traversal (../../etc/passwd).
Enter each payload type, observe errors, response time differences, and output reflection
2.1.38 Login Fields
#
Test Item
Detailed Explanation
Testing Method
50
login fields
Username and password input fields. Test for: SQL injection (authentication bypass: admin' -- as username, any password), NoSQL injection ({'$ne': null} as JSON in login), user enumeration (different error messages for existing vs non-existing users), brute force (no rate limiting), password field autocomplete (saved passwords in browser), and password field length limits (truncation).
For SQLi bypass: username: admin' --password: anything. For enumeration: compare response for admin vs nonexistentuser123.
2.1.39 Register Fields
#
Test Item
Detailed Explanation
Testing Method
51
register fields
Registration form inputs: username, email, password, confirm password, and sometimes additional fields (full name, phone, address). Test for: overposting (add &role=admin to POST body), weak email validation (test@test passes), username injection (admin already exists → enumeration), password mismatch bypass (send password=pass1&confirm_password=pass1 but manipulate), XSS in display name (saved XSS), SQL injection in any field.
Burp Repeater → Add extra parameter &is_admin=1. Try registering " onmouseover=alert(1) x=" as username.
2.1.40 Payment Processing
#
Test Item
Detailed Explanation
Testing Method
52
payment processing
Payment forms (credit card number, expiration, CVV, billing address, amount, quantity). Test for: price/quantity manipulation (change amount=0.01, quantity=-1, price=0), IDOR (change order_id=123 to 124 to see another user's order), insecure redirects after payment (return_url=https://evil.com), lack of CSRF protection (attacker can charge victim's card), discount code abuse (reuse codes, negative discounts), integer overflow (very large quantity → integer overflow to low total).
Modify amount parameter in Burp before final submission. Try negative quantity. Change order_id in confirmation page URL.
2.1.41 Client-Side Validation
#
Test Item
Detailed Explanation
Testing Method
53
client-side validation
Validation performed only in JavaScript (browser) with no server-side equivalent. Examples: Max length on input fields, email format check, required field check, password complexity rules. How to bypass: Intercept request with Burp, disable JavaScript in browser (Settings → Disable JavaScript), or directly send raw request with modified parameters bypassing all client-side checks. Client-side validation is for user experience only – never for security.
2.1.42 Identify Critical Components and Possible Ways They Can Be Subverted
#
Test Item
Detailed Explanation
Testing Method
54
identify critical components
Pinpoint high-value targets within the application: admin panels, user profile pages, password reset functions, payment gateways, file uploaders, API endpoints (especially /api/admin, /api/internal), user impersonation features, database backup endpoints, and configuration pages.
55
possible ways they can be subverted
For each critical component, identify attack vectors: IDOR (change user ID), SQL injection (retrieve all data), XSS (steal admin session), CSRF (perform actions as logged-in user), path traversal (read arbitrary files), insecure deserialization (RCE), SSRF (access internal networks), privilege escalation (change role=admin parameter), forced browsing (access hidden functions).
Map each component to OWASP Top 10 attack categories. For each attack type, try a basic payload and observe behavior.
2.1.43 Identify Hidden Fields and Their Purpose
#
Test Item
Detailed Explanation
Testing Method
56
identify hidden fields
Find all <input type="hidden"> fields in HTML forms. These are invisible to users but submitted with the form. Attackers can see and modify them using browser dev tools or Burp.
57
their purpose
Determine what each hidden field controls. Common purposes: user role (<input type="hidden" name="role" value="user">), user ID (<input type="hidden" name="user_id" value="1001">), product price (<input type="hidden" name="price" value="49.99">), CSRF token (<input type="hidden" name="csrf_token" value="random">), redirect URL (<input type="hidden" name="return_url" value="/profile">), session state, or discount code.
View page source (Ctrl+U), search for type="hidden". For each, modify value in Burp and observe effect (e.g., change role=user to role=admin).
2.1.44 Pass Through
#
Test Item
Detailed Explanation
Testing Method
58
pass through
Check if hidden fields are echoed back in responses without server-side validation. If the server simply passes through whatever value was submitted, it indicates lack of integrity checking. Example: hidden field product_id=100 is submitted as product_id=200, and the server processes 200 without verifying it's a valid product ID or that the user owns it.
Change hidden field value in Burp to an unexpected value (e.g., another user's ID, negative price, or a string). Submit. Check if server accepts and reflects the changed value in the response.
2.1.45 User Enumeration
#
Test Item
Detailed Explanation
Testing Method
59
user enumeration
Ability to determine whether a specific username, email, or user ID exists in the system. Common leakage points: Login form ("Invalid password" vs "User not found"), registration form ("Email already registered"), password recovery ("Reset email sent" vs "No account found"), password reset token endpoint (different status codes), API responses (different JSON fields), response time differences (existing user takes longer because it hashes password).
Submit a list of known (admin, root, test) and random (randomstring123) usernames. Compare response messages, status codes, response times, and response lengths.
2.1.46 Guessing Username
#
Test Item
Detailed Explanation
Testing Method
60
guessing username
Attempt to discover valid usernames by trying common default or predictable usernames. Common lists:admin, root, administrator, test, user, guest, support, helpdesk, backup, sysadmin, webmaster, postmaster, info, sales, marketing, ceo, hr, it, dev, api, service, automation, batch. Also try email patterns: firstname@company.com, first.last@company.com.
Burp Intruder → Payload list of common usernames → Observe differences in response (message, length, status code, time).
2.1.47 Password Length
#
Test Item
Detailed Explanation
Testing Method
61
length
Determine minimum and maximum password length. Minimum too short (e.g., 4 characters) allows easy brute force. Maximum too short (e.g., 8 characters) limits entropy. Maximum too long (e.g., 255 characters) may cause denial of service or hash truncation issues. No maximum could lead to buffer overflow or denial of service. Also check if password is truncated silently (e.g., first 20 characters only).
Try passwords of varying lengths: 1 char, 2, 4, 8, 12, 16, 20, 32, 64, 128, 255, 256, 512, 1024. Observe if rejected or accepted. Check if password=12345678 and password=12345678extra both work (truncation).
2.1.48 Password Complexity
#
Test Item
Detailed Explanation
Testing Method
62
complexity
Rules for password character types: uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), special characters (!@#$%^&*). Too strict (must have all 4 types, exactly 8-12 chars) reduces usable password space. Too weak (only lowercase letters allowed) is easily brute forced. Common bad rule: requires alternating character types (predictable). Also check if password cannot contain username or dictionary words.
Try password, Password, Password1, Password1!, Password123!, P@ssw0rd. Observe which are accepted. Document exact requirements.
2.1.49 Password Expiration
#
Test Item
Detailed Explanation
Testing Method
63
expiration
Passwords expire after a set number of days (e.g., 30, 60, 90, 180 days). After expiration, user is forced to change password on next login. No expiration means compromised passwords remain valid indefinitely. Too short expiration (e.g., 7 days) frustrates users and may lead to weak passwords written down. Too long expiration (e.g., 365 days) leaves old passwords vulnerable.
Check account after known period. Look for password age in account settings. Read documentation. Force password change by manipulating date in client (some apps check client-side).
2.1.50 Password History
#
Test Item
Detailed Explanation
Testing Method
64
history
Number of previous passwords remembered and prevented from reuse. No history allows user to rotate between same 2 passwords. Good practice: remembers last 5-10 passwords. Overly strict: remembers all passwords ever used (prevents legitimate password cycling).
After password change, try to change back to old password immediately. Try to cycle through multiple old passwords. Keep changing password and see when old password becomes allowed again.
2.1.51 Default Passwords
#
Test Item
Detailed Explanation
Testing Method
65
default passwords
Factory or vendor default credentials left unchanged. Common defaults:admin/admin, admin/password, root/toor, root/root, user/user, administrator/administrator, test/test, guest/guest, admin/123456, admin/password123. Also check for default credentials in documentation of any third-party software used (WordPress: admin/password, Tomcat: admin/admin, Jenkins: admin/admin, router: admin/admin).
Try all common default credential pairs. Check /default.html, /readme.html, /docs/ for default credential documentation. Search "default credentials [software name]".
Document each step. Intercept and analyze every request/response. Look for logic flaws at each boundary.
2.1.53 Forgot Password Methodology
#
Test Item
Detailed Explanation
Testing Method
67
forgot password methodology
Specific implementation of password recovery. Security questions (mother's maiden name, pet's name – often guessable or discoverable via social media) – weak. Email link (common, secure if token is random and one-time). SMS code (vulnerable to SIM swapping, SS7 attacks). Backup codes (good if stored securely). In-app notification (requires another authenticated device). In-person verification (most secure but impractical).
Identify which method is used. For security questions, test if answers can be guessed from public data. For email/SMS, test token predictability and expiration.
2.1.54 Is Password Sent in Clear Text or Not
#
Test Item
Detailed Explanation
Testing Method
68
is password sent in clear text or not
Cleartext transmission: Password visible in HTTP request body or URL. Happens when using HTTP (not HTTPS), or HTTPS with misconfigured redirect (HTTP → HTTPS but initial request is cleartext), or password sent in URL query string even over HTTPS (still logged in browser history and server logs). Encrypted transmission: HTTPS with valid TLS, password in POST body (not URL), and no logging of plaintext.
Use Burp Proxy to inspect login request. Check if password= parameter value is readable. Check browser address bar for ?password=. Check for mixed content (HTTP resources on HTTPS page).
2.1.55 How Is Password Sent – Email or Reset URL
#
Test Item
Detailed Explanation
Testing Method
69
email or reset url
Sending password via email (e.g., "Your password is: MyPassword123") – extremely insecure. Email is not encrypted by default, stored on multiple servers, and password is exposed in plaintext. Sending reset URL (e.g., "Click here to reset: https://target.com/reset?token=abc123") – more secure, but token must be random, single-use, and expire quickly.
Trigger password recovery. Check if email contains your existing password (bad) or a reset link (better). If reset link, check if token is predictable (timestamp, base64 of username).
2.1.56 Is It Generated by the App
#
Test Item
Detailed Explanation
Testing Method
70
is it generated by the app
Server-generated temporary passwords – application creates a new random password and sends it to user. More secure because user cannot choose a weak password, but user must change it immediately. User-chosen – reset process allows user to directly set new password. Generally fine but must ensure token security.
Trigger recovery. If you receive a new password (like kL9#mQ2!), it's generated. If you receive a link to set your own password, it's user-chosen.
2.1.57 How Is It Sent to the User? Email or Temporary Link
#
Test Item
Detailed Explanation
Testing Method
71
email or temporary link
Email – most common, but email is not a secure channel. Attacker with access to email account can compromise password. Temporary link – user clicks link to reset page. Link should expire after first use or within a short time (e.g., 15 minutes). SMS – mobile number, but SIM swapping risk. In-app – requires access to already logged-in device (high security).
Document delivery method. For temporary link, attempt to use it twice. Wait 24 hours and try again. Check if link contains user identifier that can be changed (?user=admin).
2.1.58 Are Users Forced to Change It on First Login
#
Test Item
Detailed Explanation
Testing Method
72
forced change on first login
After password reset or initial account creation, does the system require immediate password change? Critical security control – ensures that temporary passwords (emailed or generated) cannot be used indefinitely. Without forced change, anyone who intercepts the reset email can access the account forever.
Reset password. Log in with the temporary password or reset link. Check if you are immediately redirected to a "change password" page. Try to access other pages before changing password (should be blocked).
2.1.59 Is the App Allowing Use of Multiple Times
#
Test Item
Detailed Explanation
Testing Method
73
multiple times
Can the same password reset token or temporary password be used more than once? Single-use – after first use, token is invalidated. Multiple-use – token remains valid indefinitely or for a fixed time regardless of prior use. Multiple-use tokens are serious flaws: attacker who captures token once can access account repeatedly, and legitimate user using token does not invalidate attacker's copy.
Use reset token to reset password. Logout. Try to use same token again. Try to use same temporary password again. If either works → multiple-use flaw.
2.1.60 Based on Username
#
Test Item
Detailed Explanation
Testing Method
74
based on username
Password recovery process tied directly to username (e.g., /reset?username=admin or recovery form asks only for username, not email). Risks: User enumeration (you can test if username exists), token parameter manipulation (change username=admin to username=user2 after receiving token), and forced browsing (try all usernames).
Check recovery URL for ?user=, ?username=, ?login=. Try changing username to other values and see if you receive reset for that user.
2.1.61 Blacklist Present
#
Test Item
Detailed Explanation
Testing Method
75
blacklist present
Username blacklist – prevents registration of certain usernames (admin, root, administrator, support). Password blacklist – prevents use of common weak passwords (password, 123456, qwerty, admin). Good security control, but must be comprehensive (at least top 10,000 passwords).
Try to register admin, root, administrator. Try to set password password, 123456, qwerty, admin123. Check if rejected.
2.1.62 Need for Multifactor Authentication
#
Test Item
Detailed Explanation
Testing Method
76
need for multifactor authentication
Does the application require, support, or optionally allow MFA/2FA? Types: SMS (weak – SIM swapping), TOTP (Google Authenticator, Authy – better), WebAuthn/U2F (hardware key – best), email code (weak), backup codes (good as fallback). MFA significantly reduces account takeover risk even if password is compromised.
Check security settings for "Two-factor authentication", "2FA", "Multifactor", "Authenticator app", "Security key". Attempt to log in without MFA if it's optional. Test bypass methods (OAuth login without MFA, API endpoints that skip MFA, "remember this device" that never re-prompts).
2.1.63 Old Password Required to Change
#
Test Item
Detailed Explanation
Testing Method
77
old password required to change
When changing password, does the application ask for the current password? Yes – prevents session hijacker or unauthorized user from changing password without knowing current password. No – anyone with access to an authenticated session (even temporary) can lock out the legitimate user by changing password.
Go to "Change Password" function. Try to submit new password without entering old password. Try with incorrect old password. If either succeeds → vulnerability.
2.1.64 Need for Multifactor Authentication (repeated in original)
#
Test Item
Detailed Explanation
Testing Method
78
need for multifactor authentication
Repeated emphasis – check MFA implementation flaws: MFA bypass via parameter (?mfa_required=false or 2fa=skip), MFA not enforced on all login paths (API, OAuth, social login, admin interfaces), MFA recovery codes stored insecurely, MFA enrollment without verifying ownership, MFA codes too long expiration (e.g., 10 minutes), MFA rate limiting missing (brute force 6-digit code).
Attempt to access API endpoints directly after primary login but before MFA. Check for URL parameters controlling MFA. Try 1000 random MFA codes quickly.
2.1.65 Need for Multifactor Authentication (repeated again)
#
Test Item
Detailed Explanation
Testing Method
79
need for multifactor authentication
Third repetition – also test MFA fallback mechanisms: backup codes (are they single-use? can they be regenerated without old ones?), SMS fallback (can attacker change phone number without verification?), email fallback (can attacker access email?). Also test MFA reset process – does it require identity verification or can an attacker disable MFA?
Request MFA reset. See what verification is required. Try to disable MFA through account settings without providing current MFA code.
2.1.66 Lockout
#
Test Item
Detailed Explanation
Testing Method
80
lockout
Account lockout after a number of failed login attempts (e.g., 5 failures → lock for 15 minutes). Prevents brute force attacks. Must be balanced against denial of service (attacker can lock all users).
Attempt login with wrong password repeatedly. Count attempts until lockout. Note lockout duration. Test if lockout resets on successful login or after time. Test if lockout is per-IP or per-account.
2.1.67 Permanent
#
Test Item
Detailed Explanation
Testing Method
81
permanent
Permanent lockout (requires administrator to manually unlock account). High security but high DoS risk – attacker can lock out every user permanently by repeatedly failing login. Only acceptable for very low-volume, high-security internal systems.
Trigger lockout. Wait 24 hours. Try to log in again. If still locked, lockout is permanent. Check if there's a self-service unlock (email verification) – that's not permanent.
2.1.68 High Risk of DOS
#
Test Item
Detailed Explanation
Testing Method
82
high risk of DOS
Denial of Service via account lockouts. Attacker can systematically try wrong passwords for every known username (from user enumeration) and lock every account. Mitigations: CAPTCHA before counting failures, increasing delays (not lockout), per-IP rate limiting, lockout only after many failures (e.g., 20 attempts), short lockout duration (e.g., 5 minutes), or no lockout at all (use rate limiting instead).
Attempt to lock a known user account. Try to lock 10 different accounts. Assess business impact.
2.1.69 CAPTCHA Present?
#
Test Item
Detailed Explanation
Testing Method
83
capcha present?
CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) on login, registration, password recovery, or payment forms. Prevents automated brute force, credential stuffing, and account creation attacks. Weak CAPTCHAs: simple math (2+3=?), text CAPTCHAs with OCR bypass, CAPTCHAs that don't change, CAPTCHAs with known bypass. Strong CAPTCHAs: reCAPTCHA v3 (invisible), hCaptcha.
Check for CAPTCHA image or checkbox. Try to submit form without solving CAPTCHA (send same request with CAPTCHA parameter missing). Try to reuse old CAPTCHA token. Solve CAPTCHA manually to confirm it works.
2.1.70 Forget Password / Password Recovery Forms
#
Test Item
Detailed Explanation
Testing Method
84
forget password / password recovery forms
Specific focus on recovery forms – often the weakest link. Specific tests: (1) User enumeration – existing vs non-existing user messages. (2) Rate limiting – can you request 100 resets in 1 minute? (3) Token in URL – leaks via Referer. (4) Token predictability – base64, timestamp, MD5(username). (5) IDOR – change user parameter to reset another user's password. (6) Host header injection – recovery email sent to attacker's server. (7) SQL injection in email/username field. (8) No CAPTCHA – automated flooding.
Burp Intruder on recovery form with 100 requests. Check token format. Change user=admin to user=victim. Set Host: attacker.com and see where recovery link points.
Attempt 100 login attempts in 10 seconds. Attempt from different IPs (VPN, proxy rotation). Check if delays increase after failures. Check if JavaScript execution is required (headless browser detection).
2.1.72 Password Remembered?
#
Test Item
Detailed Explanation
Testing Method
86
password remembered?
"Remember me" or "Keep me logged in" or "Stay signed in" functionality – creates a persistent session cookie (long expiration, usually days or weeks). Security risks: Cookie stored on disk (not just memory), vulnerable to theft via malware or physical access. Best practice: Cookie should be cryptographically strong, tied to browser fingerprint, invalidated on logout, and not allow high-risk actions (password change, payment) without re-authentication.
Check Remember me box. Login. Close browser completely. Reopen browser and visit site. Are you still logged in? Check cookie expiration date (should be future). Logout. Check if persistent cookie is deleted. Try to reuse saved cookie from another computer.
2.1.73 Login After Registration or Activation Required?
#
Test Item
Detailed Explanation
Testing Method
87
login after registration or activation required?
Email activation required – user receives email with activation link, must click before first login. Prevents bots from creating accounts (if email verification is required) and confirms email ownership. Immediate login – user can log in immediately after registration without email verification. Allows fake/bot accounts but better user experience.
Register new account. Immediately try to log in. If successful → no activation required. If blocked with "Please verify your email" → activation required. Check if activation link can be used multiple times. Check if activation link reveals user ID.
2.1.74 Manual
#
Test Item
Detailed Explanation
Testing Method
88
manual
Final reminder: manual verification of every automated finding. Tools produce false positives. Manual testing provides business logic understanding, context, and confirmation of exploitability. Always produce a manual proof-of-concept for each claimed vulnerability.
For each automated finding, reproduce the vulnerability manually and document step-by-step instructions.
2.1.75 Concurrent Logins Enabled
#
Test Item
Detailed Explanation
Testing Method
89
concurrent logins enabled
Can the same user account be logged in simultaneously from multiple browsers, devices, or locations? Enabled (default) – user can be logged in on phone and laptop simultaneously. Disabled – new login invalidates old session. Disabled reduces session hijacking risk (attacker cannot stay logged in after user logs in) but frustrates users.
Log in from Browser A. Log in from Browser B (different device or private window). Check if Browser A session remains active. Perform actions in both browsers. If both work → concurrent logins enabled. If Browser A is logged out → concurrent logins disabled (session invalidation on new login).
2.2 Authorization
Definition: The process of determining what an authenticated user is allowed to do (permissions, roles, access levels). Authorization happens after authentication.
2.2.1 Horizontal Privileges Checking
#
Test Item
Detailed Explanation
Testing Method
90
horizontal privileges checking
Testing if a user can access resources belonging to another user at the same privilege level. Example: User A (role: standard user) tries to access User B's profile, orders, messages, or files. This is Horizontal Privilege Escalation or Insecure Direct Object Reference (IDOR).
For each resource endpoint (profile, order, document, message, setting), change the identifier (user_id=1001 to 1002, order_id=ABC to ABD) and observe if you can access another user's data.
2.2.2 Check If the Users Cannot Access Content of Another
#
Test Item
Detailed Explanation
Testing Method
91
check if the users cannot access content of another
Positive verification that horizontal access controls are working correctly. For each attempted IDOR, the expected result is 403 Forbidden, 401 Unauthorized, 404 Not Found, or a redirect to home page – NOT returning the other user's data.
For each IDOR attempt, document the response. If you receive another user's data → vulnerability. If you receive error → access control working.
2.2.3 Manual, Cookie Manipulation, Burp
#
Test Item
Detailed Explanation
Testing Method
92
manual
Manually edit identifiers in URL (e.g., change https://target.com/profile?id=1 to id=2) and in POST parameters (modify hidden fields).
93
cookie manipulation
Edit cookies that contain user identifiers (e.g., user_id=123, account=456). Use browser dev tools (Application → Cookies) or Burp to modify cookie values.
94
burp
Use Burp Suite: Repeater to manually change IDs and resend. Intruder to brute force ID range (e.g., from 1 to 10000). Comparer to compare responses for different IDs. Macro to automate login and IDOR attack sequence.
Burp Repeater → Change id=1 to id=2 → Send. Burp Intruder → Positions around ID → Payload = Numbers 1-1000 → Attack → Review response lengths for differences.
2.2.4 Vertical Privilege Levels
#
Test Item
Detailed Explanation
Testing Method
95
vertical privilege levels
Testing if a low-privilege user (standard user, guest, unauthenticated) can access high-privilege functions (admin panel, user management, system configuration, audit logs). This is Vertical Privilege Escalation.
Identify admin-only endpoints (/admin, /manage, /config, /users, /audit, /backup). Access them with a standard user session. Try to submit admin forms (user creation, role change) as standard user.
2.2.5 Check If the Access of Scripts from History
#
Test Item
Detailed Explanation
Testing Method
96
check if the access of scripts from history
After logout or privilege downgrade, can you access previously visited admin URLs from browser history? This tests if the application re-validates authorization on every request or only at login. Steps: 1) Log in as admin, visit /admin/users. 2) Logout. 3) Open browser history and click the same /admin/users link. 4) Also try copy-pasting URL in new private window. If you can see the page → session not properly invalidated or authorization not rechecked.
Logout completely. Close browser (to clear memory session). Reopen browser, type admin URL directly. Also try after session timeout. Use browser's "Reopen closed tab" feature.
2.2.6 Manual
#
Test Item
Detailed Explanation
Testing Method
97
manual
Manually test vertical privilege escalation by: (1) Discovering hidden admin links in page source or JavaScript. (2) Trying common admin paths (/admin, /administrator, /moderator). (3) Modifying role parameters (role=user → role=admin). (4) Accessing API endpoints (/api/users, /api/admin/config). (5) Forced browsing to backup directories (/backup.zip, /old/).
For each discovered admin resource, attempt to access as standard user. Record response.
2.2.7 Manual, Burp
#
Test Item
Detailed Explanation
Testing Method
98
manual, burp
Advanced vertical testing with Burp: (1) Capture admin request as admin user. (2) Log in as standard user. (3) Send same request in Burp Repeater (replay). (4) Observe if server accepts. (5) Modify request parameters (e.g., add isAdmin=true). (6) Use Burp Session Handling rules to automate switching between user roles while replaying same requests.
Burp Repeater → Paste admin request → Modify session cookie to standard user's cookie → Send. If response shows admin content → vertical escalation.
PART 3: REPEATED "MANUAL" ENTRIES (Original Image Artifacts)
The original image ends with multiple sequential "manual" entries and a truncated "manu". These represent individual manual test cases – each is a separate verification step. In professional testing, these correspond to:
Repeated Entry
Implied Test Case
manual
Verify directory listing manually
manual
Verify verbose error manually
manual
Verify default admin interface manually
manual
Verify trace method manually
manual
Verify SSL configuration manually
manual
Verify weak ciphers manually
manual
Verify certificate validity manually
manual
Verify server fingerprinting manually
manual
Verify robots.txt manually
manual
Verify login forms manually
manual
Verify registration forms manually
manual
Verify password recovery forms manually
manual
Verify Oracle Padding manually
manual
Verify GET/POST parameters manually
manual
Verify hidden fields manually
manual
Verify user enumeration manually
manual
Verify lockout manually
manual
Verify CAPTCHA manually
manual
Verify concurrent logins manually
manual
Verify horizontal privileges manually
manual
Verify vertical privileges manually
(truncated "manu")
Incomplete – likely "manual" again
Principle: Every automated finding must be manually validated. Automated tools are scanners; manual testers are analysts.
