CTF Web Exploitation

First Workflow

1. Record target URL, source code, routes, tech stack, cookies, headers, and flag format.
2. Map the app like a user: register/login/logout, role changes, hidden pages, error pages.
3. Capture requests with curl/browser; preserve cookies and CSRF tokens.
4. Read source for trust boundaries: input → parser → DB/files/template/shell/deserializer/fetch.
5. Try safe low-noise probes before brute force.
6. Build a minimal reproducible exploit script with requests.

Bug Family Checklist (Updated 2025-2026)

• Auth/session: default creds, weak invite codes, IDOR, role cookie, JWT none/alg confusion/weak secret/JWK/JKU/KID injection, reset-token flaws, OAuth/OIDC email subaddressing bypass, SAML assertion replay.
• Injection: SQL/NoSQL/LDAP/XPath/command/header injection, CRLF, SSTI, Prototype Pollution (client & server-side), GraphQL injection/batching abuse, React Server Components RCE (CVE-2025-55182).
• File bugs: path traversal, LFI/RFI, upload extension/content-type/polyglot, zip slip, BMP pixel webshell + filename truncation, PHP zip:// LFI via PNG/ZIP polyglot, DOCX/Office XML XXE.
• SSRF: metadata endpoints, localhost admin panels, DNS rebinding-like filters, URL parser confusion, whois -h flag SSRF to Redis (inject -h 127.0.0.1 -p 6379 to execute arbitrary Redis commands via whois CLI arguments), Next.js Middleware SSRF (CVE-2025-57822, CVE-2026-44578), HTTP/2 → HTTP/1.1 downgrade smuggling (H2.TE, H2.CL), GraphQL SSRF via field aliases, WebSocket upgrade SSRF.
• XSS/CSRF: reflected/stored/DOM, CSP bypass, postMessage, admin bot exfil, AngularJS sandbox escape, Chrome Unicode URL normalization bypass, CSS font glyph container query exfil, Hyperscript CDN CSP bypass, DOM clobbering.
• Deserialization: pickle, PHP serialize, Java, Node, YAML, signed-but-not-encrypted cookies, PHP type juggling, PHP assert() string eval, PHP extract() variable overwrite, Node.js VM escape, Insecure pickle deserialization (Glances CVE-2026-46607).
• Request smuggling/cache: header ambiguity, cache poisoning, host header injection, HTTP/2 request smuggling (H2.TE, H2.CL, H2.TE.CL), h2c smuggling via cleartext HTTP/2 upgrade, Apache mod_proxy rewrite chain smuggling (CVE-2023-25690).
• Race/logic: coupon reuse, TOCTOU, double submit, payment/order state confusion, Mass assignment (A01:2025), Business logic bypass via HTTP verb tampering, Race condition leak via information_schema.processlist.
• Supply chain / Modern: Software Supply Chain Failures (A03:2025), npm transitive dependency attacks (axios, etc.), Web3/Solidity reentrancy, delegatecall, transient storage collisions, Groth16 proof forgery, LLM prompt injection / jailbreak in AI-powered CTF challenges, AI-generated code vulnerabilities.
• Crypto/encoding: Hash length extension (hashpumpy), PBKDF2 prefix timing oracle, Affine cipher OTP brute-force, JWT algorithm confusion with JWK injection.

Default Tools

python3 -m pip install --user requests beautifulsoup4 pyjwt flask-unsign itsdangerous sqlmap

Use browser automation for JS-heavy challenges and curl -i for exact headers.

Reference Files

