WooYun Business Logic Vulnerability Methodology

22,132 real vulnerability cases · 6 domains · 33 vulnerability categories

Extended trigger keywords (not in description due to length limits): Implicit black-box testing: "Is there any problem with this function", "Is there a vulnerability in this process", "How to bypass this restriction", "Order/payment/refund process testing", "Is this system secure", "Is there any risk in the interface", "check this API", "is this flow secure", "review this for issues". Tools & techniques: packet capture analysis, Burp Suite, request interception, parameter modification, replay attack, concurrency testing, ID enumeration, brute force, bonus exploitation, scalping, arbitrage, risk control bypass, SMS bombing, interface abuse, unauthorized interface, arbitrary file operation, data leakage, information collection, subdomain, directory scanning, fingerprint identification, intercept, replay, fuzz, enumerate, brute force, rate limiting bypass, coupon abuse.

Business logic vulnerabilities cannot be detected by scanners. They exist in the gap between the developer's original intention and the actual allowed behavior of the application. This methodology teaches you to think like the developer who writes the code and launch attacks like the user who abuses the application.

Data foundation: WooYun (2010-2016), the largest vulnerability disclosure platform in China.

Vulnerability Severity Priority

Testing should prioritize high-risk vulnerability categories. The following table is sorted by the proportion of high-risk findings in the WooYun dataset — the higher the percentage, the greater the likelihood of critical impact.

Ranking	Vulnerability Category	Number of Cases	High-risk Proportion	Domain
1	Password Reset	777	88.0%	Authentication
2	Arbitrary Account Takeover	220	86.4%	Authorization
3	Withdrawal	59	83.1%	Finance
4	Amount Tampering	176	83.0%	Finance
5	Balance Tampering	113	77.9%	Finance
6	Arbitrary User Registration	24	75.0%	Authorization
7	Logic Vulnerability	266	74.8%	Logic Flow
8	Order Tampering	1,227	74.2%	Finance
9	Price Tampering	70	74.3%	Finance
10	Misconfiguration	1,796	72.6%	Configuration
11	Arbitrary Operation	40	72.5%	Authorization
12	Payment Bypass	1,056	68.7%	Finance
13	Design Defect	1,391	65.3%	Logic Flow
14	Information Disclosure	4,858	64.7%	Information
15	Privilege Escalation	1,705	62.3%	Authorization
16	Weak Password	7,513	58.2%	Authentication

Four-stage Method

Each stage is built on the previous one. Skipping any stage will lead to shallow testing and fail to find logic vulnerabilities that scanners cannot detect.

Phase 1: Business Process Mapping

Before testing any endpoint, understand what the application does and how funds, data, and permissions flow through it.

Understand the business
- What does this application do? (E-commerce, banking, social networking, SaaS)
- Who are the main participants? (Anonymous users, ordinary users, administrators, merchants, API clients)
- What is the revenue model? (How does capital flow?)
- What data is sensitive? (Personal information, financial data, medical data, credentials)
Map user journey
- Registration → Login → Core operation → Logout
- Purchase → Payment → Fulfillment → Refund
- Password reset → Verification → New password
- Administrator → User management → Permission allocation

Identify state transitions

For each business process:
  - List all states (pending review, active, paid, shipped, refunded)
  - List all valid transitions (pending review → paid, paid → shipped)
  - Question: Can invalid transitions be enforced? (Pending review → shipped)
  - Question: Can reverse transitions be performed? (Paid → pending review)

Map trust boundaries
- Client vs server: Which verifications are only performed on the client side?
- User vs administrator: What separates permission levels?
- Tenant vs tenant: What prevents cross-tenant access?
- Internal vs external: What assumes trusted internal sources?

Phase 2: Hypothesis Formulation

Use the reference documents below to form domain-specific hypotheses. Each domain file contains a detailed attack pattern matrix, test checklist, and defense patterns, all derived from thousands of real WooYun cases.

Level 1: Domain Reference (Methodology + Attack Pattern Matrix) — Load first

Domain	Reference File	Number of Cases
Authentication bypass, credential defects	authentication-domain.md	8,846
Permission bypass, IDOR, privilege escalation, arbitrary operation	authorization-domain.md	6,838
Payment, order, balance, price tampering	financial-domain.md	2,919
Personal information leakage, credential leakage, debugging information	information-domain.md	6,446
State machine abuse, race condition, process bypass	logic-flow-domain.md	1,679
Misconfiguration, default settings, hardening defects	configuration-domain.md	1,796

Level 2: In-depth Analysis Manual (Technical Details + Root Cause Analysis) — Load when you need to go deep into a technical field

Technical Domain	Knowledge File	Content
Command Execution	command-execution.md	Complete attack chain of system command injection, code injection, expression injection
File Traversal	file-traversal.md	Bypass techniques for path traversal, arbitrary file read/download
File Upload	file-upload.md	Payload matrix for upload bypass (type, suffix, content detection)
Information Disclosure	info-disclosure.md	Sensitive information exposure paths, debugging interfaces, configuration file leakage
Logic Flaws	logic-flaws.md	Root cause matrix for password reset, payment bypass, verification code bypass
SQL Injection	sql-injection.md	Injection type classification, WAF bypass, blind injection techniques
Unauthorized Access	unauthorized-access.md	Unauthorized interface discovery, permission verification missing patterns
XSS	xss.md	Input points and bypasses for stored/reflected/DOM XSS

