{"uuid": "3902fe9a-3368-4a43-a4cf-877c95778143", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2009-3555", "type": "seen", "source": "https://gist.github.com/bbrk364/352f2ecc70f5e8b65de8b817a9ab871f", "content": "## Web Application Security Testing Guide: Session Management, Authentication & Authorization\n\n\n---\n\n# PART 1: SESSION MANAGEMENT\n\n## Overview\n\nSession 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.\n\n### Why Session Management Matters\n\n| Risk | Impact |\n|------|--------|\n| Weak session token generation | Session prediction, hijacking |\n| Insecure token transmission | Man-in-the-middle (MITM) interception |\n| Missing timeout controls | Session reuse by attackers |\n| Fixation vulnerabilities | Attacker forces known session ID |\n| Concurrent login flaws | Account takeover without logout |\n\n### Key Areas of Testing\n\n1. Token creation (randomness, entropy, uniqueness)\n2. Token storage (secure cookies, HttpOnly, Secure flags)\n3. Token transmission (HTTPS only, not in URLs)\n4. Token expiration (idle timeout, absolute timeout)\n5. Token binding (to IP, User-Agent, or other fingerprint)\n6. Logout functionality (server-side invalidation)\n7. Session fixation resistance\n\n---\n\n# PART 2: AUTHENTICATION & AUTHORIZATION\n\n## 2.1 Authentication\n\n**Definition:** The process of verifying the identity of a user, device, or system. Common authentication factors include:\n- **Something you know** (password, PIN)\n- **Something you have** (phone, hardware token)\n- **Something you are** (biometrics: fingerprint, face)\n\n### 2.1.1 Basic Server Configuration\n\nTesting the fundamental web server settings that impact authentication security.\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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` |\n| 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` |\n| 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 |\n| 4 | manual & browser | Combine manual testing (raw HTTP requests via netcat or telnet) with browser-based testing (Developer Tools \u2192 Network tab) to observe differences between client-side and server-side behavior. | Browser DevTools + `nc target.com 80` |\n\n### 2.1.2 Analyze Request and Response from App\n\nInspecting the actual HTTP traffic between browser and server.\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n| 6 | browser | Use browser Developer Tools (F12) \u2192 Network tab. Observe live requests, cookies set, redirect chains, and JavaScript-triggered requests. | Chrome/Edge DevTools, Firefox Developer Tools |\n| 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\" | nc target.com 80` |\n\n### 2.1.3 Other Pages and Dirs on the Server\n\nDiscovering hidden or unlinked content on the web server.\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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` |\n| 9 | burp | Burp Suite Professional features: Content Discovery (passive + active), Engagement Tools \u2192 Discover Content, and Intruder for brute force directory lists. | Burp Suite \u2192 Target \u2192 Site map \u2192 Engage \u2192 Discover content |\n| 10 | zap | OWASP ZAP features: Forced Browse (directory brute force), Spider (crawling), and AJAX Spider for JavaScript-heavy apps. | ZAP \u2192 Quick Start \u2192 Automated Scan |\n| 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` |\n| 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` |\n\n### 2.1.4 Any Directory Listings Present\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n\n**Example of vulnerable response:**\n```html\n\n\n\n\nIndex of /backup\n\n\n\ndatabase.sql\n\nconfig.old\n\n\n\n```\n\n### 2.1.5 Verbose Error Responses Enabled\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. | Submit `'` in search box, upload invalid file, manipulate URL parameters |\n| 15 | burp | Use Burp Repeater to systematically modify parameters and observe error differences. Burp Scanner automatically detects information disclosure via error messages. | Burp Repeater \u2192 Send malformed requests \u2192 Compare error verbosity |\n| 16 | zap | ZAP's Fuzzer can send thousands of payloads and flag responses containing common error patterns (e.g., `SQL syntax`, `Stack trace`, `Warning:`, `Fatal error`). | ZAP \u2192 Fuzz \u2192 Add payloads \u2192 View errors in \"Fuzzer\" tab |\n\n### 2.1.6 Default Admin Interface\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 17 | webextensions | Browser extensions that detect or brute force admin panels: **Admin Finder**, **FindAdmin**, **Wappalyzer** (technology detection), **Retire.js** (vulnerable libraries). | Install from Chrome/Firefox store \u2192 Navigate to target \u2192 Extension scans common paths |\n\n**Common admin paths to test manually:**\n```\n/admin, /administrator, /admin.php, /admin.asp, /admin/login, /wp-admin, /cpanel, /webmail, /plesk, /dashboard, /manage, /backend\n```\n\n### 2.1.7 Trace Method\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 18 | trace method | HTTP TRACE method echoes back the exact request received by the server. Combined with XSS, this enables **Cross-Site Tracing (XST)** \u2013 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 |\n\n**Test request:**\n```http\nTRACE / HTTP/1.1\nHost: target.com\nX-Custom-Header: test\n```\n**Vulnerable response** (echoes back the headers):\n```http\nHTTP/1.1 200 OK\nX-Custom-Header: test\n```\n\n### 2.1.8 Application\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 browse \u2192 logout \u2192 back button |\n\n### 2.1.9 SSL Version\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 20 | SSL version | Check which SSL/TLS protocol versions are supported. **Deprecated/dangerous versions:** SSLv2 (1995), SSLv3 (1996 \u2013 POODLE attack), TLS 1.0 (1999 \u2013 BEAST attack), TLS 1.1 (2006). **Acceptable:** TLS 1.2 (2008), TLS 1.3 (2018). | `openssl s_client -connect target.com:443 -ssl3`, `testssl.sh target.com`, Qualys SSL Labs |\n\n### 2.1.10 Weak Ciphers\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 21 | Weak CipherS | Cryptographic cipher suites that are known to be vulnerable: **Export ciphers** (40/56-bit keys \u2013 FREAK attack), **NULL ciphers** (no encryption), **RC4** (biases), **DES/3DES** (Sweet32 attack), **CBC mode** (BEAST, Lucky13). | `nmap --script ssl-enum-ciphers -p 443 target.com`, `testssl.sh --wide target.com` |\n\n### 2.1.11 Renegotiation Support\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 22 | Renegotiation Support | TLS renegotiation allows client and server to re-establish cryptographic parameters within an existing connection. **Insecure renegotiation** (CVE-2009-3555) allows prefix injection attacks \u2013 attacker can prepend their own data to a legitimate user's request. | `testssl.sh --renegotiation target.com`, `openssl s_client -connect target.com:443 -reconnect` |\n\n### 2.1.12 Vulnerable to BEAST\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 23 | Vulnerable to BEAST | **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). | `testssl.sh --beast target.com`, Qualys SSL Labs report |\n\n### 2.1.13 Expired Certificate\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 24 | expired certificate | 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. | `openssl s_client -connect target.com:443 2>/dev/null | openssl x509 -noout -dates`, browser padlock icon \u2192 Certificate \u2192 Validity |\n\n### 2.1.14 Self-Signed Certificate\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 25 | self signed certificate | 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. | Check certificate issuer: `openssl s_client -connect target.com:443 | openssl x509 -noout -issuer`, look for \"Self-signed\" or issuer = subject |\n\n### 2.1.15 Wildcard Certificate\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 26 | wild card certificate | 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 | openssl x509 -noout -text | grep -A1 \"Subject Alternative Name\"` |\n\n### 2.1.16 SSLAudit\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 27 | SSLAudit | Comprehensive SSL/TLS configuration audit covering protocol versions, cipher suites, certificate chain, key exchange parameters (DH/RSA), HSTS, OCSP stapling, and known vulnerabilities (Heartbleed, ROBOT, CRIME, BREACH, POODLE, Logjam, DROWN). | `testssl.sh target.com`, `sslyze target.com`, `nmap --script ssl-* -p 443 target.com`, `o-saft target.com` |\n\n### 2.1.17 Refer Software Page\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 28 | Refer software page | Check for explicit references to third-party software in page footers, copyright notices, comment tags, or meta generators. Examples: \"Powered by WordPress\", \"\u00a9 2024 Magento\", \"Django 3.2\", \"ASP.NET Version:4.8\". Each reference helps attacker narrow down exploits. | View page source (Ctrl+U), check HTML comments, look for meta tags, check `/wp-content/`, `/js/`, `/css/` paths |\n\n### 2.1.18 Target URL Placeholder\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 29 | https://www.example.com | 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. | `https://actual-target.com`, `http://actual-target.com` (if redirect behavior differs) |\n\n### 2.1.19 Server Fingerprinting\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 30 | server fingerprinting | 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. | `httprint -h target.com`, `whatweb target.com`, `curl -I target.com`, observe default files (`/wp-admin` \u2192 WordPress) |\n\n### 2.1.20 Netcraft\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 31 | netcraft | 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. | Visit `https://sitereport.netcraft.com/?url=https://target.com` |\n\n### 2.1.21 IP Address Leaks\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 32 | ip address leaks | 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) |\n\n### 2.1.22 Burp Headers\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Proxy \u2192 HTTP History \u2192 Select any request \u2192 Inspector tab \u2192 Review all response headers |\n\n### 2.1.23 Is Proxy Present?\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n\n### 2.1.24 Manual\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n\n### 2.1.25 Analyze robots.txt\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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` |\n| 37 | firebug plugin | Firebug was a legacy Firefox developer tool (discontinued). Modern equivalent: **Firefox Developer Tools** (F12) \u2192 Network tab, or **Chrome DevTools** \u2192 Network tab. Use to observe requests for `robots.txt` and any dynamically generated disallow rules. | Modern: Browser DevTools \u2192 Network \u2192 Reload \u2192 Filter for `robots.txt` |\n\n**Example robots.txt revealing sensitive paths:**\n```\nUser-agent: *\nDisallow: /admin\nDisallow: /backup\nDisallow: /private-notes\nDisallow: /staging\n```\n\n### 2.1.26 Login Forms\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 38 | login forms | 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 `\n`, look for `action` pointing to login handlers, check JavaScript for dynamic login creation, spider the entire application |\n\n### 2.1.27 Registration Forms\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n\n### 2.1.28 Password Recovery Forms\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 40 | password recovery forms | \"Forgot password\" or \"Reset password\" forms \u2013 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 |\n\n### 2.1.29 Oracle Padding\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 41 | Oracle Padding | **Padding oracle attack** \u2013 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\" |\n\n### 2.1.30 Identify Technologies Used\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Visit target \u2192 Click extension icon to see full technology list |\n\n### 2.1.31 Identify GETs\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Target \u2192 Site map \u2192 Filter by method = GET, export to CSV, review each endpoint |\n\n### 2.1.32 Identify POSTs\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Target \u2192 Site map \u2192 Filter by method = POST, review each endpoint and its parameters |\n\n### 2.1.33 Identify Parameters in GETs and POSTs\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Target \u2192 Site map \u2192 Right-click \u2192 Engagement tools \u2192 Find parameters, or manually review each request in HTTP History |\n\n### 2.1.34 Check If Actual Objects, SessionIDs Are Passed in GET Requests\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n\n### 2.1.35 Replace the Methods and Headers\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Change method line \u2192 Send. Change `Referer: https://target.com` to `Referer: https://evil.com`. Change `User-Agent` to `curl/7.68.0` to mimic bot. |\n\n### 2.1.36 Check If the Application Accepts the Request\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 |\n\n### 2.1.37 Search Boxes\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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** (`alert(1)`), **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 |\n\n### 2.1.38 Login Fields\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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`. |\n\n### 2.1.39 Register Fields\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 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 \u2192 Add extra parameter `&is_admin=1`. Try registering `\" onmouseover=alert(1) x=\"` as username. |\n\n### 2.1.40 Payment Processing\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 integer overflow to low total). | Modify `amount` parameter in Burp before final submission. Try negative quantity. Change `order_id` in confirmation page URL. |\n\n### 2.1.41 Client-Side Validation\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Disable JavaScript), or directly send raw request with modified parameters bypassing all client-side checks. Client-side validation is for user experience only \u2013 never for security. | Burp Proxy \u2192 Intercept request \u2192 Modify `maxlength` attribute or submit longer value. Browser \u2192 Settings \u2192 Disable JavaScript \u2192 Submit form. |\n\n### 2.1.42 Identify Critical Components and Possible Ways They Can Be Subverted\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n| 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. |\n\n### 2.1.43 Identify Hidden Fields and Their Purpose\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 56 | identify hidden fields | Find all `` 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. |\n| 57 | their purpose | Determine what each hidden field controls. **Common purposes:** user role (``), user ID (``), product price (``), CSRF token (``), redirect URL (``), 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`). |\n\n### 2.1.44 Pass Through\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.45 User Enumeration\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.46 Guessing Username\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Payload list of common usernames \u2192 Observe differences in response (message, length, status code, time). |\n\n### 2.1.47 Password Length\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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). |\n\n### 2.1.48 Password Complexity\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.49 Password Expiration\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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). |\n\n### 2.1.50 Password History\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.51 Default Passwords\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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]\". |\n\n### 2.1.52 Recovery Process\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 66 | recovery process | Complete end-to-end analysis of the password recovery workflow: Step 1 \u2192 User requests reset (provides username/email). Step 2 \u2192 Verification (CAPTCHA, security questions, email link). Step 3 \u2192 Token generation (format, randomness, expiration). Step 4 \u2192 Token delivery (email, SMS). Step 5 \u2192 Token validation (server-side). Step 6 \u2192 New password form. Step 7 \u2192 Confirmation and login. | Document each step. Intercept and analyze every request/response. Look for logic flaws at each boundary. |\n\n### 2.1.53 Forgot Password Methodology\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 67 | forgot password methodology | Specific implementation of password recovery. **Security questions** (mother's maiden name, pet's name \u2013 often guessable or discoverable via social media) \u2013 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. |\n\n### 2.1.54 Is Password Sent in Clear Text or Not\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 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). |\n\n### 2.1.55 How Is Password Sent \u2013 Email or Reset URL\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 69 | email or reset url | **Sending password via email** (e.g., \"Your password is: MyPassword123\") \u2013 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\") \u2013 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). |\n\n### 2.1.56 Is It Generated by the App\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 70 | is it generated by the app | **Server-generated temporary passwords** \u2013 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** \u2013 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. |\n\n### 2.1.57 How Is It Sent to the User? Email or Temporary Link\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 71 | email or temporary link | **Email** \u2013 most common, but email is not a secure channel. Attacker with access to email account can compromise password. **Temporary link** \u2013 user clicks link to reset page. Link should expire after first use or within a short time (e.g., 15 minutes). **SMS** \u2013 mobile number, but SIM swapping risk. **In-app** \u2013 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`). |\n\n### 2.1.58 Are Users Forced to Change It on First Login\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 72 | forced change on first login | After password reset or initial account creation, does the system require immediate password change? **Critical security control** \u2013 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). |\n\n### 2.1.59 Is the App Allowing Use of Multiple Times\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 73 | multiple times | Can the same password reset token or temporary password be used more than once? **Single-use** \u2013 after first use, token is invalidated. **Multiple-use** \u2013 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 \u2192 multiple-use flaw. |\n\n### 2.1.60 Based on Username\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.61 Blacklist Present\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 75 | blacklist present | **Username blacklist** \u2013 prevents registration of certain usernames (admin, root, administrator, support). **Password blacklist** \u2013 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. |\n\n### 2.1.62 Need for Multifactor Authentication\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 76 | need for multifactor authentication | Does the application require, support, or optionally allow MFA/2FA? **Types:** SMS (weak \u2013 SIM swapping), TOTP (Google Authenticator, Authy \u2013 better), WebAuthn/U2F (hardware key \u2013 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). |\n\n### 2.1.63 Old Password Required to Change\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 77 | old password required to change | When changing password, does the application ask for the current password? **Yes** \u2013 prevents session hijacker or unauthorized user from changing password without knowing current password. **No** \u2013 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 \u2192 vulnerability. |\n\n### 2.1.64 Need for Multifactor Authentication (repeated in original)\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 78 | need for multifactor authentication | Repeated emphasis \u2013 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. |\n\n### 2.1.65 Need for Multifactor Authentication (repeated again)\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 79 | need for multifactor authentication | Third repetition \u2013 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 \u2013 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. |\n\n### 2.1.66 Lockout\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 80 | lockout | Account lockout after a number of failed login attempts (e.g., 5 failures \u2192 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. |\n\n### 2.1.67 Permanent\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 81 | permanent | Permanent lockout (requires administrator to manually unlock account). **High security but high DoS risk** \u2013 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) \u2013 that's not permanent. |\n\n### 2.1.68 High Risk of DOS\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.69 CAPTCHA Present?\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.70 Forget Password / Password Recovery Forms\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 84 | forget password / password recovery forms | Specific focus on recovery forms \u2013 often the weakest link. **Specific tests:** (1) User enumeration \u2013 existing vs non-existing user messages. (2) Rate limiting \u2013 can you request 100 resets in 1 minute? (3) Token in URL \u2013 leaks via Referer. (4) Token predictability \u2013 base64, timestamp, MD5(username). (5) IDOR \u2013 change user parameter to reset another user's password. (6) Host header injection \u2013 recovery email sent to attacker's server. (7) SQL injection in email/username field. (8) No CAPTCHA \u2013 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. |\n\n### 2.1.71 Prevent Automation\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 85 | prevent automation | Mechanisms to block automated attacks (brute force, credential stuffing, account creation). **Controls:** Rate limiting (per IP, per account, per session), CAPTCHA, request signing (HMAC), behavior analysis (mouse movements, typing patterns), IP blacklisting, delayed responses (exponential backoff), token bucket algorithm, JavaScript challenge (Proof-of-Work). | 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). |\n\n### 2.1.72 Password Remembered?\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 86 | password remembered? | \"Remember me\" or \"Keep me logged in\" or \"Stay signed in\" functionality \u2013 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. |\n\n### 2.1.73 Login After Registration or Activation Required?\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 87 | login after registration or activation required? | **Email activation required** \u2013 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** \u2013 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 \u2192 no activation required. If blocked with \"Please verify your email\" \u2192 activation required. Check if activation link can be used multiple times. Check if activation link reveals user ID. |\n\n### 2.1.74 Manual\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.1.75 Concurrent Logins Enabled\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 89 | concurrent logins enabled | Can the same user account be logged in simultaneously from multiple browsers, devices, or locations? **Enabled (default)** \u2013 user can be logged in on phone and laptop simultaneously. **Disabled** \u2013 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 \u2192 concurrent logins enabled. If Browser A is logged out \u2192 concurrent logins disabled (session invalidation on new login). |\n\n---\n\n## 2.2 Authorization\n\n**Definition:** The process of determining what an authenticated user is allowed to do (permissions, roles, access levels). Authorization happens after authentication.\n\n### 2.2.1 Horizontal Privileges Checking\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.2.2 Check If the Users Cannot Access Content of Another\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2013 NOT returning the other user's data. | For each IDOR attempt, document the response. If you receive another user's data \u2192 vulnerability. If you receive error \u2192 access control working. |\n\n### 2.2.3 Manual, Cookie Manipulation, Burp\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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). |\n| 93 | cookie manipulation | Edit cookies that contain user identifiers (e.g., `user_id=123`, `account=456`). Use browser dev tools (Application \u2192 Cookies) or Burp to modify cookie values. |\n| 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 \u2192 Change `id=1` to `id=2` \u2192 Send. Burp Intruder \u2192 Positions around ID \u2192 Payload = Numbers 1-1000 \u2192 Attack \u2192 Review response lengths for differences. |\n\n### 2.2.4 Vertical Privilege Levels\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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. |\n\n### 2.2.5 Check If the Access of Scripts from History\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 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. |\n\n### 2.2.6 Manual\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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` \u2192 `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. |\n\n### 2.2.7 Manual, Burp\n\n| # | Test Item | Detailed Explanation | Testing Method |\n|---|-----------|---------------------|----------------|\n| 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 \u2192 Paste admin request \u2192 Modify session cookie to standard user's cookie \u2192 Send. If response shows admin content \u2192 vertical escalation. |\n\n---\n\n# PART 3: REPEATED \"MANUAL\" ENTRIES (Original Image Artifacts)\n\nThe original image ends with multiple sequential \"manual\" entries and a truncated \"manu\". These represent **individual manual test cases** \u2013 each is a separate verification step. In professional testing, these correspond to:\n\n| Repeated Entry | Implied Test Case |\n|----------------|-------------------|\n| manual | Verify directory listing manually |\n| manual | Verify verbose error manually |\n| manual | Verify default admin interface manually |\n| manual | Verify trace method manually |\n| manual | Verify SSL configuration manually |\n| manual | Verify weak ciphers manually |\n| manual | Verify certificate validity manually |\n| manual | Verify server fingerprinting manually |\n| manual | Verify robots.txt manually |\n| manual | Verify login forms manually |\n| manual | Verify registration forms manually |\n| manual | Verify password recovery forms manually |\n| manual | Verify Oracle Padding manually |\n| manual | Verify GET/POST parameters manually |\n| manual | Verify hidden fields manually |\n| manual | Verify user enumeration manually |\n| manual | Verify lockout manually |\n| manual | Verify CAPTCHA manually |\n| manual | Verify concurrent logins manually |\n| manual | Verify horizontal privileges manually |\n| manual | Verify vertical privileges manually |\n| (truncated \"manu\") | Incomplete \u2013 likely \"manual\" again |\n\n**Principle:** Every automated finding must be manually validated. Automated tools are scanners; manual testers are analysts.\n\n---\n\n# APPENDIX: QUICK REFERENCE TABLE\n\n| Category | Subcategory | Key Test Items |\n|----------|-------------|----------------|\n| **Session Management** | Token Security | Generation, transmission, expiration, binding |\n| **Authentication** | Server Config | Banners, methods, error pages, dir listings |\n| | SSL/TLS | Versions, ciphers, certs, BEAST, renegotiation |\n| | Request Analysis | GET/POST, parameters, hidden fields |\n| | Password Policy | Length, complexity, history, expiration, defaults |\n| | Password Recovery | Methodology, token security, multiple-use, forced change |\n| | Lockout & MFA | Lockout policy, DoS risk, CAPTCHA, MFA implementation |\n| | User Enumeration | Username guessing, response differences |\n| **Authorization** | Horizontal | Same role, different user (IDOR) |\n| | Vertical | Different role (user \u2192 admin) |\n| **Manual Testing** | Validation | Every automated finding manually confirmed |\n\n---", "creation_timestamp": "2026-08-25T15:53:29.833873Z"}