• references/web-attack-playbook.md — bug families, probes, payloads, and exploitation patterns.
• references/source-review-checklist.md — source-code audit checklist for web CTF apps.
• references/public-hackathon-web-audit.md — authorized multi-target public web audit workflow, false-positive guards, XSS reflection validation ladder, and submission-ready report fields/reproduction steps.
• references/public-web-audit-workflow.md — staged workflow for authorized public web hackathon audits: passive baseline, high-value exposure checks, JS/API/source-map extraction, parameter reflection/open-redirect probes, reporting discipline, and false-positive filters.
• references/public-hackathon-high-risk-validation.md — high-severity validation discipline for public hackathon audits: avoiding inflated High counts, frontend secret/source-map false-positive filters, API/CORS/CMS confirmation rules, and report wording when fewer Highs are defensible.
• references/public-hackathon-deep-audit-reporting-lessons.md — continuation-round lessons for authorized multi-target audits: baseline merging, candidate appendices, DOM-XSS/vendor false-positive filters, timeout reruns, second-round low-noise probes, and defensible deduplication.
• references/tainan-public-hackathon-lessons.md — session-derived lessons for many-target public hackathon audits: submission-ready report fields, High-risk validation guardrails, breadth-to-depth workflow, and Chinese/direct reporting expectations.
• references/public-hackathon-per-site-high-risk-deep-dive.md — per-site High-risk deep-dive workflow for authorized many-target audits: per-site subprocess timeouts, focused timeout rescans, high-impact checks, false-positive filters for Axios/plugin/localhost tokens, and reporting shape.
• references/public-hackathon-report-packaging.md — post-audit packaging workflow: split verified findings by High/Medium/Low, keep Markdown+CSV outputs, add detailed explanations to High/Medium rows, and preserve non-destructive verification language.
• references/playbook-file-upload-to-rce.md — file upload bypass to RCE chain.
• references/playbook-command-injection-bypass.md — command injection bypass cheatsheet (space, separator, keyword, encoding, blind).
• references/playbook-php-bypass-cheatsheet.md — PHP-specific filter bypasses.
• references/playbook-eval-rce-techniques.md — PHP eval()/RCE patterns and output-order pitfalls.
• references/playbook-source-code-extraction.md — source code retrieval via LFI, git, backup files, .DS_Store.
• references/playbook-payload-reference.md — compact payload templates (SQLi, CMDi, LFI, JWT, XXE, CTFd workflow).
• references/playbook-ssti-injection-chains.md — SSTI engine fingerprint + exploit chains (Jinja2, Twig, ERB, Freemarker, Mako, Thymeleaf, Vue, Smarty).
• references/playbook-deserialization.md — deserialization gadget chains (PHP, Java, Python).
• references/playbook-php-code-audit-checklist.md — PHP code audit checklist.
• references/playbook-web-ctf-quick-reference.md — quick flag locations, first-pass workflow, common headers, chain shapes, encodings.
• references/playbook-prototype-pollution.md — NEW 2025: Prototype Pollution detection, filter bypass (toString.isAdmin=1 via typeof check bypass), gadget chains, server-side RCE paths.
• references/playbook-http2-smuggling.md — NEW 2025: HTTP/2 request smuggling (H2.TE, H2.CL, H2.TE.CL), downgrade attacks, h2c smuggling, CVE-2023-25690.
• references/playbook-nextjs-ssrf.md — NEW 2025-2026: Next.js Middleware SSRF (CVE-2025-57822, CVE-2026-44578), header injection via X-Middleware-Rewrite, WebSocket upgrade SSRF.
• references/playbook-graphql-ctf.md — NEW 2025: GraphQL introspection bypass, schema enumeration without introspection, mutation abuse, batching attacks, field aliasing for data exfiltration.
• references/playbook-supply-chain.md — NEW 2025: Software supply chain failures (A03:2025), transitive dependency attacks, malicious package detection.
• references/playbook-ai-web-vulns.md — NEW 2025-2026: LLM prompt injection in web apps, AI-generated code vulns, RAG poisoning.
• references/playbook-web3-solidity.md — NEW 2025: Solidity <0.8 integer overflow, reentrancy, delegatecall, transient storage collisions.
• references/cve-2024-2961-exploitation.md — PHP CVE-2024-2961 (CNEXT) iconv OOB exploitation via php://filter, blind OOM oracle, hardening patches bypass.
• references/playbook-redis-ssrf-to-ssti.md — NEW 2026: Redis SSRF via whois -h flag injection → RDB file write to template directory → Go SSTI via {{...}} blocks in RDB string values. Covers checksum pitfalls, nil-context handling, input jail bypass, and CTF-Instancer instance management.
• references/jeajax-php-rce-attempt-2026-07-14.md — 2026-07-14 (two sessions): Heart.okgood.biz pentest findings. jeajax.php definitive characterization (pure text-echo, NOT SQL), XSS in msg parameter, login/auth architecture (msg_out.php/msg=886 flow), fetch() redirect:manual pitfall, XSS auto-brute payload, PHP 5.6.40 error disclosure via mkdir().

Practical lessons: write-up reproduction with screenshots

When the user asks to reproduce another CTF write-up and create an original write-up, treat it as both exploitation and documentation work:

1. Read the provided write-up and inventory its assets before touching the target; preserve the original structure only as reference, then write a distinct explanation in the user's language.
2. Re-solve the challenge against the live endpoint or saved artifact and verify the flag with an exploit script/output, not just by copying the prior write-up.
3. Capture natural evidence screenshots during the actual flow: target homepage, reasoning/proof terminal output, exploit output, and final flag/source page. Use real browser/page screenshots when possible; terminal-style diagrams are acceptable only for reasoning steps, not as substitutes for final exploit evidence.
4. Put outputs in a self-contained folder with writeup_assets/, the Markdown write-up, exploit script, raw response/source dump, and captured command output; verify all referenced images and files exist before finalizing.
5. Include enough code in the write-up to reproduce the exploit, but keep the narrative focused on the vulnerability chain and why each block/request works.

Practical lessons: source-provided service triage

When a web CTF provides source plus a live endpoint, do a parallel source/live plan instead of guessing from UI alone:

1. Inventory routes, auth middleware, DB schema/init scripts, deployment config, and environment-variable substitutions.
2. Identify which data is fake in artifacts and where the live flag/password is injected at runtime.
3. Build a requests.Session() exploit that performs normal user actions first, then the minimal exploit request.
4. Keep browser/Playwright for Cloudflare, login state, and flag submission; keep exploit logic in small Python scripts for reproducibility.

Useful patterns encountered in picoCTF-style services:

• Flask 2FA/session state bugs: inspect when session['username'] is set versus when session['logged'] becomes true. If admin username is stored before OTP verification, test Flask cookie signing/secret exposure, session tampering, or routes that trust username more than logged state. With users.db, inspect two_fa, password hashes, and possible weak secrets before online brute force.
• HAProxy backup service challenges: if source says only backup has the flag and HAProxy config marks server s2 ... backup, look for ways to make primary health checks fail. Global rate limits returning 503 can affect HAProxy httpchk; controlled request floods may trigger failover to backup. Verify with low-duration bursts and stop as soon as the flag/backup marker appears.
• Node/PostgreSQL secret vaults: when login uses parameterized queries but a later insert interpolates content directly, register/login normally, then exploit the authenticated sink. Check whether the driver permits stacked statements; otherwise pivot to INSERT ... SELECT, token ownership changes, or error-based extraction. DB init files often contain fake flags while db.js/entrypoint updates admin password and flag from environment variables at runtime.
• Blockchain integer overflow web UIs: Solidity <0.8 does not auto-check overflow. If a reveal condition tests newBalance < amount after balance += amount, deposit near 2**256 - 1 then deposit again to wrap and trigger flag emission/getter.

Practical lessons: CTF write-up reproduction with screenshots

When the user asks to re-solve from an existing write-up and produce a new write-up with screenshots:

1. Read the provided write-up and assets first, then independently verify the exploit against the live target where authorized.
2. Preserve the user's requested style: screenshots should be natural captures of real browser/terminal states, not diagram-like or artificially drawn mockups.
3. Capture the whole solve flow, not just the flag: homepage, normal app behavior, exploit construction/output, forged request/cookie state when useful, vulnerable source/code path, and final flag.
4. Include both reasoning and a runnable script in the final write-up. Avoid only copying the previous write-up; explain the exploit in the new author's words.
5. If cookies are HttpOnly or browser APIs refuse setting a specific framework cookie name, verify exploit state with direct HTTP tooling (curl/requests) and use browser screenshots for naturally visible pages.

Practical lessons: AES-ECB encrypted cookie oracles

For web CTFs where the server returns an encrypted cookie for attacker-controlled input:

1. Identify the exact plaintext being encrypted, including server-added suffixes such as .txt.
2. Use block alignment to make a target plaintext block appear at a chosen ciphertext block offset.
3. Obtain a valid padding block separately by choosing input whose final plaintext block is exactly full, so PKCS#7 adds a full 0x10 * 16 block.
4. Splice ECB blocks as E(target_block) || E(padding_block) when the decryptor lacks MAC/signature validation.
5. Combine with path handling bugs: in Python, os.path.join(base, absolute_path) discards base, so an unlocked filename beginning with / can bypass a data directory if direct front-end validation can be avoided.

CTF write-up deliverable pitfalls

When producing a write-up from a user-provided reference folder:

• Preserve the challenge metadata from the reference exactly (especially the displayed challenge name), even if the live URL or route suggests a different internal name.
• Write outputs under the exact directory tree the user provided. Use the supplied absolute path as the destination unless asked otherwise.
• Screenshots in write-ups must be real direct screenshots of the browser/page/tool state. Do not create drawn/mock/terminal-styled images as substitutes unless the user explicitly asks for a diagram. If a screenshot is needed, navigate to the actual page or opened artifact and capture it directly; keep captions honest (e.g. “direct browser screenshot”).
• If using a saved HTTP response to show a browser-rendered result, open that exact response in the browser and capture the page directly. Avoid adding annotations, fake chrome, generated terminal windows, or reconstructed visuals.
• After corrections, remove or replace stale image references in the Markdown; verify that every referenced image exists and that removed/generated substitutes are no longer referenced.

Public hackathon / many-target audit pattern

When the user is in an authorized hackathon or bug-bounty-style event with many public web targets and asks for many vulnerabilities quickly, start with a low-noise breadth pass before active exploitation. Produce CSV/Markdown rows with title, risk, URL, type, system, CVSS score/URL, source IP, and evidence. Prioritize defensible medium findings such as missing HSTS/HTTPS redirect, missing clickjacking protections, insecure cookie flags, internal URL leakage in public JS/HTML, and exact old front-end component versions. Avoid submitting HTTP-200 false positives for sensitive paths: verify content signatures for /phpinfo.php, /.env, /.git/HEAD, package.json, etc., and remove SPA/custom-error pages from the formal report.

When the user pushes for “more Highs”, run a separate high-risk-focused pass instead of inflating severity: secrets/config/backup/source-map/API-sensitive-data/SQL-error/LFI/debug-log/CORS-with-sensitive-content. Keep a candidate appendix for anything that needs mutation, privileged context, browser execution proof, or uncertain server-side behavior. Formal Highs need a second validation pass and a stable reproduction URL.

High-risk false-positive lessons from Tainan-style public targets:

• Google API keys can be valid High when they are in target-owned inline/custom code with a clear assignment such as GOOGLE_MAP_KEY or a Maps API call. Deduplicate by system/key, not by every page that repeats the key. Do not use the key; report only masked evidence.
• Minified polyfills often contain host, username, password, and port identifiers from URL parser code. Do not report these as DB connection strings unless the context is an actual assigned connection string (Data Source=...;Password=..., jdbc:, etc.).
• Third-party library source maps and DOM sinks (jquery, bootstrap, swiper, highcharts, polyfills) are usually candidates only. Promote source-map findings only when sourcesContent exposes target-owned source, secrets, internal endpoints, or non-public logic.
• SSRF canaries using https://example.com/<marker> are only formal findings if the response contains fetched external page content (for example Example Domain plus the page text), not merely the supplied URL or marker reflected in HTML. Never test metadata/localhost/internal SSRF endpoints on production public targets without explicit authorization.
• For debug/API docs (openapi.json, Swagger, ELMAH, trace endpoints, composer.lock), exact endpoint URLs are reproducible medium findings. Avoid merging away unrelated issues on the same homepage; dedupe by a key appropriate to the class (e.g., same host+exact vulnerable URL for debug/docs, same host+secret for leaked API keys, same host+param/path for reflections).
• If a broad concurrent scan times out on several hosts, follow with a focus pass over high-value paths only. Preserve the previous formal baseline and append only newly verified URLs; do not overwrite or over-dedupe the whole report.

See references/public-hackathon-passive-audit.md for the full workflow, default severity mapping, false-positive checks, and report shape. See references/tainan-public-hackathon-lessons.md for session-specific Tainan audit notes and examples.

1. Keep the previous verified report as the baseline; never overwrite it with a partial rerun. If a timeout-subset or fast-follow scan is needed, merge its new findings back into the already-cleaned baseline.
2. Run low-noise probes for each class: headers/cookies/HSTS/clickjacking, CORS reflection, sensitive-file signatures, JS secrets/internal URLs/source maps, reflected parameter markers, open redirect, SQL-error canaries, LFI/path traversal canaries, and public stack/error disclosure.
3. Add per-target timeouts and progress logging for many-host async scans so slow government sites cannot block the full batch. In Python asyncio, create semaphores inside the running event loop (e.g. in main()), not at import time, to avoid cross-loop Future attached to a different loop failures under older Python versions.
4. Treat high-risk candidates with a second validation pass. De-duplicate high-impact frontend-secret findings by system + leaked secret class, not by every URL where the same key appears; do not inflate duplicate pages into multiple High submissions.
5. Produce both the final cleaned vulnerability table and a type-coverage matrix showing which vulnerability classes were actually found per system. This helps explain why some classes (RCE/SSRF/upload/SQLi) have no confirmed finding without inventing false positives.