Level 3: Vulnerability Case Base (Real Case Titles + High-frequency Payload) — Load when you need to cite specific cases or Payload patterns

Vulnerability Type	Case File	Purpose
SQL Injection	sql-injection.md	15 typical cases + high-frequency injection Payload
Command Execution	command-execution.md	15 typical cases + command execution Payload
Unauthorized Access	unauthorized-access.md	15 typical cases + privilege escalation patterns
Weak Password	weak-password.md	15 typical cases + high-frequency weak passwords
Information Disclosure	info-disclosure.md	15 typical cases + leakage paths
XSS	xss.md	9 typical cases + XSS Payload
Misconfiguration	misconfig.md	15 typical cases + misconfiguration patterns
Logic Flaws	logic-flaws.md	15 typical cases + logic bypass
File Upload	file-upload.md	11 typical cases + upload bypass Payload
SSRF	ssrf.md	SSRF attack patterns
CSRF	csrf.md	CSRF exploitation patterns
File Traversal	file-traversal.md	5 typical cases + traversal Payload
RCE	rce.md	3 typical cases + RCE chain
XXE	xxe.md	XXE injection patterns
Others	other.md	13 typical cases

Progressive loading rule: First read the first level (domain reference) to determine the test direction, then read the second level (in-depth analysis) as needed to obtain technical details, and finally read the third level (case base) only when you need to cite specific cases or Payload patterns. Do not load all files at once.

For each domain, use the following structure to form hypotheses:

Hypothesis: [Business process X] is vulnerable to [attack pattern Y]
Reason: [Evidence from investigation — visible parameters, lack of server verification, predictable ID]
WooYun pattern: [Pattern matching the domain reference]
Impact: [Business impact — financial loss, data leakage, account takeover]
Test: [Specific manual test steps]

Phase 3: Targeted Manual Testing

Business logic requires manual testing, because vulnerabilities exist in the way the application interprets business rules, not in the technical features that scanners can match.

Prepare test accounts
- At least 2 accounts with the same permission level (for horizontal testing)
- At least 1 account for each permission level (for vertical testing)
- Record all session tokens, Cookies, IDs
Perform minimal testing
- Intercept specific requests (Burp/mitmproxy)
- Only modify the parameters to be tested
- Observe: Does the server verify? Does the state change?
- Record the exact request/response pair
Analyze according to business rules
- Does the application implement business rules on the server side?
- Can state transitions be enforced out of order?
- Can another user's resources be accessed/modified?
- Can financial value be tampered with?
If confirmed → Phase 4 · If denied → Next hypothesis · If uncertain → Change method

Phase 4: Impact Assessment and Documentation

Prove business impact, not just technical bypass.

## Finding: [Title]
- Severity: [Critical/High/Medium/Low]
- Domain: [Authentication/Authorization/Finance/Information/Logic/Configuration]
- WooYun pattern: [Historical pattern matched by this finding]
- Business impact: [Financial loss, number of affected users, data scope]
- Reproduction steps:
  1. [Exact steps with request/response]
  2. [...]
- Remediation: [Server-side fix, not client-side band-aid]

Real Cases

These cases illustrate why business logic testing is important — each represents a real vulnerability discovered by WooYun researchers:

Case	Domain	Impact
Privilege escalation in a Beijing Hyundai platform traverses millions of ID cards/driving licenses	Authorization	Millions of ID cards leaked through sequential file IDs
M1905 Movie Network 2588 yuan package vulnerability only costs 50 cents	Finance	5000x price difference achieved through back-end self-approval bypass
TCL unified authentication platform can reset all user passwords	Authentication	Full account takeover across N+ business systems
Weitang main site SQL injection affects more than 8.6 million patients / 460,000 doctors	Information	8.6 million patient records, 460,000 doctor records
China Tietong billing system GetShell + generate recharge cards	Finance	Arbitrary recharge card generation + customer data leakage
Design defect in a Baihe.com APP affects more than 1 million female mobile phone numbers	Logic Flow	More than 1 million phone numbers leaked through design defects

Thinking Traps to Avoid

When testing business logic, be alert to these common rationalizations that lead to shallow testing:

Trap	Reality
"Scanners can cover business logic"	Scanners find features, not logic vulnerabilities. No scanner can find that "order status can skip payment".
"I tested the main process, it is secure"	22,132 cases prove: Logic vulnerabilities exist in edge cases.
"Just change the price to 0.01"	That's just one test. WooYun data shows more than 17 payment attack patterns.
"IDOR is very simple, just change the ID"	IDOR has encoding bypass, parameter pollution, JSON nesting. Simple ID modification only accounts for 30% of cases.
"Front-end verification is done, so there is no problem"	68.7% of payment vulnerabilities exist because verification is only performed on the client side.
"The administrator panel requires different credentials"	58.2% of unauthorized access = management backends with no authentication at all.

Quick Reference

Phase	Key Activities	Threshold Criteria
1. Mapping	Business process, state machine, trust boundary	Complete flow chart has been recorded
2. Hypothesis	Domain-specific theories based on WooYun patterns	≥5 hypotheses sorted by impact
3. Testing	Manual interception, single parameter, accurate observation	Each hypothesis has evidence to support or refute
4. Reporting	Business impact, reproduction steps, remediation measures	Findings with WooYun pattern classification

wooyun-legacy

NPX Install

Tags

SKILL.md Content (Chinese)