wooyun-legacy

# WooYun Vulnerability Analysis Knowledge Base

Methodology and testing patterns extracted from 88,636 real-world
vulnerability cases reported to the WooYun platform (2010-2016).

---

## When to Use

> All testing described here must be performed only against systems you
> have written authorization to test.

- Penetration testing web applications
- Security code review (server-side or client-side)
- Vulnerability research against web targets you have explicit authorization to test
- Building security test cases or checklists
- Assessing web application attack surface
- Reviewing remediation effectiveness
- Training or education in authorized security testing contexts

## When NOT to Use

- Network infrastructure testing (firewalls, routers, switches)
- Mobile application binary analysis
- Malware analysis or reverse engineering
- Compliance-only assessments (PCI-DSS, SOC2 checklists without testing)
- Physical security assessments
- Social engineering campaigns
- Cloud infrastructure misconfigurations (IAM, S3 buckets) — these
  require cloud-specific tooling, not web vuln patterns

## Rationalizations to Reject

These shortcuts lead to missed findings. Reject them:

- "The WAF will catch it" — WAFs are bypass-able; test the application
  logic, not the middleware
- "It's an internal app, so auth doesn't matter" — internal apps get
  compromised via SSRF, lateral movement, and credential reuse
- "We already use parameterized queries everywhere" — check for ORM
  misuse, stored procedures with dynamic SQL, and second-order injection
- "The framework handles XSS" — template engines have raw output modes,
  JavaScript contexts bypass HTML encoding, and DOM XSS lives
  entirely client-side
- "File uploads are safe because we check the extension" — extension
  checks are bypassed via null bytes, double extensions, parser
  discrepancies, and race conditions
- "We validate on the frontend" — client-side validation is a UX
  feature, not a security control
- "Nobody would guess that URL" — security through obscurity fails
  against directory bruteforcing, referrer leaks, and JS source analysis
- "Low severity, not worth reporting" — low-severity findings chain
  into critical attack paths

---

## Core Mental Model

```
Vulnerability = Expected Behavior - Actual Behavior
             = Developer Assumptions + Attacker Input -> Unexpected State

Analysis chain:
1. Where does data come from?  (Input sources)
   -> GET/POST/Cookie/Header/File/WebSocket
2. Where does data flow?       (Data path)
   -> Validation -> Processing -> Storage -> Output
3. Where is data trusted?      (Trust boundaries)
   -> Client / Server / Database / OS / External service
4. How is data processed?      (Processing logic)
   -> Filter / Escape / Validate / Execute
5. Where does data end up?     (Output sinks)
   -> HTML / SQL / Shell / Filesystem / Log / Email
```

---

## Attack Surface Mapping

```
              +-------------------------------------------+
              |         Application Attack Surface         |
              +-------------------------------------------+
                                  |
          +-----------------------+-----------------------+
          |                       |                       |
     +----v----+            +-----v-----+           +-----v-----+
     |  Input  |            | Processing|           |  Output   |
     +---------+            +-----------+           +-----------+
     | GET     |            | Input     |           | HTML page |
     | POST    |    ->      | validation|    ->     | JSON resp |
     | Cookie  |            | Biz logic |           | File DL   |
     | Headers |            | DB query  |           | Error msg |
     | File    |            | File op   |           | Log entry |
     | Upload  |            | Sys call  |           | Email     |
     +---------+            +-----------+           +-----------+
```

---

## SQL Injection

**Cases:** 27,732 | **Reference:** [sql-injection.md]({baseDir}/references/sql-injection.md)
| **Checklist:** [sql-injection-checklist.md]({baseDir}/references/checklists/sql-injection-checklist.md)

High-risk parameters: `id`, `sort_id`, `username`, `password`, `search`,
`keyword`, `page`, `order`, `cat_id`

Injection point detection:
- String terminators: `'  "  )  ')  ")  --  #  /*`
- DB fingerprint: `@@version` (MSSQL), `version()` (MySQL),
  `v$version` (Oracle)

Bypass techniques:
- Whitespace: `/**/  %09  %0a  ()`
- Keywords: `SeLeCt  sel%00ect  /*!select*/`
- Equals: `LIKE  REGEXP  BETWEEN  IN`
- Quotes: `0x` hex, `char()`, `concat()`

Core defense: parameterized queries (PreparedStatement / ORM binding).

---

## Cross-Site Scripting (XSS)