See references/public-hackathon-passive-audit.md for the full workflow, default severity mapping, false-positive checks, and report shape.

Maintenance Rule

Patch this skill when a challenge teaches a new payload, parser confusion, framework-specific trick, useful web tooling workflow, or write-up deliverable preference.

Session Lessons Learned (2026-07-14)

Target: http://heart.okgood.biz:8251/playOn/index.php (jeajax.php) — Two-Session Cumulative

Vulnerabilities Confirmed (Definitive):

1. Reflected XSS in msg parameter on index.php — unsanitized, all payload types reflected. Playwright verified: alert(1) fires.
2. Arbitrary Text Write via Path Traversal in jeajax.php — column/word are pure text output parameters, NOT SQL. Response format: 寫入:{column}內容:{word}:完成. Writes succeed to any path (/tmp/, /var/www/html/heart/playOn/) but written content is text-only, NOT web-accessible, and NOT executable.
3. Error-based Path Disclosure — function.php:849 mkdir() error reveals /var/www/html/heart/JC2/function.php; index.php:62 reveals /var/www/html/heart/playOn/index.php.
4. Login form — POST to index.php with u/p, failure redirects to index.php?msg=帳號或密碼不對,錯 (302). No user enumeration: all invalid combos produce identical responses.
5. Post-login endpoints — /playOn/video.php and /playOn/play.php redirect unauthenticated users to msg_out.php?msg=886&accesscheck=... then meta-refresh to index.php?msg=886. msg=886 = auth failure code.
6. phpMyAdmin exposed — /phpmyadmin/ accessible but blocked by PHP 5.6.40 version check (requires 7.1.3+).
7. JC2 directory — /JC2/ returns 403 Forbidden; individual files (jeajax.php) accessible with params.

jeajax.php Definitive Characterization:

• column and word are NOT SQL parameters — they are pure text strings echoed back as 寫入:{column}內容:{word}:完成
• ALL SQLi payloads (UNION, stacked, error-based, time-based) in either parameter produce the same output — the payload text is echoed verbatim
• column with SQL injection syntax like id/**/FROM/**/users/**/WHERE/**/1=1-- just prints that string
• word[]=hello produces 寫入:test內容:Array:完成 (PHP array-to-string conversion)
• Conclusion: jeajax.php is an AJAX text-echo endpoint, likely a logging/debug mechanism, NOT a database write gateway

What Did NOT Work (Both Sessions Combined):

• SQLi in login form: All SQLi auth bypass payloads redirect to msg=帳號或密碼不對,錯 — likely prepared statements or effective escaping
• SQLi in vip parameter: vip is client-side JS navigation (window.location.href="?vip="+n), not server-side SQL
• php://filter LFI: All parameters (msg, ER, accesscheck, column) treat php://filter as literal string, not wrapper
• Session forgery: Writing to /tmp/sess_* via jeajax.php succeeds but session not honored — different session.save_path or format mismatch
• Brute force: 1581 combinations (17 users × 93 passwords) all failed identically
• msg_out.php accesscheck LFI: All path traversal attempts redirect to same index.php?msg=886

PITFALL — fetch() redirect:manual for login testing: When using browser fetch() with redirect: 'manual' to test login credentials, a 302 redirect produces type: "opaqueredirect" with status: 0 and empty body regardless of success or failure. You CANNOT distinguish successful login from failed login by HTTP status alone. The correct approach: check response text for error messages (e.g., "帳號或密碼不對"), or use redirect: 'follow' and inspect the final page content. This pitfall caused a false-positive admin:admin match in this session.

Only Viable Attack Path: Reflected XSS → cookie theft or in-browser auto-brute force. The XSS payload runs in the same origin and can:

• Steal document.cookie (PHPSESSID)
• fetch() POST to index.php to brute-force credentials
• Report results back via new Image().src = '../JC2/jeajax.php?column=FOUND&word=...'
• On success, location.href = 'video.php' to access the post-login backend

Full working XSS auto-brute payload available in references/jeajax-php-rce-attempt-2026-07-14.md.