eWPT study materials
eWPT study resources

eWPT cheat sheet

eWPT · Keep the key ideas within reach.

Quick reference

Web Application Penetration Testing

  • Scope and rules of engagement must be fixed in writing before testing: in-scope hosts, IP ranges, credentials, test windows, prohibited techniques (DoS, social engineering), and emergency contact.

  • Testing phases follow: pre-engagement, reconnaissance, mapping/enumeration, vulnerability discovery, exploitation, post-exploitation, reporting, and retest; each phase produces an artifact the next phase consumes.

  • Black-box testing assumes no prior knowledge; grey-box supplies credentials or architecture; white-box supplies source and design docs. Findings from black-box are not comparable to white-box coverage.

  • Burp Suite workflow: Proxy intercept, Repeater for single-request iteration, Intruder for fuzzing (Sniper, Battering ram, Pitchfork, Cluster bomb), Scanner for passive/active checks, Decoder and Comparer for encoding and diffing.

  • OWASP WSTG and OWASP Top 10 are the standard checklists; WSTG organizes tests as INFO, CONF, IDNT, ATHN, ATHZ, SESS, INPV, ERRH, CRYP, BUSL, CLNT, APIT.

  • Testing must stay within authorization; a vulnerability that requires out-of-scope pivoting is reported as a finding, not exploited. Evidence collection (request/response pairs, timestamps) happens during testing, not after.

  • Authentication testing covers default credentials, username enumeration via response timing or message differences, lockout behavior, password reset token entropy, MFA bypass, and remember-me token forgery.

  • Session testing covers cookie attributes (Secure, HttpOnly, SameSite), token randomness, fixation, logout invalidation, and cross-user token reuse after privilege change.

  • Severity ratings (CVSS v3.1 base: AV, AC, PR, UI, S, C, I, A) must be justified with the exploit preconditions actually observed, not the theoretical maximum.

Quick reference

Web Application Reconnaissance and Enumeration

  • Passive recon uses third-party sources with no direct contact: certificate transparency (crt.sh), WHOIS/RDAP, DNS history, Shodan/Censys, GitHub code search, Wayback Machine, and search engine dorks (site:, inurl:, filetype:, intitle:).

  • Active recon touches the target: DNS zone transfer attempt (AXFR), subdomain brute force with wordlists (amass, subfinder, dnsx), virtual host discovery, and port scanning of authorized ranges only.

  • Technology fingerprinting signals: Server and X-Powered-By headers, cookie names (PHPSESSID, JSESSIONID, ASP.NET_SessionId), error page formats, favicon hash (mmh3), and static asset paths.

  • Content discovery uses directory/file brute forcing (ffuf, feroxbuster, gobuster) with status-code and size filters; 403 responses often indicate a resource exists but is access-controlled, 301/302 indicate redirects worth following.

  • robots.txt, sitemap.xml, .well-known/, and security.txt disclose intended and unintended paths; backup extensions (.bak, .old, ~, .swp, .zip) frequently expose source code.

  • JavaScript analysis: extract endpoints from bundles with linkfinder-style regex, check source maps (.map) for original code, and identify API base URLs and hidden parameters.

  • Google dorks map to exposure classes: filetype:env, filetype:sql, filetype:log, inurl:admin, inurl:.git, intitle:index.of, ext:php inurl:id=.

  • WAF detection via response headers, cookie behavior, and payload reflection differences; a WAF changes exploitation strategy (encoding, case variation, chunked transfer) but not vulnerability existence.

  • Enumeration of APIs: fetch /swagger.json, /openapi.json, /api-docs, /graphql with introspection query, and check HTTP methods per endpoint with OPTIONS.

Quick reference