**Cases:** 7,532 | **Reference:** [xss.md]({baseDir}/references/xss.md)
| **Checklist:** [xss-checklist.md]({baseDir}/references/checklists/xss-checklist.md)

Output points: user profile fields (nickname, bio), search reflections,
file metadata (filename, alt text), email content (subject, body)

Bypass techniques:
- Tag mutation: `<ScRiPt>  <script/x>  <script\n>`
- Event handlers: `onerror  onload  onmouseover  onfocus`
- Encoding: HTML entities, JS Unicode, URL encoding
- Protocol handlers: `javascript:  data:  vbscript:`

Core defense: context-aware output encoding + Content Security Policy.

---

## Command Execution

**Cases:** 6,826 | **Reference:** [command-execution.md]({baseDir}/references/command-execution.md)
| **Checklist:** [command-execution-checklist.md]({baseDir}/references/checklists/command-execution-checklist.md)

Entry points: system command wrappers (ping, traceroute, nslookup),
file operations (compress, decompress, image processing), code eval
(`eval`, `assert`, `preg_replace(/e)`), framework vulnerabilities
(Struts2, WebLogic, JBoss)

Command chaining:
- Linux: `;  |  ||  &&  \`  $()`
- Windows: `&  |  ||  &&`

Bypass techniques:
- Whitespace: `${IFS}  $IFS$9  %09  <  <>`
- Keywords: `ca\t  ca''t  c$@at  /???/??t`
- Encoding: `$(printf "\x63\x61\x74")`,
  `` `echo Y2F0|base64 -d` ``

Core defense: avoid shell invocation; use `execFile` over `exec`,
allowlist acceptable inputs.

---

## File Upload

**Cases:** 2,711 | **Reference:** [file-upload.md]({baseDir}/references/file-upload.md)
| **Checklist:** [file-upload-checklist.md]({baseDir}/references/checklists/file-upload-checklist.md)

Bypass detection:
- Client-side validation: modify JS or send request directly
- Content-Type: `image/gif` header + PHP code body
- Extension: `.php5  .phtml  .pht  .php.  .php::$DATA`
- Content inspection: `GIF89a` + `<?php` or image-based webshell
- Parser discrepancy: `/upload/1.asp;.jpg` (IIS 6.0)

Parser-specific vulnerabilities:
- IIS 6.0: `/test.asp/1.jpg`, `test.asp;.jpg`
- Apache: `.php.xxx` (unknown extension fallback)
- Nginx: `/1.jpg/1.php` (`cgi.fix_pathinfo`)
- Tomcat: `test.jsp%00.jpg`

Core defense: allowlist extensions, rename uploads, store outside
webroot, validate content type server-side.

---

## Path Traversal

**Cases:** 2,854 | **Reference:** [path-traversal.md]({baseDir}/references/path-traversal.md)
| **Checklist:** [path-traversal-checklist.md]({baseDir}/references/checklists/path-traversal-checklist.md)

High-risk parameters: `file`, `path`, `filename`, `url`, `dir`,
`template`, `page`, `include`, `download`

Traversal payloads:
- Basic: `../../../etc/passwd`
- Encoded: `%2e%2e%2f`, `..%252f`, `%c0%ae%c0%ae/`
- Null byte: `../../../etc/passwd%00.jpg`
- Windows: `..\..\..\windows\win.ini`

Target files (Linux): `/etc/passwd`, `/etc/shadow`,
`/proc/self/environ`, `/var/log/apache2/access.log`

Core defense: resolve canonical paths, validate against allowlisted
directories, never use user input in file paths directly.

---

## Unauthorized Access

**Cases:** 14,377 | **Reference:** [unauthorized-access.md]({baseDir}/references/unauthorized-access.md)
| **Checklist:** [unauthorized-access-checklist.md]({baseDir}/references/checklists/unauthorized-access-checklist.md)

Access types:
- Admin panel exposure: `/admin`, `/manager`, `/console`
- API without authentication: missing token validation, predictable
  tokens
- Exposed services: Redis (6379), MongoDB (27017),
  Elasticsearch (9200), Memcached (11211), Docker (2375)
- IDOR: horizontal privilege escalation via ID enumeration

Core defense: authentication + authorization on every endpoint,
session management, principle of least privilege.

---

## Information Disclosure

**Cases:** 7,337 | **Reference:** [info-disclosure.md]({baseDir}/references/info-disclosure.md)
| **Checklist:** [info-disclosure-checklist.md]({baseDir}/references/checklists/info-disclosure-checklist.md)

