SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsctf-web-methodology

ctf-web-methodology

General & other

View repository

Updated 10-16 06:52

About this skill

CTF Web challenge methodology

In-depth references

The following reference materialsLoad on demand, select the corresponding file based on the challenge type identified in Phase 2:

CTF Web challenges and real penetration testing are fundamentally different: the objective is clear (get the flag), the vulnerability is intentionally placed, and there is usually only one entry point. This methodology helps you quickly identify the challenge type and choose the shortest path.

Core mental model

The essence of CTF is puzzle solving. The author intentionally left an attack path, and your task is to find it.

Key principles:

  1. Breadth before depth — spend 2-3 rounds quickly surveying the whole picture, then go deep into specific vulnerabilities
  2. Clue-driven — the result of each step tells you what to do next
  3. 3-round rule — if a method has been tried for 3 rounds with no substantial progress, switch direction
  4. Don't guess blindly — if brute force is needed, it means you may have gone in the wrong direction (CTF usually has a clever solution)

Phase 1: Rapid reconnaissance (1-3 rounds)

Execute by priority (not all of it; if you find something, stop and analyze):

  1. Visit the homepage — http_request GET the homepage and observe:

    • What kind of application is it? (login page/blog/shop/API)
    • What functions does it have? (search/upload/register/comment)
    • Are there any hints at the bottom of the page/in comments?

  2. View the source code — check the HTML source code (not the rendered page):

    • HTML comments <!-- hint: ... -->
    • Hidden form fields <input type="hidden">
    • API paths and variables in JavaScript
    • Referenced JS/CSS file paths

  3. Path probing — Check common paths:

    • /robots.txt — Often hides sensitive paths with forbidden access
    • /flag, /flag.txt, /flag.php
    • /.git/, /.svn/ — Source code disclosure
    • /backup.sql, /www.zip, /源码.tar.gz
    • /admin, /login, /api

  4. Fingerprinting — httpx -tech-detect or curl -sI Identify the tech stack

Phase 2: Challenge Type Identification and Strategy Selection

Based on reconnaissance results, quickly categorize:

What you see What it might be Next step
Search box/query parameters SQL injection Read sql-injection-methodology
Login page Weak passwords/SQL injection/JWT First follow the CSRF-safe login flow, then try SQLi
File upload functionality File upload vulnerability Read file-upload-methodology
Template rendering/user input echo SSTI/XSS Try {{7*7}} and ${7*7}
File path parameter in URL LFI/directory traversal Try ../../etc/passwd
Deserialized data (base64 cookie) Deserialization RCE Read deserialization-methodology
API endpoint + JSON IDOR/authorization bypass Read idor-methodology
JWT token（eyJ...） JWT attack Read jwt-attack-methodology
Source code visible (.git disclosure, etc.) Source code audit Read ctf-source-audit
ping/curl functionality Command injection Read command-injection-methodology
XML input/SOAP XXE Read xxe-injection-methodology
URL/file path parameter SSRF Read ssrf-methodology

Phase 2.5: CSRF-Safe Login Flow (Critical!)

Many web applications (DVWA, WordPress, etc.) have login forms with CSRF tokens (user_token、csrf_token、_token and other hidden fields).If you do not first GET to obtain the token and then POST within the same session, login will fail even if the password is correct.

Correct flow (http_request automatically manages cookies)

Example

1. GET /login.php              ← 获取页面，自动保存 session cookie
2. 从响应 HTML 提取 user_token 值
3. POST /login.php             ← 自动携带同一 session cookie
   body: username=admin&password=password&Login=Login&user_token=<提取的值>
4. 验证：响应不再是登录页面（body 大小变化、出现 Welcome/Dashboard）

Common pitfalls

  • New session for each request — If GET and POST are not in the same session, token validation will inevitably fail (the server-side token is bound to the session)
  • Token name is not fixed — It may be user_token、csrf_token、_token、csrfmiddlewaretoken
  • Token is in a meta tag — <meta name="csrf-token" content="...">, not necessarily in the form
  • Configuration needs to be changed after login(such as DVWA security level) — You must continue operating in the same session, otherwise the change will be lost

Determine whether login succeeded

  • Response body size changes significantly (e.g., 1523→7274 bytes)
  • Appearance of keywords such as Welcome、Dashboard、Logout and other keywords
  • No longer appears Login form

Phase 3: Exploitation

  • SQL injection:UNION SELECT preferred, EXTRACTVALUE as fallback
  • Command injection:Directly cat /flag.txt, don't bother with a reverse shell
  • When continuous interaction is needed (reverse shell/SSH/database), use the interactive_session tool instead of bash+nc
  • LFI：read /flag.txt directly, don't read /etc/passwd first
  • fake flag — flag{test} is not the real flag;multi-layer vulnerability — use LFI to get the source code, then dig for a second hole
  • WAF bypass — case/double-write/comment /*!select*/；encoding — URL/double/Unicode

Phase 4: Strategy switching

  • Tried 5 variants of the same payload without success → change direction
  • SQL injection confirmed but cannot read files → the flag is in the database
  • Feels like "almost there" but it doesn't work → the most dangerous signal, step back and re-examine

Vulnerability type determination

  • Observe functionality: a display feature is not SQL injection (it's not a query), it may be SSTI/XSS

Efficiency trap

  • When the complete data has no length limit, segmented extraction is not needed
  • Segmented concatenation is error-prone, and manual concatenation carries risk