Web Application Vulnerability Identification and Exploitation

  • SQL injection classes: in-band (union, error-based), blind (boolean, time-based); union requires matching column count and compatible types, determined by ORDER BY n or UNION SELECT NULL iteration.

  • NoSQL injection in MongoDB-style apps uses operator injection ($ne, $gt, $regex) in JSON bodies or query strings; authentication bypass is typically {"username":{"$ne":null},"password":{"$ne":null}}.

  • XSS types: reflected, stored, DOM-based (sink such as innerHTML, document.write, eval). Context determines payload: HTML body, attribute, JavaScript string, URL, CSS. CSP and HttpOnly limit impact, not existence.

  • CSRF requires a state-changing request with cookie-based auth and no unpredictable token or SameSite protection; PoC is an auto-submitting HTML form hosted cross-origin.

  • SSRF: test parameters that accept URLs or hostnames; bypass filters with decimal/octal IP, DNS rebinding, redirects, and IPv6-mapped addresses; cloud metadata endpoint 169.254.169.254 is the high-impact target.

  • XXE requires an XML parser with external entity resolution; test with a SYSTEM entity referencing a local file, then escalate to out-of-band via an external DTD for blind cases.

  • File upload bypass: content-type header, magic bytes, double extensions (.php.jpg), null byte, .htaccess upload, and filename path traversal. Execution depends on server config, so verify, do not assume.

  • Path traversal and LFI: ../ sequences, encoded variants (%2e%2e%2f, ..%5c), absolute paths, and PHP wrappers (php://filter, php://input, data://) where allow_url_include is on.

  • IDOR/BOLA: change object identifiers in requests and compare responses across two accounts with different privileges; the test is authorization, not identifier guessability.

  • Command injection: shell metacharacters (; | & $() `` \n) in parameters passed to system calls; blind detection via time delay (sleep, ping -c) or out-of-band DNS interaction.

  • Deserialization: Java (ysoserial gadget chains), PHP (PHPGGC), .NET (ysoserial.net), Python pickle. Look for base64 blobs in cookies, viewstate, and hidden fields.

  • JWT attacks: alg:none, algorithm confusion (RS256 to HS256 using the public key as HMAC secret), weak HMAC secret cracking with hashcat/john, and kid/jku header injection.

Quick reference

Web Application Exploitation and Reporting

  • Post-exploitation on a web app stays within scope: enumerate the DB (information_schema, current user privileges), read app config for credentials, and check for file read/write primitives (INTO OUTFILE, LOAD_FILE).

  • Privilege escalation from web shell: identify OS user, kernel version, sudo rights, cron jobs, writable service paths, and SUID binaries; document each step with command output.

  • Lateral movement and pivoting require explicit authorization; tunneling (SSH -L/-R/-D, chisel, socat) is documented as a technique with the exact command and affected hosts.

  • Evidence standard: for each finding, capture the full HTTP request and response, the exact payload, timestamps, affected URL/parameter, and reproduction steps that a third party can follow.

  • Report structure: executive summary (business risk, counts by severity), methodology and scope, findings ordered by severity, each with description, evidence, impact, remediation, and references.

  • Remediation guidance must be specific: parameterized queries rather than 'sanitize input'; output encoding by context; allowlist validation; least-privilege DB accounts; security headers (CSP, HSTS, X-Content-Type-Options).

  • CVSS v3.1 vector strings must be consistent with the report narrative; a stored XSS requiring admin interaction is typically S:C with UI:R, not a critical unauthenticated RCE.

  • Retest verifies the fix addresses root cause, not just the reported payload; note residual risk and any new issues introduced by the fix.

  • Data handling: reports and evidence containing credentials or PII are encrypted, shared only with named recipients, and deleted per the retention clause agreed in the rules of engagement.

Quick reference

Web Application Penetration Testing

  • Scope and rules of engagement must be fixed in writing before testing: in-scope hosts, IP ranges, credentials, test windows, prohibited techniques (DoS, social engineering), and emergency contact.

  • Testing phases follow: pre-engagement, reconnaissance, mapping/enumeration, vulnerability discovery, exploitation, post-exploitation, reporting, and retest; each phase produces an artifact the next phase consumes.

  • Black-box testing assumes no prior knowledge; grey-box supplies credentials or architecture; white-box supplies source and design docs. Findings from black-box are not comparable to white-box coverage.

  • Burp Suite workflow: Proxy intercept, Repeater for single-request iteration, Intruder for fuzzing (Sniper, Battering ram, Pitchfork, Cluster bomb), Scanner for passive/active checks, Decoder and Comparer for encoding and diffing.

  • OWASP WSTG and OWASP Top 10 are the standard checklists; WSTG organizes tests as INFO, CONF, IDNT, ATHN, ATHZ, SESS, INPV, ERRH, CRYP, BUSL, CLNT, APIT.

  • Testing must stay within authorization; a vulnerability that requires out-of-scope pivoting is reported as a finding, not exploited. Evidence collection (request/response pairs, timestamps) happens during testing, not after.

  • Authentication testing covers default credentials, username enumeration via response timing or message differences, lockout behavior, password reset token entropy, MFA bypass, and remember-me token forgery.

  • Session testing covers cookie attributes (Secure, HttpOnly, SameSite), token randomness, fixation, logout invalidation, and cross-user token reuse after privilege change.

  • Severity ratings (CVSS v3.1 base: AV, AC, PR, UI, S, C, I, A) must be justified with the exploit preconditions actually observed, not the theoretical maximum.

Quick reference

Web Application Reconnaissance and Enumeration

  • Passive recon uses third-party sources with no direct contact: certificate transparency (crt.sh), WHOIS/RDAP, DNS history, Shodan/Censys, GitHub code search, Wayback Machine, and search engine dorks (site:, inurl:, filetype:, intitle:).

  • Active recon touches the target: DNS zone transfer attempt (AXFR), subdomain brute force with wordlists (amass, subfinder, dnsx), virtual host discovery, and port scanning of authorized ranges only.

  • Technology fingerprinting signals: Server and X-Powered-By headers, cookie names (PHPSESSID, JSESSIONID, ASP.NET_SessionId), error page formats, favicon hash (mmh3), and static asset paths.

  • Content discovery uses directory/file brute forcing (ffuf, feroxbuster, gobuster) with status-code and size filters; 403 responses often indicate a resource exists but is access-controlled, 301/302 indicate redirects worth following.

  • robots.txt, sitemap.xml, .well-known/, and security.txt disclose intended and unintended paths; backup extensions (.bak, .old, ~, .swp, .zip) frequently expose source code.

  • JavaScript analysis: extract endpoints from bundles with linkfinder-style regex, check source maps (.map) for original code, and identify API base URLs and hidden parameters.

  • Google dorks map to exposure classes: filetype:env, filetype:sql, filetype:log, inurl:admin, inurl:.git, intitle:index.of, ext:php inurl:id=.

  • WAF detection via response headers, cookie behavior, and payload reflection differences; a WAF changes exploitation strategy (encoding, case variation, chunked transfer) but not vulnerability existence.

  • Enumeration of APIs: fetch /swagger.json, /openapi.json, /api-docs, /graphql with introspection query, and check HTTP methods per endpoint with OPTIONS.

Quick reference

Web Application Vulnerability Identification and Exploitation

  • SQL injection classes: in-band (union, error-based), blind (boolean, time-based); union requires matching column count and compatible types, determined by ORDER BY n or UNION SELECT NULL iteration.

  • NoSQL injection in MongoDB-style apps uses operator injection ($ne, $gt, $regex) in JSON bodies or query strings; authentication bypass is typically {"username":{"$ne":null},"password":{"$ne":null}}.

  • XSS types: reflected, stored, DOM-based (sink such as innerHTML, document.write, eval). Context determines payload: HTML body, attribute, JavaScript string, URL, CSS. CSP and HttpOnly limit impact, not existence.

  • CSRF requires a state-changing request with cookie-based auth and no unpredictable token or SameSite protection; PoC is an auto-submitting HTML form hosted cross-origin.

  • SSRF: test parameters that accept URLs or hostnames; bypass filters with decimal/octal IP, DNS rebinding, redirects, and IPv6-mapped addresses; cloud metadata endpoint 169.254.169.254 is the high-impact target.

  • XXE requires an XML parser with external entity resolution; test with a SYSTEM entity referencing a local file, then escalate to out-of-band via an external DTD for blind cases.

  • File upload bypass: content-type header, magic bytes, double extensions (.php.jpg), null byte, .htaccess upload, and filename path traversal. Execution depends on server config, so verify, do not assume.

  • Path traversal and LFI: ../ sequences, encoded variants (%2e%2e%2f, ..%5c), absolute paths, and PHP wrappers (php://filter, php://input, data://) where allow_url_include is on.

  • IDOR/BOLA: change object identifiers in requests and compare responses across two accounts with different privileges; the test is authorization, not identifier guessability.

  • Command injection: shell metacharacters (; | & $() `` \n) in parameters passed to system calls; blind detection via time delay (sleep, ping -c) or out-of-band DNS interaction.

  • Deserialization: Java (ysoserial gadget chains), PHP (PHPGGC), .NET (ysoserial.net), Python pickle. Look for base64 blobs in cookies, viewstate, and hidden fields.

  • JWT attacks: alg:none, algorithm confusion (RS256 to HS256 using the public key as HMAC secret), weak HMAC secret cracking with hashcat/john, and kid/jku header injection.

Quick reference

Web Application Exploitation and Reporting

  • Post-exploitation on a web app stays within scope: enumerate the DB (information_schema, current user privileges), read app config for credentials, and check for file read/write primitives (INTO OUTFILE, LOAD_FILE).

  • Privilege escalation from web shell: identify OS user, kernel version, sudo rights, cron jobs, writable service paths, and SUID binaries; document each step with command output.

  • Lateral movement and pivoting require explicit authorization; tunneling (SSH -L/-R/-D, chisel, socat) is documented as a technique with the exact command and affected hosts.

  • Evidence standard: for each finding, capture the full HTTP request and response, the exact payload, timestamps, affected URL/parameter, and reproduction steps that a third party can follow.

  • Report structure: executive summary (business risk, counts by severity), methodology and scope, findings ordered by severity, each with description, evidence, impact, remediation, and references.

  • Remediation guidance must be specific: parameterized queries rather than 'sanitize input'; output encoding by context; allowlist validation; least-privilege DB accounts; security headers (CSP, HSTS, X-Content-Type-Options).

  • CVSS v3.1 vector strings must be consistent with the report narrative; a stored XSS requiring admin interaction is typically S:C with UI:R, not a critical unauthenticated RCE.

  • Retest verifies the fix addresses root cause, not just the reported payload; note residual risk and any new issues introduced by the fix.

  • Data handling: reports and evidence containing credentials or PII are encrypted, shared only with named recipients, and deleted per the retention clause agreed in the rules of engagement.