Performing Web Application Penetration Test

Step 5: Session Management Testing

Evaluate the security of session handling:

• Session token analysis: Collect 100+ session tokens and analyze for randomness using Burp Sequencer. Check token length (minimum 128 bits of entropy), character set, and predictability.
• Session expiration: Verify that sessions expire after a defined idle timeout and absolute timeout. Test by capturing a session token, waiting beyond the timeout, and replaying.
• Cookie security flags: Verify Secure, HttpOnly, and SameSite flags are set on session cookies. Missing HttpOnly enables XSS-based session theft. Missing SameSite enables CSRF.
• CSRF testing: Identify state-changing operations (password change, email update, fund transfer) and test if they can be triggered from a cross-origin page without a valid CSRF token
• Concurrent session handling: Test if the application limits the number of concurrent sessions and if logging in from a new location invalidates the previous session

Step 6: Business Logic Testing

Test application-specific logic flaws that automated scanners cannot detect:

• Race conditions: Send multiple simultaneous requests to exploit time-of-check-to-time-of-use (TOCTOU) vulnerabilities (double-spending, coupon reuse, voting multiple times) using Burp Turbo Intruder
• Workflow bypass: Attempt to skip steps in multi-step processes (checkout, registration, approval) by directly requesting later-stage endpoints
• Numeric manipulation: Modify prices, quantities, or amounts to negative values, zero, or extremely large numbers to test for integer overflow or logic errors
• File upload bypass: Test file upload restrictions by modifying MIME types, double extensions (file.php.jpg), null bytes (file.php%00.jpg), and content-type manipulation

Step 7: Report and Remediation Guidance

Compile all findings into a structured report:

• Write an executive summary describing the overall application security posture in business terms
• Document each finding with title, severity (CVSS 3.1), affected URL/parameter, description, reproduction steps, screenshots, and HTTP request/response pairs from Burp
• Provide specific remediation guidance for each finding including code-level fixes where applicable
• Include a risk matrix showing the distribution of findings by severity
• Deliver the report securely (encrypted, not via email attachment) and schedule a findings walkthrough with the development team

Key Concepts

Tools & Systems

• Burp Suite Professional: Primary web application testing proxy providing interception, scanning, and manual testing tools including Repeater, Intruder, and Sequencer
• ffuf: Fast web fuzzer for directory/file discovery, parameter fuzzing, and virtual host enumeration
• sqlmap: Automated SQL injection detection and exploitation tool supporting all major database engines and injection techniques
• Nuclei: Template-based vulnerability scanner with community-maintained templates for known CVEs and misconfigurations
• SecLists: Curated collection of wordlists for fuzzing, credential testing, and payload delivery used throughout web application testing

Common Scenarios

Scenario: E-Commerce Application Pre-Launch Security Assessment

Context: A retail company is launching a new e-commerce platform built on Node.js with a React frontend and PostgreSQL database. The application handles credit card payments through Stripe integration and stores customer PII. Testing scope includes the staging environment with full API access.

Approach:

1. Map the application through manual browsing and API documentation review, identifying 47 unique endpoints
2. Test authentication flows including social login (OAuth), standard login, and password reset
3. Discover IDOR vulnerability in the order retrieval API (/api/orders/{orderId}) where any authenticated user can view any order by iterating order IDs
4. Identify stored XSS in the product review feature that executes when administrators view the admin dashboard
5. Find SSRF in the product image import function that allows reading AWS EC2 instance metadata
6. Test payment logic by manipulating price values in the client-side cart before checkout submission
7. Report all findings with specific Node.js code-level remediation (parameterized queries, input sanitization with DOMPurify, authorization middleware)

Pitfalls:

• Testing only the frontend while ignoring the API layer that lacks independent authorization checks
• Missing business logic flaws by relying solely on automated scanning without manual testing
• Not testing the same functionality across different privilege levels to catch authorization issues
• Overlooking client-side JavaScript for hardcoded API keys, debug endpoints, and internal URLs

Output Format

## Finding: Insecure Direct Object Reference in Order API

**ID**: WEB-003
**Severity**: High (CVSS 7.5)
**Affected URL**: GET /api/v1/orders/{orderId}
**Parameter**: orderId (path parameter)

**Description**:
The order retrieval endpoint does not verify that the authenticated user owns
the requested order. Any authenticated user can access any order's details
including customer name, shipping address, email, phone number, and order
items by incrementing the orderId path parameter.

**Reproduction Steps**:
1. Authenticate as user A (testuser@example.com)
2. Note user A's order ID: 10451
3. Send GET /api/v1/orders/10452 with user A's session token
4. Observe that user B's order details are returned with full PII

**HTTP Request**:
GET /api/v1/orders/10452 HTTP/1.1
Host: staging.example.com
Authorization: Bearer eyJhbGc....[User A's token]

**HTTP Response** (truncated):
HTTP/1.1 200 OK
{"orderId":10452,"customerName":"Jane Smith","email":"jane@...","address":"123 Main St"}

**Impact**:
An attacker can enumerate all customer orders and extract PII (names, emails,
addresses, phone numbers) for an estimated 25,000 customers.

**Remediation**:
Add authorization middleware that verifies the authenticated user's ID matches
the order's userId field before returning order data. Implement UUIDs instead
of sequential integers for order identifiers to prevent enumeration.

Validation Criteria

A successful discovery of this vulnerability class must demonstrate:

• POC reproducible against fresh target instance (timestamp documented)
• Impact scope quantified (data leaked / privilege gained / RCE achieved)
• CVSS or business risk score assigned
• Authorization scope documented (B SRC vs target, A 项目 vs 全量)
• No destructive side effects (if RCE, sandboxed proof preferred)
• Affected endpoint clearly identified with full URL/request

If any of these cannot be demonstrated, treat the finding as inconclusive and run 111-fp-check for cross-verification.