name: wooyun-legacy description: >- Provides web vulnerability testing methodology distilled from 88,636 real-world cases from the WooYun vulnerability database (2010-2016). Use when performing penetration testing, security audits, code reviews for security flaws, or vulnerability research. Covers SQL injection, XSS, command execution, file upload, path traversal, unauthorized access, information disclosure, and business logic flaws. allowed-tools:

• Read
• Grep
• Glob
• Bash

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 | Checklist: 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 | Checklist: 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 | Checklist: 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 | Checklist: 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 | Checklist: 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 | Checklist: 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 | Checklist: 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 | Checklist: 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.

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):

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

1. Unauthorized Access — second-highest case count (14,377)
2. Business Logic Flaws — application-specific, hard to automate
3. XSS — session hijacking, phishing

Lower Priority (but still important)

1. Path Traversal — file read, sometimes write
2. Information Disclosure — reconnaissance value, enables chaining
3. CSRF/SSRF/XXE — context-dependent severity

Defense Quick Reference

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