Disclosure sources: error messages with stack traces, exposed `.git`
or `.svn` directories, backup files (`.bak`, `.sql`, `.tar.gz`),
configuration files, debug endpoints, directory listings

Core defense: custom error pages, disable directory listing, remove
debug endpoints in production, audit publicly accessible files.

---

## Business Logic Flaws

**Cases:** 8,292 | **Reference:** [logic-flaws.md]({baseDir}/references/logic-flaws.md)
| **Checklist:** [logic-flaws-checklist.md]({baseDir}/references/checklists/logic-flaws-checklist.md)

Vulnerability patterns:
- Password reset: verification code in response body, step skipping,
  controllable reset tokens
- Authorization bypass: horizontal (ID enumeration), vertical (role
  escalation)
- Payment logic: amount tampering, quantity manipulation, coupon
  stacking
- CAPTCHA: not refreshed, reusable, brute-forceable, client-side only

Testing approach:
1. Map the business flow -> draw state transition diagram
2. Identify critical checks -> which parameters determine outcomes
3. Attempt bypass -> modify parameters / skip steps / replay / race
4. Verify impact -> prove the scope of harm

Core defense: server-side validation of all business-critical logic.

---

## Additional Categories

These categories are derived from case data without full reference
documents. Each has a testing checklist extracted from real cases.

| Category | Checklist |
|----------|-----------|
| CSRF | [csrf-checklist.md]({baseDir}/references/checklists/csrf-checklist.md) |
| SSRF | [ssrf-checklist.md]({baseDir}/references/checklists/ssrf-checklist.md) |
| Weak Passwords | [weak-password-checklist.md]({baseDir}/references/checklists/weak-password-checklist.md) |
| Misconfiguration | [misconfig-checklist.md]({baseDir}/references/checklists/misconfig-checklist.md) |
| Remote Code Execution | [rce-checklist.md]({baseDir}/references/checklists/rce-checklist.md) |
| XML External Entity (XXE) | [xxe-checklist.md]({baseDir}/references/checklists/xxe-checklist.md) |

> **Note:** The RCE checklist covers deserialization, OGNL injection, and
> framework-specific remote code execution — distinct from the OS command
> injection focus of the Command Execution reference above.

---

## Methodology Case Studies

Real-world penetration testing methodology examples (anonymized):

| Case Study | Description |
|------------|-------------|
| [bank-penetration.md]({baseDir}/references/bank-penetration.md) | Multi-stage attack chain against a financial institution |
| [telecom-penetration.md]({baseDir}/references/telecom-penetration.md) | Infrastructure penetration of a telecom carrier |

These demonstrate how individual vulnerabilities chain together into
full compromise scenarios.

---

## Testing Priority Framework

### High Priority (test first)

1. **SQL Injection** — direct data access, highest case count (27,732)
2. **Command Execution** — OS-level compromise
3. **File Upload** — arbitrary code execution via webshell

### Medium Priority

4. **Unauthorized Access** — second-highest case count (14,377)
5. **Business Logic Flaws** — application-specific, hard to automate
6. **XSS** — session hijacking, phishing

### Lower Priority (but still important)

7. **Path Traversal** — file read, sometimes write
8. **Information Disclosure** — reconnaissance value, enables chaining
9. **CSRF/SSRF/XXE** — context-dependent severity

---

## Defense Quick Reference

| Vulnerability | Core Defense | Implementation |
|---------------|-------------|----------------|
| SQL Injection | Parameterized queries | PreparedStatement / ORM |
| XSS | Output encoding | Context-aware escaping + CSP |
| Command Execution | Avoid shell | `execFile` not `exec`, allowlist |
| File Upload | Strict validation | Allowlist ext, rename, isolate |
| Path Traversal | Canonical paths | Resolve + validate against allowlist |
| Unauthorized Access | Access control | AuthN + AuthZ + session mgmt |
| Logic Flaws | Server-side checks | Validate all business logic server-side |
| Info Disclosure | Minimize exposure | Custom errors, no debug in prod |

---

## Key Insight

All 88,636 vulnerabilities in this database share a common root cause:
the gap between what developers assumed and what attackers actually
provided. Effective security testing means systematically challenging
every assumption at every trust boundary.

Four principles from the data:
1. **Boundary thinking** — all vulnerabilities occur at trust boundaries
2. **Data flow tracing** — follow data from input to output completely
3. **Assumption challenging** — question every "obvious" validation
4. **Chain composition** — individual low-severity findings combine
   into critical attack paths